Subject: [Ips] DRAFT Montreal minutes

From: [email-masked]
Date: Wed, 12 Jul 2006 19:51:58 -0400

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-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: David Wysochanski <[email-masked]>
Date: Thu, 13 Jul 2006 10:44:47 -0400

A couple comments a points for clarification, while this is fresh on
everyone's minds below.

>                 to impose this restriction
This is actually already in there if you read the fine print of the 
"Use" portion of
the declaration and note that "Any-Stage" is not there (see Section 12 
in 3720).
Since it has come up repeatedly though from various people, I will add some
text to point this out explicitly and refer to Sections 11 and 12 of 3720.

>                 one used for the large numbers involved in some
Was the comment to limit the value size to 255 bytes, i.e. a single
"text-value" (or "simple-value"), as defined by 3720, or something
else?

I liked the comma separated values and list-of-values seemed to
fit well.  But if there are concerns about key length I suppose we
can add an explicit max length of the list-of-values.  Another reviewer
raised the question about the maximum length early on so perhaps
an explicit limit is the way to go here.

>                 or revise text to make this point.
Was the consensus that the original term, "functional behavior",
was clear enough, and I just muddied the water by trying to
make it more crisp?

>                 the other side deals with the resulting response.
Ok.

>                 specific that the amount of detail is what changes across
I'm not sure about this comment because I thought the existing text
does just that.  Here's what the text says today:

    all
    implementations of this extension key SHOULD provide an 
    administrative mechanism to configure different levels of
    detail in the extension key values and MUST provide an
    administrative mechanism to disable sending the key.

>                 (the prior "SHOULD NOT" appears to conflict with this
Point taken - will work on it.

>                 including description clearly in the draft. 
Was the comment that the existing declaration in section 2
conforms to section 12 of 3720, and specifically, section
12.22?

>                 the double quotes ("), as they don't appear on the wire.
Ok.  Main intent in providing company names was to show valid
examples for implementers but I will remove them.  Note that
RFC 2616 does have valid examples

   Examples:

       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
       Server: Apache/0.8.4

>                 and feel free to ask on the list for options on how to 
Good catch - looks like I got carried away in my intent to provide
clear examples.

---

From: William Studenmund <[email-masked]>
Date: Thu, 13 Jul 2006 15:46:39 -0400

On Jul 13, 2006, at 10:44 AM, David Wysochanski wrote:

> the declaration and note that "Any-Stage" is not there (see Section  
> 12 in 3720).

It could also be that we just kinda forgot the exact wordings. Now  
that I look at it, it seems ok. So perhaps just mentioning  
Operational Negotiation Only somewhere in the text is ok.

> "text-value" (or "simple-value"), as defined by 3720, or something

Yes, 255. The long keys are rarely used, so we wanted to keep this a  
short one.

> an explicit limit is the way to go here.

Well, we can get a lot in 255 bytes. :-)

>>                 the other side deals with the resulting response.

I think that you'll get back a "NotUnderstood" response, but we  
should check into this. :-)

> conforms to section 12 of 3720, and specifically, section

I think the initial thought was something more along the lines of  
making sure there is a 12.whatever (less than 22) style block. And I  
think there is.

> Good catch - looks like I got carried away in my intent to provide

No. I think spaces could be quite useful. My idea is to suggest that  
we make this key use "iSCSI-name-value" format. That would let us  
have a 255 byte UTF-8 string, which can encode a lot of stuff.

I think it's ok for commas to be in there. The difference between  
having commas in an "iSCSI-name-value" and a "list-of-values" is that  
the latter is a list of things that make sense to iSCSI negotiation.  
Like Auth methods or CHAP hashes. But this key isn't supposed to be  
processed by login negotiation (it's passed around as an opaque  
string), so just happening to have commas in it is fine. They merely  
only have meaning for humans looking at the logs.

Take care,

Bill

---

From: David Wysochanski <[email-masked]>
Date: Thu, 13 Jul 2006 18:39:36 -0400

William Studenmund wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Ok, may have to revisit this one.

I think all the other comments are
the same as David's and/or have been
addressed.

Thanks for the feedback.