Simple Authentication And Security Layer (SASL) IETF70, Vancouver, BC, Canada Wednesday, December 5, 2007, at 1300-1500 ========================================= Chairs: Tom Yu Kurt Zeilenga DRAFT MINUTES ============= Thanks to Jeff Hutzelman for scribing. Jabber logs: http://www.ietf.org/meetings/ietf-logs/sasl/2007-12-05.html Document Status: draft-ietf-sasl-crammd5-09 - needs writeup draft-ietf-sasl-gs2-09 - needs publication request draft-ietf-sasl-rfc2831bis-12 - (to Historic) draft-cridland-sasl-hexa-00 - merged with SCRAM draft-josefsson-password-auth-00 - expired draft-melnikov-digest-to-historic-00 - to WGLC draft-newman-auth-scram-05 - new rev. submitted, not yet in repos. draft-zeilenga-sasl-yap-02 - independent submission Due to the chairs' errors, CRAM is still missing WGLC writeup. Kurt will follow up. Sam did AD review on GS2; he has some issues regarding detection of channel binding failure. Sam has replied to Simon's comment on this subject, but is waiting for a reply from Simon. Kurt will continue to pursue YAP as an independent submission. Sam will ask the WG about conflicts when the RFC Editor makes pre-publication contact with the IESG about YAP. If the WG doesn't take it into the charter, you can't say it conflicts forever. The question is whether to delay the publication of YAP until whatever password-based mech in the WG is done. One reason to do this is if you think that publishing YAP first will confuse the market. Kurt as author will support whatever the WG decides. Sam says that since we know this is coming, unless the WG says otherwise before YAP reaches the IESG, he'll assume that the WG doesn't want to delay it. If you think delay is needed, speak up. Nico Williams asks whether it would be possible for YAP to be a mode of SCRAM; Kurt doesn't think so. YAP depends on having unique channel bindings and is designed as a one-message protocol; SCRAM is designed to support standalone mode and requires multiple messages. Sam notes that a problem with YAP is that it sends a password equivalent; he would rather it be salted. Kurt made it unsalted to avoid dependency on authentication ID; in a one-message protocol there is nothing to available to salt with. Chris Newman says he would rather YAP and SCRAM be separate; you could combine them under one name, but it would really be separate mechs, and just make both more complicated. Some further discussion about optimistic negotiation and its non-existence in SASL. Simon Josefsson has indicated he is not interested in purusing his password-based mech draft at this time. [He has since clarified to the list that he meant that he was not going to include the SASL/GS2 mappings due to perceived lack of interest.] Sam asks if there are any differences between Simon's draft and SCRAM that anyone cares about. Kurt thought the idea was to take concepts from SCRAM and wrap them in GS2. Sam replies that we did agree to do that, but Simon's proposal has been presented to the WG in this space and hasn't been considered, and you have to consider the proposals presented to you. It's sounding like Simon is saying he doesn't care much. If this doesn't have any other features over SCRAM, maybe you can take SCRAM, take Simon's text about wrapping in GS2, and use it to meet the deliverable. Chris Newman says he doesn't think the proposal is complete until you can store the credentials in one of the common credential stores out there (LDAP, RADIUS). He has looked at Simon's PW auth draft and there are basically 3 paragraphs that you could copy into SCRAM to make ita GS2 mechanism. Various people joke about using a preimage attack on MD5 to generate an OID that produces an interesting GS2-* mechanism name. Abhijit Menon-Sen submitted a new revision of SCRAM which includes some material from Dave Cridland. This revision has not yet reached the repository. Alexey Melnikov relays some questions from Abhijit about protecting secret channel binding data. Sam says that if some channel binding type requires confidentiality, and is used with a channel that doesn't provide confidentiality, then the upper layer must provide confidentiality if it's going to be secure. If the SASL mech doesn't provide confidentiality for channel bindings, then confidential channel bindings must not be used with that SASL mech over channels which don't provide confidentiality. Someone interjects, "Doctor, it hurts when I do this!" Some further discussion happens about channel bindings. Answer for Abhijit: "Do what GS2 does". Alexey will produce text about how to make SCRAM into a GS2 mechanism (probably based on text from Simon's expired draft); Nico Williams and Chris Newman will review. Nico is also willing write about how to turn SCRAM into a full GSS-API mechanism. We will slip milestones about 4 months for most items (due to holidays, not 3 months). Can WGLC on "digest-to-historic" immediately. Frank Ellerman brings up the md5-sess incompatibility between 2831 vs 2617+erratum. Frank is welcome to submit the comment during WGLC, preferrably with specific suggested text. Open Microphone: Mark Crispin has concerns with how certain IMAP implementations handle SASL vs legacy non-SASL auth; issue is larger than SASL and might be more appropriate for an IMAP spec. revision. Kurt notes that this sort of thing is also a problem with LDAP. Jeff Hutzelman notes that it is a problem for legacy protocols, and you need to specify the answer for each legacy protocol that supports SASL, but such protocols should not leave it up to the implementation, which is what causes problems for IMAP. [Crispin adds FTP, SMTP, etc.] Milestones: Done initial I-D for DIGEST-MD5 to Historic Done WGLC I-D for DIGEST-MD5 to Historic Feb 08 initial impl. report questionnaire Feb 08 initial RFC4422bis Feb 08 initial I-D for DIGEST-MD5 successor Feb 08 DIGEST-MD5 to Historic I-D to IESG Mar 08 send impl. report questionnaire Apr 08 compile impl. questionnaire responses Jun 08 WGLC RFC4422bis Jun 08 WGLC DIGEST-MD5 successor Jul 08 discuss impl. questionnaire responses Aug 08 final impl. report Aug 08 RFC4422bis to IESG Aug 08 DIGEST-MD5 successor to IESG