2.7.14 Simple Authentication and Security Layer (sasl)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


Tom Yu <tlyu@mit.edu>
Kurt Zeilenga <kurt@openLDAP.org>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@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:
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
Done  Submit revised SASL GSSAPI I-D
May 2005  Submit SASL (+ EXTERNAL) to the IESG for consideration as a Proposed Standard
Jun 2005  Submit CRAM-MD5 to IESG for consideration as a Proposed Standard
Jul 2005  Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard
Aug 2005  Submit GSSAPI to IESG for consideration as a Proposed Standard
Oct 2005  Provide implementation report plan (with milestones)
Nov 2005  Revise charter or conclude


  • draft-ietf-sasl-anon-05.txt
  • draft-ietf-sasl-plain-08.txt
  • draft-ietf-sasl-rfc2831bis-07.txt
  • draft-ietf-sasl-rfc2222bis-13.txt
  • draft-ietf-sasl-crammd5-05.txt
  • draft-ietf-sasl-gssapi-03.txt

    Request For Comments:

    RFC4013 Standard SASLprep: Stringprep profile for user names and passwords

    Current Meeting Report

    Simple Authentication and Security Layer (SASL) WG
    IETF 64
    Tuesday, November 8, 2005
    Tom Yu 
    Kurt Zeilenga 
    Thanks to Bob Morgan for scribing.
    Document Status:
    SASL base spec (rfc2222bis) is delayed; hopefully back on track in a
    few weeks.  CRAM-MD5 direction less certain after list discussion.  No
    objections to WGLC for GSSAPI mech, but Sam Hartman reinforces that
    silence is not assent for this particular WGLC.  PLAIN mechanism is
    waiting for Sam to talk with Kurt, but this will wait until after SASL
    base spec is done.  DIGEST-MD5 is making progress.
    We appeared to have prior consensus at IETF63 to take CRAM-MD5 off the
    standards track.  Recent list discussion calls that consensus into
    question.  People seem to be leaning in favor of Informational in
    preference to Historic.  A show of hands indicates a few people remain
    in favor of standards track for CRAM-MD5.  Kurt notes that remaining
    on the standards track requires fixing problems, not just publishing
    current practice, e.g., fixing internationalization, and security
    problems.  Simon Josefsson asks what the security problems are.
    Answer: integrity protection, etc.  Simon asks why we can't just
    recommend mandatory TLS.  Chris Newman thinks Informational is a
    reasonable compromise.  Simon can live with Informational.  A poll of
    people wanting CRAM-MD5 to remain on the standards track shows no
    objections to moving CRAM-MD5 to Informational.
    Kurt would like to see document describe existing practice, but should
    also describe shortcomings of the mechanism, not only the security
    issues, but also the internationalization issues.  Cyrus Daboo [via
    jabber] asks if any of proposed changes to CRAM-MD5 effectively
    require vendors to re-implement.  Kurt replies that fixing
    internationalization requires SASLprep, which is a change.  Tony
    Hansen suggests that we document why CRAM-MD5 is no longer on the
    standards track.  Chris Newman suggests that the person who is pushing
    for CRAM-MD5 to be taken off the standards track be the one to write
    that text.
    Alexey Melnikov talks about DIGEST-MD5.  Removed AES-CBC proposal with
    explicit separate IV block.  Added text about channel bindings to TLS.
    Started replacing ABNF, referencing new ABNF RFC; ran out of time.
    Perhaps split specification of extended ABNF syntax to separate
    document to HTTP people can use it?
    AES counter mode -- started to write text; needs answers regarding IV
    construction for counter.  Sam notes followup discussion in IETF63
    SAAG in response to WG summary.  You could use combined
    integrity/encryption mode instead.  Not much support on mailing list
    for counter mode.  A poll of the room shows a few people in favor of
    adding AES counter mode to DIGEST-MD5, and no objections.  No
    volunteers for writing text.  Sam is willing to answer questions and
    do review.
    Simon says we should do security layers right or not at all.  (He
    doesn't believe they're widely used.)  Kurt opposes working on
    DIGEST-MD5 without security layers due to application protocol
    requirements for supporting strong authentication and integrity.  Sam
    agrees with both Simon and Kurt; existing CBC proposal meets security
    layer requirements, but possibly not certain performance requirments.
    Document likely won't be approved without security layer.  No
    volunteers obvious for counter mode.  Sam will help find someone to
    work on counter mode.  Tom asks if people are willing to delay the
    document for AES counter mode.
    Alexey notes that AES isn't mandatory to implement.  Sam suggests that
    the issue of RC4 as mandatory cipher be considered to be re-opened.
    Kurt suggests that we postpone discussion of mandatory cipher until
    text is produced describing the cipher suites.
    Issues remain with ISO8859-1 compatibility (backwards compat with HTTP
    servers).  Some HTTP people declare that UTF-8 is the character set
    for HTTP.  Desire for DIGEST-MD5 to share authentication database with
    HTTP-DIGEST.  Simon's implementation uses UTF-8.  Kurt will talk to
    Applications Area people about the problem.  Next revision before end
    of 2005.
    SASL Base:
    Kurt will write next revision during IETF64.  Chris Newman has
    suggested text on how to handle certain errors; no objections.  Also,
    empty server challenge requirement could break things; proposal to
    delete text requiring that challenge be empty.  No objections.  Simon
    has proposed "SHOULD close connection" on detection of mechanism
    downgrade; no objections.  Pekka has raised issues against the
    security considerations section, primarily regarding intermixed
    discussions of multiple security considerations.  Kurt proposes
    splitting discussions; no objections.
    Discussion about IANA considerations, particularly regarding families
    of mechanisms.  Sam asks that if we require IESG approval, to give the
    IESG explicity guidance.  Simon suggests delegation of namespace to
    registrant of mechanism family; no objections.
    Milestone Review:
    [see Action Items below]
    Open Mic:
    Simon asks if GSS includes the family of mechanisms.  Sam says no,
    asks if Simon wants to work on it; Simon agrees.  Initial draft in Feb
    2006.  Note base-32 encoding needs checking with DNSEXT.  To IESG
    around Sep 2006.
    Sam notes that there was a dinner meeting discussion SASL for HTTP.
    There will most likely be a discussion of channel bindings in that
    context, so people should be prepared.  Kurt wants to make sure we
    don't break compatibility, so either new mechansisms, or use
    extensibility features of existing ones.
    Action Items:
    Kurt will talk with Apps Area people about HTTP DIGEST 8859-1 issue
    GSS (krb5 & SPNEGO) WGLC nowish
    SASL base to IESG Dec 2005
    DIGEST-MD5 next rev before Dec 2005
    GSS mech family initial draft Feb 2006
    CRAM-MD5 WGLC around Mar 2006
    DIGEST-MD5 WGLC around Mar 2006
    implementation plan Summer 2006
    GSS mech family to IESG Sep 2006


    SASL base update