2.6.12 Simple Authentication and Security Layer (sasl)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-03-07

Sam Hartman <hartmans@mit.edu>
Kurt Zeilenga <kurt@openLDAP.org>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
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:
JAN 03  Submit revised SASL (+ EXTERNAL) I-D
Done  Submit revised SASL ANONYMOUS I-D
Done  Submit revised SASL PLAIN I-D
JAN 03  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
JUL 03  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-00.txt
  • - draft-ietf-sasl-plain-00.txt
  • - draft-ietf-sasl-rfc2831bis-00.txt
  • - draft-ietf-sasl-saslprep-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes based on notes from Chris Newman and Sam Hartman.
    SASL WG IETF 56 San Francisco
    1. Base spec -- document editor is non-responsive, will assign new 
       Issue: Is security considerations sufficient to meet IESG review?
    2. Anonymous
      went through WG last call, will fix issues raised during last call, will 
    submit with base spec. Sam  Hartman will send a summary of the last call to 
    the working group after reviewing with the editor. 
    3.  Plain/saslprep
      The main issue is the stringprep profile. More review is required, 
    especially of the profile.
      Issue: SASLprep profile should deal with user@domain-name syntax 
    issues.  IN particular many authentication identifiers and 
    authorization  identifiers include domain components. We need to be aware of 
    any differences between nameprep and saslprep and avoid introducing these 
    differences without good reason.  Nameprep works on domain labels, while 
    saslprep works on the string as a whole.  Applications may mistakenly 
    perform nameprep on input before giving it to SASL.
      Issue: Want SASLprep and Kerberos prep to use the same namespace.
      Discussion of authorization  names vs authentication names.  Larry 
    Greenfield believes that applications will use the same profile for both.  
    Kurt pointed out that  LDAP is an example of an application with 
    significantly different requirements for authorization identifiers than 
    authentication identifiers.
    3. DIGEST-MD5 issues  Alexey is editor
      three open issues:
      1. Whether we want to merge AES cipher?
         Postpone selection of mandatory-to-implement and adding AES until we 
    have done a security analysis.  Security analysis will be posted to the 
    working group list.
      2. Add SASLprep.
      3. then ready for last call.
    4. CRAM-MD5 draft   Lyndon is editor
      1. add SASLprep, then done.
    5. GSSAPI issues    
      1. Last call the base32 draft, then last call.
      2. An editor needs to be selected.
    6. Individual submissions
      Authors of SRP document want to last call it.
        Issue: Sam Hartman believes it should have structure which included an 
    OID in front so it could be used as a GSSAPI mechanism. 


    None received.