2.6.10 Simple Authentication and Security Layer (sasl)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

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: ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and EXTERNAL. This work will 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 draft-ietf-cat-sasl-gssapi.

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
Done  Submit revised SASL GSSAPI I-D
Jan 04  Submit SASL (+ EXTERNAL), SASLprep, ANONYMOUS, PLAIN to IESG for consideration as Proposed Standards
Feb 04  Submit CRAM-MD5 to IESG for consideration as a Proposed Standard
Mar 04  Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard
May 04  Submit GSSAPI to IESG for consideration as a Proposed Standard
Jun 04  Provide implementation report plan (with milestones)
Aug 04  Revise charter or conclude
  • - draft-ietf-sasl-anon-03.txt
  • - draft-ietf-sasl-plain-04.txt
  • - draft-ietf-sasl-rfc2831bis-03.txt
  • - draft-ietf-sasl-saslprep-05.txt
  • - draft-ietf-sasl-rfc2222bis-06.txt
  • - draft-ietf-sasl-crammd5-02.txt
  • - draft-ietf-sasl-gssapi-00.txt
  • No Request For Comments

    Current Meeting Report

    Sasl Working Group IETF 59 Minutes
    Chairs: Sam Hartman <hartmans@mit.edu>
            Kurt Zeilenga <kurt@openLDAP.org>
    The SASL working group met for an hour at IETF 59.  The primary 
    objective of the meeting was to determine next steps for RFC 2222bis.
    The chairs are concerned that the document has not received 
    sufficient review.  The chairs will contact the apps and security areas and 
    ask for review of the specification before last call.
    Kurt Zeilenga raised several issues on the mailing list.  Most of these 
    were resolved before the meeting; Kurt will check future versions of the 
    draft to confirm resolution.
    One of Kurt's issues that is not resolved is the handling of security 
    layers for multiple reauthentications.  At IETF 58, we decided not to 
    change the protocol because of this threat, but Kurt raised concerns about 
    the wording of the security consideration.  During this discussion Sam 
    Hartman realized this attack is apparently an instance of a more general 
    attack.  Sam will confirm this and propose text on the list.
    Bob Morgan described his concerns about the confusion between 
    authentication identity and authorization ID.  The sense of the room was 
    that while we want to be as clear as possible, both concepts are 
    important and we need to keep both terms.  This discussion is still open on 
    the list.
    A new document will be published  shortly after the meeting.  There will be a 
    need for at least one more revision, slated for early April before a last 
    call.  We hope to have the base spec to the IESG by May; this is a 
    milestone slip.
    Bob raised concerns about how RFC 2119 language such as MUST and MAY are 
    used in this document.  He is concerned that some keywords are 
    addressed to implementations and others to future 
    specifications.  He is not sure that RFC 2119 language should be used for 
    requirements on future specifications.  Kurt believes that it is 
    important to make sure readers know what keywords apply to.  Examples of 
    ways to do this include separating language for profile 
    requirements from language for implementation imperatives.  No 
    resolution was reached on the appropriateness of RFC 2119 language for 
    purposes other than implementation imperatives.
    ALexey Melnikov still needs input on use of stringprep and saslprep in 
    digest-md5.  There was discussion of dropping support for ISO 8859-1 and 
    claiming that all strings are UTF8.  This will be resolved on the list.  
    Sam agreed to review the AES mode for digest-md5.  The working group 
    previously agreed to use explicit IVs to avoid adaptive chosen 
    plaintext attacks, but ALexey has two alternative wire formats for 
    explicit IVs.
    We hope to have digest-md5 last called by July.  Alexey thinks this is very 


    None received.