Subject: RE: [Ips] DRAFT Montreal minutes

From: [email-masked]
Date: Thu, 3 Aug 2006 16:32:17 -0400

> > 	- 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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 3:36 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [Ips] DRAFT Montreal minutes
> 
> On Wed, Jul 12, 2006 at 07:51:58PM -0400, [email-masked] 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-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Aug 2006 15:47:39 -0500

> use SPKM3 is what I had in mind.

Assuming that SPKM-3 progresses.  But more importantly, you'll get all
GSS-API mechanisms (we'll probably get more GSS mechs over time,
starting with GSS bindings of DIGEST-MD5 or something of the sort), and
that's architecturally what you want: an hole to be filled by others,
that way you leave PKI to SPKM-3 without having to even mention it
(except as a REQUIRED mechanism, but I think it'd be hard to REQUIRE
anything other than Kerberos V at the moment).