Last Modified: 2003-06-26
| Done | Submit revised SASL (+ EXTERNAL) I-D | |
| Done | Submit revised SASL ANONYMOUS I-D | |
| Done | Submit revised SASL PLAIN I-D | |
| Done | Submit revised SASL CRAM-MD5 I-D | |
| Done | Submit revised SASL DIGEST-MD5 I-D | |
| Jan 03 | Submit revised SASL GSSAPI I-D | |
| Jun 03 | Submit Implementation Report | |
| Done | Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with Implementation Report to IESG for consideration as a Draft Standard | |
| Jul 03 | Submit revised SASL GSSAPI I-D to IESG for consideration as a Proposed Standard | |
| Aug 03 | Revise charter or conclude |
IETF SASL WG meeting Minutes ========================== Tuesday 15 July 2003 3:45pm chairs: Sam Hartman <hartmans@mit.edu> Kurt Zeilenga <kurt@openLDAP.org> scribe: Luke Howard <lukeh@padl.com> 2222bis ======= - Alexei Melnikov noted that he has published a subsequent revision of 2222bis; minor editorial issues remain - Clarification of empty authorization identities - Alexei will do a final revision of the document in the first week of August after which it can go to last call saslprep ======== - Sam noted that current belief is that this will meet the needs of the Kerberos community - The saslprep document is to be revised to include informational mapping tables but is otherwise ready for last call. New revision is expected shortly after the meeting and the last call will follow shortly after it is announced. DIGEST-MD5 ========== - DIGEST-MD5: Alexei noted that since the last revision he has made the following changes: - Clarifications regarding character sets and authorization vs authentication identities - reference to saslprep the last revision has been updated - Clarified RC4 cipher state is not reset between packets - merged AES cipher document with this one - no changes to solve the AES CBC mod attack:requested text be contributed once a solution is found. - The working group decided that AES for digest-md5 will use random IVs rather than counter mode. Counter mode is harder to implement correctly. - Questions from Sam regarding mandatory to implement ciphers: what should it be (if one is not already required)? - Sam believes there will be interest in making RC4 mandatory to implement because it is implemented now; there is no security reason to not do so that he was aware of - Kurt noted a question as to whether security layers were mandatory to implement; not wearing his chair hat he suggested that at least integrity should be mandatory, Alexei noted that many mail clients do authentication only - Chris Newman suggested that layers should not be mandatory because we already have TLS; suggest that vendors may remove support for DIGEST-MD5 entirely due to engineering cost of implementing layers Kurt suggested SHOULD implement integrity and that security considerations should note that you are subject to MITM without TLS or layers Noted that CRAM-MD5 is subject to the "evil server" attach which DIGEST-MD5 is not because there is a client nonce; also DIGEST-MD5 being compatible with HTTP digest has advantages. ie. there are sufficient advantages over CRAM-MD5 in spite of the lack of layers being mandatory to implement Sam asked for consensus for deprecating both DES and triple DES. There were no objections, nor to taking them out of the document. Sam suggested that we note in the Security Considerations or Changes Since section as to why these were deprecated (preference for latter section) GSSAPI ====== - Sam noted draft was "eaten by the secretariat" - Plan is to move forward on it -- 00 to appear "soon" CRAM-MD5 ======== - A version with saslprep references is available SASL Applicability Statement ============================ - Keith Burdis agreed to submit an SASL applicability statement as an individual submission. His document will include comparisons of the various sasl mechanisms and their security properties. Sam agreed to propose an outline for the document. The working group will discuss rechartering to include this document after the first |