Simple Authentication And Security Layer (SASL) IETF72, Dublin, IE Tuesday, July 29, 2008 at 15:20-17:20 ===================================== Chairs: Tom Yu Kurt Zeilenga ==================== Jabber logs: http://jabber.ietf.org/logs/sasl/2008-07-29.txt Audio logs: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch8-tue-noon.mp3 ftp://limestone.uoregon.edu/pub/videolab/media/ietf72/ietf72-ch8-tue-noon.mp3 Slides: Agenda http://www3.ietf.org/proceedings/08jul/slides/sasl-0.pdf SCRAM http://www.ietf.org/proceedings/08jul/slides/sasl-1/sasl-1.htm Channel-Binding for HTTP Digest http://www3.ietf.org/proceedings/08jul/slides/sasl-2.pdf ==================== Thanks to Larry Zhu for scribing. Working Group status: activity is low; inadequate progress is being made, and the group needs revitalization. Chairs admit past scarce available time, should have more time in the future. To solve this problem, chairs will be more proactive and produce a biweekly summary of who has the ball on what. Get rechartering back on track. Document status: * draft-ietf-sasl-crammd5-10 - answer outstanding comments; It went through last call with the document claiming to be Standards Track, but there was some confusion about what the intended status actually was and whether it actually moves RFC 2195 to Historic. Produce new revision to IESG with Informational status and explicitly marking 2195 Historic. * draft-melnikov-digest-to-historic-00 - expired; Alexey says he wants SCRAM to be stable before publishing. * draft-ietf-sasl-gs2-10 - need rev; gated on SCRAM (or more specifically a document that would use the framework) Sam would rather GS2 were published than have it die if SCRAM happens to die. * draft-newman-auth-scram-06 - new doc available * 4422bis - not yet * 4013bis (SASLprep-bis) - maybe not yet; might not be enough time at the moment. CRAM-MD5: Confirm 2195 to historic; confirm new status (informational) ... respond to frank Kurt: If consensus is not for Informational, much more work to do because it is not ready for Standards Track. jhutz: Get it done already. Kurt: Comments from Frank Ellerman not properly addressed; redo last call to deal with that. Sam, Pasi: Don't redo the last call; answer the e-mails. Kurt: Chairs will respond to the outstanding comments; direct editors to make minor changes consistent with consensus: status informational and RFC 2195 to Historic. Then send to IESG. SCRAM: (Alexey Melnikov) Changes done: SHA-1 as MTI hash alg. Redefine Hi(x) to use PBKDF2 from RFC 2898. Added text re using saslprep for username canonicalization. Text on channel bindings needs to have refs; Abhijit wants clarifications (client-to-server vs server-to-client). Sam: SASL server indicates whether channel binding was valid because client will make decisions based on that. Don't want server to decide that bindings invalid, and client to want to drop connection, but some MITM keeps connection open. In GS2 this is more complicated because you might want client keep the connection open for security layers and it might be ok if channel bindings don't verify. If in SASL mech w/o sec layer, it can be simpler if we say that channel binding failure is fatal. Kurt: SASL provides indication of succes, or an indication or error. No indication of "maybe". Sam: Internal to the mech, can choose to install a security layer. jhutz: use side channel in nonexistent SASL API for indicating channel binding failure... jhutz: client needs to know that channel binding failed, so must be communicated through mechanism. part that concerns me (and not sure how we dealt with this). don't want to end up in situation where server leaves connectino open when client decides it's not ok. then you have a tunnel attacker connected to the server as the client. Sam: I think we got this right in GS2. Very easy to analyze in the ABNF version I sent to the list. Suggest that we look at it in terms of the GS2 spec. Regardless of whether we use gs2 for scram, if we got it wrong there, we should fix it (gs2). i think it's been more considered there than in the scram text. alexey: Design team? sam: wiling to be be part of design team evaluate/compare, not interested in fixing the SCRAM text as the SCRAM text today. Would rather work on things in the GS2 context than in the SCRAM context. Chris: If channel binding fails, authentication must fail. Otherwise why ask for channel bindings? SCRAM has no security layer. I can't see why you would want a different outcome than failing authentication when channel bindings fail? Kurt: need to make progress. Try to ensure that both of these alternative views are as mature as possible in the WG to make a decision. Alexey: DIGEST had the problem that hash was not computed over all possible extensions, so attacker could add one. Are extensions allowed, or does signature cover the whole thing? Chris: no extensions. if you want extensions, make a new mechanism. Nico, jhutz: Do we need extensions at all? Kurt: If you need extension, define new mech to support extension. jhutz: Long life for SCRAM, or short one? alexey: differing opinions. take to list? Kurt: First make sure to sign everything. Allow unknown keywords? Ignore by default, or cause failure by default? Nico: Need only provide one critical extension. Sam: Could propose for maximum flexibility: ignore unknown keywords, have special one for "fail". (futureproofing) Chris: Editors should write text that says something in this area. Kurt: Restating. All unknown keywords will be ignored except one. Alexey: Hash negotiation in SCRAM, or put it in the mech name? Kurt: Put hash algorithm choice in mech name. Sam: Upgrade problem, e.g. no stored user cred for new upgraded mech. (in the case where you are being good and not storing plaintext passwords) jhutz: username-based SASL mech selection? If you impose the right requirements on what mechs are listed where/when, then you avoid multilevel negotiation. Kurt: username harvesting? jhutz: policy tradeoff Tom: Server can lie about whether the user exists. Chris: Decide to do hash in mech name, then figure out how to do it. jhutz: Oh, so defer until we actually have SCRAM-HMAC-SHA256 or whatever the next hash algorithm is. Alexey: PBKDF glitch? Extra integer parameter to allow people to use existing PBKDF libraries? Alexey: user-specific iteration counter? vs server-wide? Sam: Kerberos had implementor requests for user-specific, and got implemented. Chris: I deliberately wrote that part of SCRAM to make it user-specific. Alexey: Original text was worded wrong... was omitted from list of user-specific things. Chris: LDAP storage with million users. Say we want to up the iteration count for every user. Taking entire DB down for upgrade is not a good idea. Alexey: Simple enough. Will update text. Alexey: Skipping GS2 for now. Alexey: adding realms? jhutz: Really an identity hint for client's use for choosing which credentials to use. Kurt: [Nico] proposed on list and it was rejected. Alexey: LDAP attribute for storing SCRAM auth info? Kurt: out of scope? {LDAP wg work} not implemented Chris: Can it be implemented on an unextended LDAP server (off-shelf), or does it require protocol extensions? Kurt: It's an attribute, but uses its own matching rules specification. Chris: I will not implement SCRAM unless there is a way to store auth info in LDAP that is written down. ... {separate doc?} ... Alexey: will write some text Alexey: GS2 framing Sam: Apologies for the delay ... designed during IETF71 (PHL) (for then-current SCRAM) with Nico. Today, got raw notes and posted. Maybe only Chris can evaluate raw notes. Purely aesthetic issue. If we are willing to make changes to GS2, can get to a framing that people would find reasonable. If we don't make changes to GS2, some things that some people will find objectionable in what I posted. What's going to get complicated ... different aesthetics between GSS people and apps people. May be a challenge to get to consensus. Willing to talk with people about it. GS2? Sam: GS2 is in holding pattern, waiting on SCRAM. Question in IETF71 (PHL) whether that's a good idea. Came to conclusion it's a very good idea, because there are some things you might want to do to align SCRAM and GS2 will end up changing the encoding of GS2. Stefan Santesson talks about a non-WG document concerning HTTP digest with channel binding to TLS. Kurt talks about revising SASLprep. It currently references stringprep, which references a fixed Unicode version (3.2). The new approach uses Unicode parameters, and is more immune to Unicode updates. CRAM done; DIGEST - know what we are doing there; GS2 done but waiting [Chris sends implementation questionnaire draft to list during session!] Milestones: Aug 08 - send implementation questionnaire Aug 08 - 4422bis - editorial revisions Sep 08 - 4422bis WGLC Oct 08 - SCRAM WGLC Nov 08 - SCRAM to IESG Nov 08 - implementation report