2.6.6 Simple Authentication and Security Layer (sasl)

Last Modified: 2003-06-26

Sam Hartman <hartmans@mit.edu>
Kurt Zeilenga <kurt@openLDAP.org>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
Mailing Lists:
General Discussion: ietf-sasl@imc.org
To Subscribe: ietf-sasl-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/ietf-sasl/mail-archive/
Description of Working Group:
The Simple Authentication and Security Layer [RFC2222] provides key
security services to a number of application protocols including BEEP,
IMAP, LDAP, POP, and SMTP. The purpose of this working group is to
shepherd SASL, including select SASL mechanisms, through the Internet
Standards process.

This group will deliver a revised SASL Technical Specification
suitable for consideration as a Draft Standard. This work will be
based upon RFC 2222 and draft-myers-saslrev.

This group will deliver revised Technical Specifications suitable for
consideration as Draft Standards for the following SASL mechanisms:
be based upon RFC 2195, RFC 2222, RFC 2831, draft-zeilenga-sasl-anon,
draft-zeilenga-sasl-plain, draft-nerenberg-sasl-crammd5 and
draft-melnikov-rfc2831bis, and draft-myers-saslrev-xx.txt.

This group will deliver a revised Technical Specification suitable for
publication as Proposed Standard for the GSSAPI family of SASL
mechanisms. This work will be based upon RFC 2222 and

The following areas are not within the scope of work of this WG:

- new features,

- SASL Mechanisms not specifically mentioned above, and

- SASL "profiles".

However, the SASL WG is an acceptable forum for review of SASL-related
submissions produced by others as long as such review does not impede
progress on the WG objectives listed above.
Goals and Milestones:
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
  • - draft-ietf-sasl-anon-02.txt
  • - draft-ietf-sasl-plain-02.txt
  • - draft-ietf-sasl-rfc2831bis-02.txt
  • - draft-ietf-sasl-saslprep-03.txt
  • - draft-ietf-sasl-rfc2222bis-02.txt
  • - draft-ietf-sasl-crammd5-00.txt
  • No Request For Comments

    Current Meeting Report

    IETF SASL WG meeting Minutes
    Tuesday 15 July 2003
    chairs:    Sam Hartman <hartmans@mit.edu> Kurt Zeilenga 
    scribe: Luke Howard <lukeh@padl.com>
    - 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
    - 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: 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 
    - 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)
    - Sam noted draft was "eaten by the secretariat"
    - Plan is to move forward on it -- 00 to appear "soon"
    - 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 


    None received.