Re: 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