2.6.17 Simple Authentication and Security Layer (sasl)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27


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 05  Submit SASL (+ EXTERNAL) to the IESG for consideration as a Proposed Standard
Jun 05  Submit CRAM-MD5 to IESG for consideration as a Proposed Standard
Jul 05  Submit DIGEST-MD5 to IESG for consideration as a Proposed Standard
Aug 05  Submit GSSAPI to IESG for consideration as a Proposed Standard
Oct 05  Provide implementation report plan (with milestones)
Nov 05  Revise charter or conclude


  • draft-ietf-sasl-anon-05.txt
  • draft-ietf-sasl-plain-08.txt
  • draft-ietf-sasl-rfc2831bis-06.txt
  • draft-ietf-sasl-rfc2222bis-11.txt
  • draft-ietf-sasl-gssapi-02.txt

    Request For Comments:

    RFC4013 Standard SASLprep: Stringprep profile for user names and passwords

    Current Meeting Report

    Simple Authentication and Security Layer (SASL) WG
    Tuesday, August 2, 2005

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

    Thanks to Love Hornquist-Astrand, Jeffrey Altman, and Jeffrey Hutzelman for scribing.

    Document status:

    Tom somehow forgets that anon was already approved.

    CRAM-MD5 expired. Sam Hartman desires to publish it as Historic. In any case, the document needs a better applicability statement. Some discussion ensues about whether Historic or Informational status is more appropriate. There is consensus to take the document off of the standards track.

    Simon Josefsson brings up the question of whether SASLprep can be added to the protocol (for migration support) and still have the document issued as Historic. Tony Hansen indicates that existing implementations already do SASLprep on CRAM-MD5, so adding saslprep support would be documenting existing practice. Sam thinks it needs to go Informational if internationalization support is added. Someone points out that we could publish as Informational and immediately move to Historic, whereupon Sam withdraws his comment.

    Alexey has updated the GSSAPI mech document. SASLprep needs to be addressed. Some discussion ensues about roundtrip optimization. It is pointed out that there are actually two specifications in the GSSAPI mech document: the legacy mechanisms krb5 and SPNEGO, and the family of mechansims whose names are produced by hashing. jhutz suggests removing the non-legacy mechanisms from this document. Consensus that optimization is important. Consensus for performing the document split.

    PLAIN mechanism revised; Kurt and Sam still need to talk about some issues.

    SASL base:

    SASL base specification (rfc2222bis) has been to WGLC. It received some responses, many editorial. Some misunderstandings about Stringprep remain. Kurt acknowledges that the text still has clarity issues. jhutz indicates that people reading the document, as well as other SASL documents, get really confused about the distinction between authentication and authorization names, and about whether responsibility for handling each of these names lies with the application implementation or with the mechanism implementation. A straw poll indicates that about 7 people find SASL names confusing, while about 2 don't.


    DIGEST-MD5 re-issued recently. Alexey sent mail to the list requesting comment on recent changes, and about where SASLprep is done. Discussion ensues about CBC mode vs counter mode. We believe counter mode is good. Alexey wants help with describing counter mode. Consensus exists to drop CBC that does not send random IV in every packet (proposal #2). Simon Josefsson proposes using a mode with combined integrity checking such as CCM/GCM. Sam recommends checking IPR carefully. Sam also suggests putting the combined mode in a separate document, and to just complete the work.

    Philip Guenther brings up Christian Huitema's presentation to the Applications Area about CRAM-MD5 and other challenge-response protocols being insecure due to offline attacks. Question of whether we should recommend running DIGEST-MD5 over TLS. Nico describes how channel bindings might be useful for this purpose. Some discussion of whether extending DIGEST-MD5 to use channel bindings is within our charter. Simon questions whether DIGEST-MD5 is secure compared to CRAM-MD5, considering that there is no formal security proof for the ad-hoc hash construction in DIGEST-MD5, while there is for HMAC, which CRAM-MD5 uses. Sam says he can't prove it, but believes DIGEST-MD5's construction to be similar to CRAM-MD5 in quality.

    Sam notes DIGEST-MD5 is relatively extensible. digest-md5 or digest-sha1? It's great if digest-md5 is done, but will it be secure? If digest-md5 is delayed, plain passwords may win.

    Roger Harrison indicates that LDAP community wants a strong mandatory-to-implement security mechanism, and that they have some uncertainty about whether algorithms are secure given recent discoveries about hashes. Sam points out that the challenge-response issues are separate from the hash issues, and the recent attacks are specifically against hash algorithms; we know how to protect against dictionary attacks. Kurt notes that Applications Area has had discussions whether it's time to deprecate challenge-response sent in the clear.


    SASL-base to iesg by end of Aug.

    discuss future of DIGEST-MD5

    discuss future of CRAM-MD5

    text for CRAM-MD5 applicability

    split GSSAPI SASL mech -> legacy (krb5 & spnego) vs other GSSAPI

    GSSAPI SASL legacy mech ready by Oct.

    other revised milestones to be discussed on list


    None received.