RE: DRAFT Montreal minutes

> > 	- SASL has an SPKM-3 method.
> 
> SASL has no SPKM-3 mechanism.  The GSS-API does (see below).

My sloppiness - what Nico describes about SASL having a generic
GSS-API bridge (GS2) in the works that will provide a means to
use SPKM3 is what I had in mind.

Thanks,
--David
----------------------------------------------------
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: Nicolas Williams [mailto:[email protected]] 
> Sent: Thursday, August 03, 2006 3:36 PM
> To: Black, David
> Cc: [email protected]
> Subject: Re: [Ips] DRAFT Montreal minutes
> 
> On Wed, Jul 12, 2006 at 07:51:58PM -0400, [email protected] wrote:
> > 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.
> 
> (a) is no longer an issue for me...
> 
> > 	b) The SPKM-1 and SPKM-2 methods are arguably obsolete.
> 
> Yes, but also it made no sense to specify their use without specifying
> the use of the GSS-API.
> 
> > 	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.
> 
> SASL has no SPKM-3 mechanism.  The GSS-API does (see below).
> 
> SPKM-3 is being revised by individual submitters; it's currently
> undergoing expert review.
> 
> SASL's GSS-API bridge currently only really works with the Kerberos V
> mechanism.  There's a new SASL GSS-API bridge in the works that will
> be much more general and which introduces a SASL-specific channel
> binding concept.
> 
> > 	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.
> 
> Sure.
> 
> > 	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.
> 
> I agree.
> 
> Longer term, when the BTNS WG completes work on "connection latching"
> (how to construct "IPsec channels") and IPsec APIs then iSCSI 
> should be
> able to specify a profile of iSCSI using SASL channel binding to IPsec
> channels and simplify IPsec configuration.
> 
> Nico
> -- 
> 
> _______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
> 

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