Simple Authentication And Security Layer (SASL) IETF74, San Francisco, CA Tuesday, March 24, 2009 at 0900-1130 ==================================== Chairs: Tom Yu Kurt Zeilenga Scribe: Cyrus Daboo http://jabber.ietf.org/logs/sasl/2009-03-24.txt ftp://videolab.uoregon.edu/pub/videolab/media/ietf74/ietf74-continental_3-tue-am.mp3 ==================== * draft-melnikov-sasl-scram-ldap-01 * draft-newman-auth-scram-11 - near consensus * draft-newman-auth-scram-gs2-01 - fold into SCRAM * draft-ietf-sasl-4422bis-00 - needs refresh * draft-ietf-sasl-crammd5-10 - expired; consensus call in-progress * draft-ietf-sasl-digest-to-historic-00 - needs refresh; to IESG with SCRAM * draft-ietf-sasl-gs2-11 - near consensus * draft-zeilenga-sasl-crammd5-00 - SCRAM - PBKDF2 iteration count: Document currently says 128 iterations (per original 10 years ago); probably way too low. Simon notes more recent documents recommend 4096. PKCS#5 recommends minimum of 1000. Pasi notes that was 10 years ago. Pasi Eronen suggests that for battery-powered devices, consideration is user-visible latency, not battery. Use largest count that allows an acceptable user experience. SCRAM - open question on including "service name" URI (similar to DIGEST-MD5 usage, where it caused interop problems) to avoid a "bad" server proxying to a "good" server and thus gaining access to the "good" server as the user. Would be a weak form of channel binding. Some discussion of how it happens to work for SIP. Pasi notes that the reason it works for SIP is because SIP is a single application. Sam Hartman agrees - whatever we choose has to work with SASL, which already has a concept of server and client name (to support Kerberos etc.) Much discussion. Chris Newman: full URI? client-provided server name? service name? Kurt: service name can cause problems with proxies, e.g. SIP, XMPP Dave Cridland (via jabber): why not use channel bindings if you want to protect against it? Love Hornquist Astrand: problem with channel bindings - clients may not implement, so servers won't turn it on due to interop considerations. Chris: How hard is it to implement TLS channel bindings? Alexey: Dave Cridland found undocumented stuff in OpenSSL to make it work. No clear consensus on "service name". New GS2 approach, very text-oriented. Considered acceptable for SCRAM. Distinguish channel-binding vs not by using a suffix on mechanism name. Kurt polls -> Shall we modify SCRAM to put some notion of service identifier in client's request? Yes - ~2 No - ~6 Undecided - ~2 Sam really wants to solve this problem, but in a way that doesn't destroy interop and actually gets implemented. Worthless if nobody implements it or if it doesn't work. Also want to solve this for EAP; would be great if the solutions were compatible in how they name servers. Love is concerned about both server and service impersonation. (Both one IMAP server impersonating another IMAP server, or an XMPP server impersonating an LDAP server. Sam: idea from Nico that makes me want to say yes: client can indicate; server can tell you whether it bothered to validate. [but there are issues like additional roundtrips if you don't want to provide an attacker with a validated channel] ...can we postpone dealing with this? probably. Alexey talks about a simpler GS2 variant that is still textually based. Looks like there is consensus to do SCRAM using the new GS2. GS2, SCRAM edits done by end of month. CRAM-MD5 - ongoing consensus call. So far, general agreement about abandoning work, etc. as in Tom's statements in the consensus call, except for the adoption of SCRAM as the replacement for CRAM-MD5. Milestones: Mar 09 GS2 WGLC Mar 09 SCRAM WGLC Apr 09 decide CRAM-MD5 approach Jun 09 4422bis I-D and implementation report Oct 09 4422bis WGLC