Simple Authentication and Security Layer (SASL) WG IETF 67 Tuesday, November 7, 2006, at 1740-1950 Chairs: Tom Yu Kurt Zeilenga ==================== Thanks to Chris Newman and Lisa Dusseault for scribing. Summary of consensus points and action items: ============================================= * Chris Newman and Jeff Altman will do reviews of DIGEST-MD5 by end of Nov. HTTP people will be contacted too. * Lyndon will incorporate new CRAM-MD5 text by end of Nov. * Alexey will verify that GS2 last call issues are addressed in current doc rev. * People interested in supporting non-integrity GSS mechs in GS2 should write text. * Alexey, Jeff Altman, and Kurt will independently compute the krb5 GS2 mechanism name for verification. * Kurt will form a design team to determine what's needed for the interop reports. Updated Milestones: Nov 2006 WGLC for CRAM-MD5 Nov 2006 WGLC for GS2 Nov 2006 WGLC for DIGEST-MD5 Dec 2006 CRAM-MD5 to IESG Dec 2006 GS2 to IESG Dec 2006 DIGEST-MD5 to IESG Jun 2007 Implementation report plan Jul 2007 Revise charter or conclude Document Status: ================ CRAM-MD5 - needs new rev GS2 - some open issues GSSAPI - RFC Editor queue PLAIN - RFC 4616 rfc2831bis (DIGEST-MD5) - some open issues Only minor open issues in DIGEST-MD5; we will coordinate with HTTP people to investigate possible HTTP compatibility issues. Sam Hartman says that HTTP digest (RFC2617) is under review on the HTTP mailing list to determine if it should be updated or obsoleted. We need to make sure that HTTP digest revision is kept compatible with DIGEST-MD5. Sam's suggestions are: * share authentication db between HTTP digest and DIGEST-MD5 * similar security properties * share interactions with AAA infrastructure * get people from this WG who know DIGEST-MD5 to work with that not-a-WG Alexey thinks minimum changes to HTTP digest are to update ABNF and introduce UTF-8; Sam suggests cut & paste of channel binding support, etc. Chris Newman and Jeff Altman volunteer to review DIGEST-MD5. CRAM-MD5 needs new revision with Kurt's proposed applicability text and other minor changes. interop concerns? Kurt thinks lack of normalization could be a problem -- should at least be noted. Chris is concerned about a standards body stating that interop problems exist when none have been observed in practice. Kurt thinks it's important to note that there is a potential problem. Sam suggests rewording "interoperability concerns" to read as "internationalization concerns". GS2 last called in September; some issues raised. Revision published; no comment to revised copy. Kurt thinks there's consensus. Alexey has action item to verify that latest GS2 revision addresses issues raised during last call; agrees to do this soon. Support for non-integ mechanisms? Non-integrity mechanisms can't protect channel bindings. Sam says we want people to write GSS mechs in preference to writing SASL mechs; thus we should support GSS non-integrity mechs. [Side discussion: consensus for preferring writing GSS mech over SASL mechs? jhutz says that there is consensus: write things as GSS mechs so they can be used with applications that can't use SASL. Sam hopes there is consensus and will do everything ethical he can to make sure standards track SASL mechs which aren't GSS mechs aren't chartered and aren't individually sponsored. Chris doesn't understand GSSAPI; doesn't know how to design a GSS mech. He understands SASL well enough to design a SASL mech. Sam says if you get into situation where you are trying to design a GSS mech, know how to do SASL mech, and can't get help needed to turn into gss mech -- he will be more lenient. Chris: if there were help to define GSS binding of a mech, he wouldn't object, but would want SASL binding as well to bypass complexity. Sam: important thing -- don't _need_ to implement it this way.] Alexey suggests that the people who want non-integ GSS mechs in GS2 be the ones to write the text. Simon's proposed options: (1) publish current revision; revise GS2 or do "GS0" later; (2) revise GS2 now (need volunteers). Consensus to do (1) unless (2) happens soon (next few weeks). As an individual, Sam feels this is reasonable. Extended discussion ensues about GS2 and channel bindings. Simon Josefsson has some concerns about implementability of TLS channel bindings due to lack of adequate specification. Simon feels that it's a problem if you can't implement GS2 with channel bindings today -- hasn't been implemented in GNU SASL is because other htings aren't specified and in particular if we don't know how to do bindings in TLS we can't implement GS2 with channel bindings to TLS; jhutz doesn't feel it's a problem because it's possible to implement GS2 w/o channel bindings to particular channel type; as implementor Simon wants reassurance it's actually possible. We might want to wait on moving GS2 forward until we have an example of this being implemented. Kurt: push into queue, tell IESG to hold for feedback from implementors. Sam and jhutz would like to see an update to SASL base covering channel bindings rather than individual SASL mechs specifying how to do channel bindings, but Sam won't block GS2 for it. Simon's options: (1) reference TLS channel bindings directly; or (2) improve other docs and possibly writing new doc on channel bindings in GS2 or SASL in general. Consensus that (1) isn't viable. Consensus that keeping GS2 as is (referencing williams-on-channel bindings) is reasonble. Should WG require implementation experience before recommending GS2 to IESG? Simon seems to want at least one channel binding in the framework specified before progressing GS2. Sam is happy to hold documents for such. Lisa just told an apps WG they couldn't publish a Proposed Standard that was part of an incomplete set of specifications that couldn't be implemented usefully. Consensus to push doc; it can get held at a later stage pending implementation experience. Volunteers to compute krb5 GS2 mech name? Alexey, Jeff Altman, Kurt.