Simple Authentication and Security Layer (SASL) WG IETF68 - Prague, Czech Republic Wednesday, March 21, 2006, at 1300-1500 Chairs: Tom Yu Kurt Zeilenga RESOURCES ========= Jabber logs: http://www.ietf.org/meetings/ietf-logs/sasl/2007-03-21.html Audio logs: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch7-wed-noon.mp3 Agenda slides: http://www3.ietf.org/proceedings/07mar/slides/sasl-0.pdf HEXA slides: http://www3.ietf.org/proceedings/07mar/slides/sasl-3.pdf SCRAM slides: http://www3.ietf.org/proceedings/07mar/slides/sasl-1.pdf YAP slides: http://www3.ietf.org/proceedings/07mar/slides/sasl-2.pdf Agenda bash/scribe/etc. ======================= Thanks to Bob Morgan for scribing. Document Status =============== draft-ietf-sasl-crammd5-08 in WGLC draft-ietf-sasl-gs2-07 in WGLC draft-ietf-sasl-gssapi-08 RFC 4752 draft-ietf-sasl-rfc2831bis-12 some issues... WGLC documents -- mostly only have minor issues. We need more reviewers for CRAM-MD5. rfc2831bis (DIGEST-MD5) ======================= Alexey talks about DIGEST-MD5. "To be or not to be"... some interop problems; too many features, many not implemented or tested properly. minor security design issues. Many options, not easy to implement from scratch. Heard from many people including original authors suggesting we should do better. No obvious volunteers for review. options? 1. drop, maybe document what's wrong 2. update to clarify w/o adding new features 3. get doc published with all new features Nobody so far suggested publishing document with new features; people divided between (1) and (2). Related question: not just that we want to drop; many express desire to have a mech with similar properties, just done better. Considering 3 recent new documents... interest in doing something better. some discussion re moving to historic. Sam notes a key thing DIGEST gets you is sharing authentication DB with SIP. Kurt asks if we know of anyone doing it. Sam is uncomfortable with making the disparity of credential formats worse. Alexey suggests that we can make that a requirement for the replacement mechanism. Sam wants to ensure (1) mech that's simple, channel bindings, no security layers (2) mech similar to DIGEST with security layers and channel bindings. His personal preference is that if you do a new mechanism that you do channel bindings. Nico asks if Sam thinks new SASL mechanisms should also be GSS mechanisms. Sam affirms. Nico thinks a GSS/DIGEST mechanism should be very simple to specify. Sam's desirable outcomes: DB compatibility w/mechanisms used in SIP/HTTP world Parts of apps world think that CRAM is better than DIGEST; don't want to hear later feedback that CRAM is better than our replacement to DIGEST-MD5! GSS mechanism rather than SASL mechanism; if had to choose -- would only push for if someone could spend real time demo that you could do a GSS mechanism simple -- basically a document done as a GSS mechanism, but text saying that if you don't want to deal with this GSS stuff, you can treat it as a SASL mechanism with a funny name. Simon Josefsson agrees with Nico re specifying DIGEST mechanism as GSS mechanism; already has a document doing exactly that. He thought of publishing, but we already had 3 new mechs to discuss. HEXA ==== Dave Cridland talks about HEXA. It's intended as a better digest-md5 -- goal is easily deployable security. Probably merged with SCRAM; though developed independently, it has awfully many similar properties. Client secret hash of pswd salted w/realm (close to digest-md5 on client). Server secret is salted hash of client's secret; doesn't actually have client's secret -- similar to /etc/shadow. ("hash" meaning repeated HMAC based on agreed-upon hash alg). security goals: * no plaintext on wire or server * no reliance on external channel for mutual auth - does both mutual auth and channel binding (allows anon-DH or leap-of-faith) * real-world hash agility * all opts used in hash input; no MITM opportunity security non-goals: * security layers * fast re-auth Nico asks if it shares creds w/DIGEST -- it does not. Dave's customers don't want something like shared secret between client and server; hacking into server lets you masquerade as user. Nico asks for options to do either, for transition. Dave also notes that merging with /etc/shadow type db is possible for transitions. SCRAM-MD5 ========= Chris Newman (outgoing editor) talks about SCRAM-MD5. revived from 1998 i-d. key properties - stored key not plaintext equivalent (same property as HEXA). No realms; no security layers; changing userid doesn't invalidate stored key (unlike digest)... for that reason, nobody stores DIGEST-MD5 passwords as hashes -- instead, store as clear; enough people don't like doing so that digest isn't deploying. No sub-negotiations; define new mechs per hash. Hash is part of mech name. YAP === Kurt talks about YAP (Yet Another Password-based mechanism). Wants something with value proposition close to CRAM-MD5 - simple to implement, one round-trip, wholly relies on lower-level security to protect exchange and application data. Include i18n, hash agil. Sam, Nico, et al. debate round trips vs mutual auth and channel bindings ... there appears to be consensus to move DIGEST-MD5 (in the form of RFC 2831) to Historic. Recharter discussion ==================== Nico wants to kill DIGEST-MD5 and do a GSS mech that does DIGEST-type things; if you also want to do sasl-type things, great. Nico is willing to write text, but not willing to edit. Sam thinks there will be skepticism of the gss approach -- show the doc as a primarily sasl mech, has a mechname that happens to start with "GS2-", has normative section that points out that it's also a GSS mechanism. if we do anything less, people are going to whine at us that it's hard to implement, and that may be hard to defend against... simplest way to show ppl something isn't hard is to give them a simple instantiation of it. nico is willing to help write that text. Chris encourages doc editors of hash mechs to expt w/ the gs2 proposal. There are advantages to having a GSS mech where you can't do sasl, e.g. nfs. Sam recommends from a security standpoint evaluating pbkdf2 for converting password to internal rep; if not, you should justify. Agrees with chris that 2-lvl nego bad. As individual, channel bindings and mutual auth are a requirement. Will eventually make up an AD opinion on the issue. Seem to have eliminated option of continued devel of DIGEST-MD5. Propose re-charter for replacement mech? Sam considers failure if WG doesn't publish DIGEST-MD5 and also doesn't publish something better than PLAIN that's lower infrastructure than gss-krb5; open to recharter request. Must recharter if replacing DIGEST-MD5 mech. kurt - (1) request to move to historic w/o i-d (2) request to move to historic and provide i-d (3) document problems, etc. do something else Is there value of having an rfc saying why we moved to historic? Any volunteers? Sam says not sufficient value if it takes as long to write as CRAM-MD5 applicability statement. If we drop digest-md5 we will have to recharter because it's explicitly in our charter. Chris asks if there's volunteer to republish DIGEST fixing bugs not adding new features, stating why problems... if no volunteers, move to historic. Alexey can write "what's wrong" clarifying text iff other people who want it done. As individual Sam would rather not see a document updating digest. Kurt thinks an update would reinforce usability; better to just move to historic. Poll: DIGEST-MD5 to historic: yes 7-10; no 0; don't care 3-4 Looks like consensus to move DIGEST-MD5 to Historic. kurt calls for volunteers for i-d for historic. (one?) RFC detailing historic? Alexey prefers explicit explanation locatable in RFC index. Dave asks if we could have replacement mech obsoleting digest to show a clear update path. Interest in adopting hash-based pass-based mech as replacement for DIGEST-MD5 as work item? yes 7-10; no 0; don't care 0 Consensus to recharter as proposed. Sam asks if charter proposal will explicitly state specific solution. Kurt says no. Discussion of how many password-based mechs are to replace digest. HEXA and SCRAM are somewhat similar and may end up being combined eventually. YAP may remain separate; Kurt may continue it as individual submission. LEMONADE may be interested in single round-trip. Sam suggests getting sec area-wide last call before adopting one of these -- once you decide which way you want to go... secdir may not be broad enough. Are there sets of users of these mechs who have disjoint reqt's in terms of properties of these mechs? Chris definitely sees varying req'ts; NNTP want protected auth but no channel protection. to satisfy that use case, you must have hash iterator; that kills one round-trip. YAP completely unapplicable w/o TLS. LEMONADE very tense about round-trips; may be very interested in YAP. Real design tradeoffs. HEXA+SCRAM derivative likely to satisfy more use cases. Talk to LEMONADE chairs about their requirements. Poll: enough info now to make recharter decision on # mechs: yes 0; no ~4 Sounds like there is consensus for HEXA+SCRAM to replace DIGEST-MD5; not yet consensus on whether to adopt YAP or similar. Further discussion to happen on list. Kurt talked about interop reports. Kurt's discussion with Alexey indicate that multiple interoperable implementations do exist; we just need to document that fact. Kurt will work with implementors to assemble report. Some normative reference issues to deal with. Discussion about relaxing normative downref rules. Alexey talked about Sam's Discuss on the SMTP AUTH document, regarding mandating of the verification of server TLS certificates when using PLAIN over TLS... whether the server cert check belongs in STARTTLS vs SMTP AUTH. Sam says cert verification actually harmful in STARTTLS -- significant value as just confidentiality. You get protection against passive attackers if you don't do server cert verification. If you do need protection against active attacks, and PLAIN does, you need to verify certs. Don't specify to drop connection if certs don't verify -- just don't do the things you wouldn't want to do over an unverified connection. Don't want people turning off TLS just because turning on TLS creates an interop problem. As long as you say that in STARTTLS doc, that's ok. Discussion of exactly which document the text should end up in. ACTION ITEMS ============ * Kurt will assemble a preliminary interop report before next meeting Milestones: * in the next week, acquire more information about application requirements upon password-based mechanisms. * conclude WG Last Calls * recharter including DIGEST-MD5 replacement(s) -- about April