Simple Authentication and Security Layer (SASL) WG IETF 66 Monday, July 10, 2006, at 1520-1720 Chairs: Tom Yu Kurt Zeilenga ==================== Thanks to Jeffrey Hutzelman for scribing. Agenda slides: http://www3.ietf.org/proceedings/06jul/slides/sasl-1.pdf GS2 slides: http://www3.ietf.org/proceedings/06jul/slides/sasl-0.pdf Summary of consensus points and action items: ============================================= DIGEST-MD5: AES cipher IV / QOP data? Add to nonce like channel bindings. DIGEST-MD5: "SHOULD" vs "MUST" check authzid? Use non-normative text. DIGEST-MD5: AES not RC4 is mandatory to implement. CRAM-MD5: Kurt will write applicability statement. Updated Milestones: Aug 2006 WGLC for CRAM-MD5 Aug 2006 WGLC for GS2 Aug 2006 WGLC for DIGEST-MD5 Sep 2006 CRAM-MD5 to IESG Sep 2006 GS2 to IESG Sep 2006 DIGEST-MD5 to IESG Oct 2006 Implementation report plan Nov 2006 Revise charter or conclude Document Status: ================ CRAM-MD5 - needs applicability statement GS2 - some open issues GSSAPI - sent to IESG PLAIN - approved rfc2831bis (DIGEST-MD5) - some open issues DIGEST-MD5: =========== Alexey talks about DIGEST-MD5 AES cipher IV - DIGEST-MD5 suffers from some MITM attacks because hash doesn't include QOP attributes generated by both ends. With new AES cipher, we can fix it in the new cipher spec. In previous conversation with Sam, he pointed out that if both ends are using the AES cipher, they've already negotiated confidentiality, which is the strongest mode. He then suggests that we can get protection for QOP by adding data to channel bindings. Following a question from Kurt, Alexey clarifies that QOP data would be added to the nonce in the same way that channel bindings would be. No objections. Use of different string preparations - the 09 revision added new way to describe what preps are supported by server; client picks one. After a previous discussion, proposal to deal with both old and new implementations by defining a new attribute to indicate that server supports saslprep. When client sees the attribute, it sends one hash each for the saslprep string and the unprepared string. Some debate about optimization to only send one string if they're identical. Sam warns to be careful to consider implications for testing. Simon (via Jabber) raises concerns about apps area intentions to revisit stringprep. John Klensin is summoned to Jabber. John comments that it's unknown to what degree SASLprep will be impacted. Most of the issue is whether stringprep is tied to a particular version of Unicode; if it's not, then there might be differences in normalization and hence problems with forward compatibility. Sam is primarily concerned about linguistically valid text, which will probably be less of an issue, but John points out that some non-linguistically valid text makes really good identifiers and passwords, and there could be trouble if Unicode version changes affect the normalization. Re-authentication differences between HTTP DIGEST and DIGEST-MD5? DIGEST-MD5 requires client side nonce to be same on re-auth while HTTP DIGEST doesn't have this restriction. Do we care? Should we make them the same? Security issues one way or other? Check with ekr. "SHOULD" vs "MUST" verify authorization ID? It's really up to the application profile; will revise to use non-normative form. AES mandatory to implement? Simon had pointed out some problems with RC4. Any objections to AES counter mode mandatory? No objections. The document uses HTTP ABNF which has extra constructs from standard ABNF; linear whitespace differences, etc. Removing pieces of HTTP ABNF which were in common with standard ABNF. Some coordination possible with HTTP people; HTTP ABNF might become a separate document. CRAM-MD5: ========= Sam sees no applicability statement in latest CRAM-MD5 draft; Kurt will write one. GS2: ==== Simon Josefsson leads discussion via Jabber Main open issue is channel bindings. Sam and others feel that channel bindings to TLS should be specified in a general way and not in this document and not in this WG. Nico kind of has an individual submission relating to this. TLS PRF is probably the way to handle channel bindings. Lengthy discussion about whether TLS implementations provide access to PRF, also whether to use some hash of TLS finished messages.