Simple Authentication and Security Layer (SASL) WG IETF 65 Thursday, March 23, 2006, at 1510-1610 Chairs: Tom Yu Kurt Zeilenga ==================== Thanks to Rob Siemborski for scribing. Agenda slides: http://www3.ietf.org/proceedings/06mar/slides/sasl-0.pdf GS2 slides: http://www3.ietf.org/proceedings/06mar/slides/sasl-1.pdf [Kurt shows a crazy dependency graph of documents formerly blocked on rfc2222bis.] Document Status: ================ RFC2222bis approved PLAIN in IESG eval GS2: ==== [Simon Josefsson attending remotely] [slide: GS2 pg. 2 -- iab-auth-mech 1/2] draft-iab-auth-mech-05 - IAB document on security frameworks; some layering concerns (section 11.3). Jeffrey Hutzelman says the stated position is one he almost diametrically disagrees with. Section 11.3 appears to contain some factual errors: SASL doesn't support Kerberos directly (not on the standards track), and supports Kerberos through GSSAPI. In the Kerberos world, use Kerberos through GSSAPI unless you have a good reason otherwise; already too many thing who think they have a good reason otherwise. "In accordance with the principle of having as few mechanisms as possible, frameworks should avoid mechanisms that are themselves frameworks, in favor of using the second framework's mechanisms directly. 'We'll build ours on top of theirs' is a bad policy." Speaking as an individual, Sam Hartman disagrees with this slide. "Speaking as an AD, this is completely horrible". jhutz and others will be speaking with the IAB about this. The right way for SASL to support Kerberos or anything else that is a GSSAPI mech is to use the GSSAPI and not the underlying thing. Layering helps us in terms of modularity, not defining multiple ways of doing the same thing in different places, etc. Applications that use SASL shouldn't also use GSSAPI directly. Multi-level negotiation is an issue. [slide: GS2 pg. 3 -- iab-auth-mech 2/2] Concrete plans to use a non-Kerberos mech in context of GS2? Sam: stackable pseudo-mechanisms. David Black: Not knowing any better, iSCSI specified some native Kerberos and native SPKM mechs. Someone laboring in the background to clean this mess up. Kill several birds with one stone. Drop in SASL and have that drag in both cleaned up kerberos and SPKM. Sam: talked with Bill earlier this week... that would be entirely neat and clever; unfortunately, you may have to worry about BTNS. Theoretically a great solution. Chris Newman: Tentative plans to GS2-KRB5; plans for other mechs many years away if ever. Interesting point is... GS2-KRB5 as name for krb5... expose name from SASL... mapping of GSS OID to friendly name at SASL level. Kind of like that... no strong feelings though. Simon's concern is lack of review of non-Kerberos mechs. Sam: can get enough review from GSS community to have confidence. Kurt: to get to Draft Standard, want to have evidence of family working with at least 2 mechs. ...rough consensus is to continue down the path we're on: define a family of mechanisms. David: Base32... aesthetic dislike but not an objection. Would like to clean up multiple authentication mechs in iSCSI specified in ways you really wouldn't want to do if you started from scratch today. Both of Simon's options pull in SPKM .. makes SASL more interesting. [slide: GS2 pg. 4 -- channel bindings] "Sam points out that in SASL what we want out of channel binindings is to affect the negotiation of security layers. If a channel being bound to provides integrity and confidentiality protection then the application won't want to use a SASL mechanism's own security layers -- it's a waste." jhutz: SASL app doesn't know anything about GSSAPI. Potential brokenness with GSSAPI channel bindings: initiator sets channel bindings, and acceptor sets channel bindings. If they set channel bindings to the same thing, then the context establishment succeeds, else fails. Unless you want SASL to have exactly the same properties, you can't just dump SASL bindings into GSS channel binding field. Sam: 2 choices that make sense: (a-umlaut) exact same semantics as GSSAPI ... just use GSS channel bindings. (e-acute) want different semantics ... don't use GSS channel bindings, just use whatever our semantics are. Option (e-acute) [Simon's option 3] is more conservative with respect to working in more use cases. Chris?: leaning towards [Simon's] option 3. [...no real consensus in the room.] Simon: (via Rob) app responsible for negotiating TLS so it will have to tell the SASL library about the channel binding. Kurt: channel bindings discussion to list DIGEST-MD5: =========== [slide: agenda pg. 6 - DIGEST-MD5 open issues] [Alexey Melnikov] IANA registry for channel bindings? Fast reauth: * http digest: client nonce to be different but server nonce same * digest-md5: client & server both same on reauth -- is this an interop problem? any security implications? AES counter mode -- implicit initial counter from calculated key during auth. any security implications vs using explicit initial counter in each block? Sam: protocol always has blocks, even if cipher doesn't. does AES counter mode have timing attack? Simon's concern -- RC4 cipher mandatory? Big hack -- if username or password has characters representable completely in ISO 8859-1, downconvert from UTF-8 to 8859-1. HTTP mailing list... revising HTTP DIGEST... 8859-1 not applicable; usernames and passwords UTF-8 only. Can we remove this hack? Kurt: Is there an implementation with downconversion? Alexey: Cyrus SASL does this. Hard to judge if issue in practice. Love Hornquist-Astrand: Users use non-ASCII characters as passwords. Alexey: UTF-8 or whatever is on local system? Love: Yes... and yes it's painful. Alexey: Asked Ted and Lisa about what HTTP DIGEST clients/servers are doing; still have to digest response. My sense we can just go UTF-8, which will simplify spec. Simon says his implementation is UTF-8-only; 8859-1 is only due to spec... RFC 2831 and this document. Alexey: If we're going to break things, might as well fix things. Kurt: agree saslprep will break things jhutz: Why are we doing this mech? ... motivation for doing this spec bears directly on answer to this question [8859-1 downconversion]. if we decide we're doing/continuing this mech... document existing practice? Sam: Speaking as AD ... would like simple, secure, cheap, soon. (1) shared key mech (2) mech shares credentials with http auth and (3) evolves along with current http auth ... all 3 are important objectives for this WG. Kurt: AES questions? who will review? [silence] Chris: if we can't get review by someone who people are comfortable with, we should remove security layer. Sam: and then not publish as standards track. David: If saslprep is in the picture, 8859-1 downconversion is a bad idea... in terms of what happens between when it gets entered and when it hits the crypto, fewer steps the better. Prefer one to having to use both. Kurt: Depending on username/passwords used, may be a no-op. Chris: 8859-1 downconversion has sample code in base spec believed correct; not complicated, just ugly. Alexey: Chris, maybe the reason nobody complained is that everyone cuts&pastes the same code. [slide: agenda pg. 7 -- DIGEST-MD5 TODO list] Milestone Review: ================= Kurt: What are we really doing, requirements for mechanisms; Chris has said many times CRAM as currently specified is widely deployed and we shouldn't break it; DIGEST-MD5 is not widely deployed, known to have all kinds of problems. Alexey: most of [DIGEST-MD5] problems in security layer Sam: DIGEST-MD5 may not be widely deployed but HTTP-DIGEST kind of is, or at least there are enough corner case deployments that we actually care about interoperability, or at least I do as someone trying to create a consistent internet security architecture. Kurt: GSS ... available, reasonable interop ... is it widely deployed? [brief side discussion (jhutz, Sam, Kurt) -- yes, it is widely deployed] Kurt: personal thoughts... lots of issues raised with existing mechs... limitations -- QOP protection in DIGEST, DIGEST itself, various other limitations. Write one informational for each mech, interop concerns, security concerns, publish. Then focus on designing mechs for people's long-term needs going forward. Tom: Set action items first... what needs doing on CRAM? DIGEST? still need some work. Lyndon: needs to rev [CRAM] for refs, clarify applicability; will write applicability text. Alexey: saslprep issue with CRAM? Kurt: Chris, will it break deployments? Chris: My implementation... CRAM only turned on if password stored in clear in DB... can work around whatever happens. Prefer to leave saslprep out of CRAM to keep it simple. Sam: Document what's deployed. Chris: What's deployed doesn't do saslprep. Sam/jhutz: Focus on publishing this document already. Lyndon is willing to write applicability text himself -- 2 weeks to new draft. Action Items: ============= Lyndon will rev CRAM to deal with security considerations and applicability statement. Other action items/milestones: May 2006 CRAM-MD5 May 2006 GSS-KRB5 Jun 2006 GS2 Jul 2006 DIGEST Oct 2006 implementation report plan Nov 2006 revise charter or conclude