FINAL Montreal minutes

Having seen no comments on the list, these are now the final
Montreal minutes, and the "IMPORTANT:" note about the merits
of adding SASL to iSCSI is now the rough consensus of the
IP Storage WG.  As the minutes say:

	There may be a draft forthcoming that will add SASL to iSCSI -
	the sense of the room is that this would be a good thing to
	do, although it is not of immediate urgency.

Thanks,
--David (ips WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: Black, David 
Sent: Wednesday, July 12, 2006 7:52 PM
To: [email protected]
Cc: Black, David
Subject: DRAFT Montreal minutes
Importance: High

We actually managed to use the entire hour, and (IMHO) had very
productive discussions.  Please send any corrections to the
DRAFT minutes below to me (and cc: the list if you want to).

IMPORTANT: The sense of the room in Montreal was that adding SASL
to iSCSI is a good way to:
	- Obtain an authentication method or methods based on SHA-256
	- Address issues with the current Kerberos and SPKM methods.
There is no current intent to make any SASL method mandatory or
remove the mandatory-to-implement status of iSCSI CHAP.

Anyone who disagrees with the above sense-of-the-room conclusions
should post that disagreement to the list promptly along with an
explanation of why - *please* change the subject line of the
email when doing so.  Absent such posts, this "SASL is a good
thing to add" direction will become the rough consensus of
the IPS WG.

Thanks,
--David (ips WG chair)

IP Storage (ips) WG Meeting Minutes - DRAFT
Wednesday, July 12, 2006 - 1510-1610
Montreal, Quebec, Canada
-----------------------------------

Administrivia, agenda bashing, draft status review, etc. - 15 min
		David L. Black, EMC (chair)
	Blue sheets
	Note Well
	Draft status - projected from I-D tracker
		- Lots of published RFCs
		- iSER and DA drafts are paused waiting for the RDDP
			drafts that they depend on.  The RDDP drafts are
			starting to move.
		- iSNS MIB has received MIB Doctor review, and a revised
			draft is in preparation (significant work is
involved)
		- Implementers Guide is in WG, but not much activity.
Likely
			to be WG Last Called before next IETF.  Most
important
			material in that draft involves task management
operations
			that may affect more than one task (e.g., ABORT TASK
SET,
			CLEAR TASK SET, LOGICAL UNIT RESET, TARGET RESET) -
			please review this material.  Not on today's agenda
		- Node Architecture draft.  Will be worked on today.
	Milestones
		- Dec 2006 for Node Architecture Draft
		- Jan 2007 for Implementers Guide Draft
		- Both appear reasonable.  WG chair will be pushing ISER,
DA,
			and iSNS MIB drafts through the process.

iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min
	(draft-ietf-ips-iscsi-nodearch-key.txt)

	WG Discussion:
	- Key should be allowed only after Authentication.  Revise draft
		to impose this restriction
	- Make sure it's a regular-size text key (not a big one, like the
		one used for the large numbers involved in some
authentication
		methods).
	- "protocol logic": crucial point is that **behavior** is the same
		independent of presence, absence, or content of the key.
Add
		or revise text to make this point.
	- Document behavior of RFC 3720-compliant implementation that
		receives this new key and does not understand it, and how
		the other side deals with the resulting response.

	- "configure different levels" text needs to be rephrased to be
		specific that the amount of detail is what changes across
levels.
	- Align ability to configure amount of details with "SHOULD NOT"
		in Section 1.2 about administrative setting of key value.
		(the prior "SHOULD NOT" appears to conflict with this
"SHOULD").

	- Double-check there is a 3720-format definition of the key,
		including description clearly in the draft.  

	- Make the examples phony (no real company names), and remove
		the double quotes ("), as they don't appear on the wire.
	- Spaces are forbidden in text strings.  See RFC 3720, Section 5.1,
		and feel free to ask on the list for options on how to deal
		with this.

iSCSI Security Mechanisms: WG Members - time remaining (if any)

	The IETF Security Area has requested that IETF Working Groups plan
	to transition away from usage of MD5.  iSCSI CHAP currently uses
	MD5 in a fashion not directly threatened by the hash collision
	results known for MD5.  If time is available in the meeting, it	
	will be used to discuss what to do instead, as using a different
	hash with CHAP is not the only option.

	Above description is copied verbatim from Dallas agenda.  There
	are two other related concerns:
	a) The Kerberos support in iSCSI is frowned upon by Kerberos
		experts.  iSCSI Kerberos is not GSSAPI-based, and hence
		can't be used with GSSAPI-only Kerberos implementations.
	b) The SPKM-1 and SPKM-2 methods are arguably obsolete.

	SASL is a potential means of addressing all of these problems:
	- SASL has and/or will have methods based on SHA-256, the
		next hash of choice (according to the IETF Security Area)
	- SASL has GSSAPI-based Kerberos support that has been
		designed by Kerberos experts
	- SASL has an SPKM-3 method.

	The approach would be to add SASL methods to iSCSI by doing
	mapping the SASL tokens into iSCSI and providing authentication
	mechanism names (e.g., the SASL mechanism <foo> is negotiated
	by iSCSI as the SASL-<foo> mechanism).  These would be additions
	- the current must-implement CHAP mechanism is not broken, and
	would not be removed.

	There may be a draft forthcoming that will add SASL to iSCSI -
	the sense of the room is that this would be a good thing to
	do, although it is not of immediate urgency.

Open Mike - Roger Cummings noted that RFC 3720 is based on SAM-2; 
	SAM-3 has appeared resulting in SCSI work in T10 that requires
	SAM-3.  One example is encrypting tape drive work in T10 that
	relies upon a new well-known logical unit definition that is
	only in SAM-3.  This is a reason to work on updating iSCSI to
	SAM-3.  The WG chair commented that such an update would be
	backwards compatible, and would require the active involvement
	of a SCSI guru to ensure that the interactions with the SAM-3
	specification are correct.

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips