[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10                              
SASL Working Group                                     L. Nerenberg, Ed.
Internet-Draft                                           Orthanc Systems
Obsoletes: RFC2195 (if approved)                         August 21, 2005
Expires: February 22, 2006

                      The CRAM-MD5 SASL Mechanism

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on February 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document defines a simple challenge-response authentication
   mechanism, using a keyed MD5 digest, for use with the Simple
   Authentication and Security Layer (SASL).

Nerenberg               Expires February 22, 2006               [Page 1]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The CRAM-MD5 SASL Mechanism  . . . . . . . . . . . . . . . . .  3
   3.  Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Normative References . . . . . . . . . . . . . . . . . . .  5
     5.2.  Informative References . . . . . . . . . . . . . . . . . .  6
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . .  6
     A.1.  IMAP4  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       A.1.1.  Example 1: Simple IMAP . . . . . . . . . . . . . . . .  6
       A.1.2.  Example 2: IMAP4 with embedded spaces  . . . . . . . .  7
       A.1.3.  Example 3: IMAP4 with Unicode characters . . . . . . .  7
     A.2.  ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
       A.2.1.  Example 4: Simple ACAP . . . . . . . . . . . . . . . .  8
   Appendix B.  IANA Considerations . . . . . . . . . . . . . . . . .  8
   Appendix C.  Contributors  . . . . . . . . . . . . . . . . . . . .  8
   Appendix D.  Changes since RFC 2195  . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

Nerenberg               Expires February 22, 2006               [Page 2]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

1.  Introduction

   This document defines a simple challenge-response authentication
   method, using a keyed MD5 [RFC2104] digest, for use with the Simple
   Security and Authentication Layer (SASL) [I-D.ietf-sasl-rfc2222bis].
   The mechanism name associated with CRAM-MD5 is 'CRAM-MD5'.

   This mechanism is an improvement over plain text authentication
   schemes, such as the SASL PLAIN [I-D.ietf-sasl-plain] mechanism, in
   that it transmits the clients' authentication credentials in a secure

   This mechanism does not provide a security layer.

2.  The CRAM-MD5 SASL Mechanism

   The mechanism starts with the server issuing a <challenge>.  The data
   encoded in the challenge contains a presumptively arbitrary string of
   random data.

   The client makes note of the data and then responds with a <response>
   consisting of the <username>, a space, and a <digest>.  The digest is
   computed by applying the keyed MD5 algorithm from [RFC2104] where the
   key is a shared secret and the digested text is the challenge
   (including angle-brackets).  The client MUST NOT interpret or attempt
   to validate the contents of the challenge in any way.

   This shared secret is a string known only to the client and server.
   The digest parameter itself is a 16-octet value which is sent in a
   restricted hexadecimal format (see the <digest> production in
   Section 3).

   When the server receives this client response, it verifies the digest
   provided.  Since the user name may contain the space character, the
   server must take care to ensure the right-most space is recognised as
   the token separating the user name from the digest.  If the digest is
   correct, the server should consider the client authenticated.

   The client MUST prepare the user name and shared secret strings using
   the SASLprep [RFC4013] profile of the Stringprep [RFC3454] algorithm.
   The resulting values MUST be encoded as UTF-8 [RFC2279] strings.  The
   server may store the prepared string instead of, or as well as, the
   unprepared string, so that it does not have to prepare it every time
   it is needed for computation.  However, if the original, unprepared
   string, is not stored, it may render the computed secret to be
   incompatible with a future revisions of SASLprep that support
   currently unassigned code points (compare section 7 of Stringprep).

Nerenberg               Expires February 22, 2006               [Page 3]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

   It is therefor recommended to store the unprepared string in the

3.  Formal Grammar

   The following grammar specification uses the Augmented Backus-Naur
   Form (ABNF) as specified in [RFC2234], and incorporates by reference
   the Core Rules defined in that document.

     challenge  = "<" 3*(%x21-3B / %x3D / %x3F-7E) ">"
                  ; a bracketed string of printing ASCII characters, not
                  ; containing embedded "<" or ">"

     digest     = 32(DIGIT / %x61-66)
                  ; A hexadecimal string, using ONLY lower-case
                  ; letters

     response   = username SP digest

     username   = 1*OCTET
                  ; Must be well-formed UTF-8.

4.  Security Considerations

   It is conjectured that use of the CRAM-MD5 authentication mechanism
   provides replay protection for a session.

   This mechanism does not obscure the user name in any way.
   Accordingly, a server that implements both a clear-text password
   command and this authentication type should not allow both methods of
   access for a given user name.

   Keyed MD5 is chosen for this application because of the greater
   security imparted to authentication of short messages.  In addition,
   the use of the techniques described in [RFC2104] for pre-computation
   of intermediate results make it possible to avoid explicit clear-text
   storage of the shared secret on the server system by instead storing
   the intermediate results which are known as "contexts."  While the
   saving, on the server, of the MD5 context is marginally better than
   saving the shared secrets in clear-text, it is not sufficient to
   protect the secrets if the server itself is compromised.
   Consequently, servers that store the secrets or contexts must both be
   protected to a level appropriate to the potential information value
   in the data and services protected by this mechanism.  In other
   words, techniques like this one involve a trade-off between
   vulnerability to network sniffing and I/O buffer snooping and

Nerenberg               Expires February 22, 2006               [Page 4]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

   vulnerability of the server host's databases.  If one believes that
   the host and its databases are subject to compromise, and the network
   is not, this technique (and all others like it) is unattractive.  It
   is perhaps even less attractive than clear-text passwords, which are
   typically stored on hosts in one-way hash form.  On the other hand,
   if the server databases are perceived as reasonably secure, and one
   is concerned about client-side or network interception of the
   passwords (secrets), then this (and similar) techniques are
   preferable to clear-text passwords by a wide margin.

   As the length of the shared secret increases, so does the difficulty
   of deriving it.

   While there are now suggestions in the literature that the use of MD5
   and keyed MD5 in authentication procedures probably has a limited
   effective lifetime, the technique is now widely deployed and widely
   understood.  It is believed that this general understanding may
   assist with the rapid replacement, by CRAM-MD5, of the current uses
   of permanent clear-text passwords in many protocols.  This document
   has been deliberately written to permit easy upgrading to use SHA (or
   whatever alternatives emerge) when they are considered to be widely
   available and adequately safe.

   Even with the use of CRAM-MD5, users are still vulnerable to active
   attacks.  An example of an increasingly common active attack is 'TCP
   Session Hijacking' as described in CERT Advisory CA-95:01.

   CRAM-MD5 does not authenticate the server and does not include a
   client-supplied nonce.  As a result, it is possible to construct a
   server with a fixed challenge string that has pre-computed the hashes
   for all possible passwords up to a certain length (or from a
   dictionary).  Such a server could then immediately determine the
   user's password if it is sufficiently short.

5.  References

5.1.  Normative References

              Melnikov, A., "Simple Authentication and Security Layer
              (SASL)", draft-ietf-sasl-rfc2222bis-11 (work in progress),
              June 2005.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

Nerenberg               Expires February 22, 2006               [Page 5]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              December 2002.

   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
              and Passwords", RFC 4013, February 2005.

5.2.  Informative References

              Zeilenga, K., "The Plain SASL Mechanism",
              draft-ietf-sasl-plain-08 (work in progress), March 2005.

   [RFC2244]  Newman, C. and J. Myers, "ACAP -- Application
              Configuration Access Protocol", RFC 2244, November 1997.

              4rev1", RFC 3501, March 2003.

Appendix A.  Examples

   The examples in this appendix DO NOT form part of the specification.
   Where conflicts exist between the examples and the formal grammar or
   the normative text in Section 2, the latter are authoritative.

A.1.  IMAP4

   These examples show the use of the CRAM-MD5 mechanism with the IMAP4
   [RFC3501] AUTHENTICATE command.  The base64 encoding of the
   challenges and responses is part of the IMAP4 AUTHENTICATE command,
   and not part of the CRAM-MD5 specification itself.

A.1.1.  Example 1: Simple IMAP

   In this example the shared secret is the string 'tanstaaftanstaaf'.

     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+
     C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3
     S: A0001 OK CRAM-MD5 authentication successful

Nerenberg               Expires February 22, 2006               [Page 6]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

   Hence, the keyed MD5 digest is produced by calculating

     MD5((SASLprep(tanstaaftanstaaf) XOR opad),
         MD5((SASLprep(tanstaaftanstaaf) XOR ipad),

   where ipad and opad are as defined in RFC 2104 and the string shown
   in the challenge is the base64 encoding of
   '<1896.697170952@postoffice.example.net>'.  The shared secret is
   null-padded to a length of 64 bytes.  If the shared secret is longer
   than 64 bytes, the MD5 digest of the shared secret is used as a 16
   byte input to the keyed MD5 calculation.

   This produces a digest value (in hexadecimal) of
   '3dbc88f0624776a737b39093f6eb6427'.  The user name is then prepended
   to it, forming 'joe 3dbc88f0624776a737b39093f6eb6427', which is then
   base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE
   command yielding 'am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3'.

A.1.2.  Example 2: IMAP4 with embedded spaces

   This example uses the user name 'Ali Baba' and the shared secret
   'Open, Sesame'.  It illustrates that both user names and passwords
   may contain non-alphanumeric characters.

     S: <68451038525716401353.0@localhost>
     C: Ali Baba 6fa32b6e768f073132588e3418e00f71

A.1.3.  Example 3: IMAP4 with Unicode characters

   This example demonstrates the processing of Unicode strings.  The raw
   user name is 'Al<U+00AA>dd<U+00AD>in<U+00AE>' where <U+00AA> is the
   Unicode Latin symbol <FEMININE ORDINAL INDICATOR>, <U+00AD> is <SOFT
   HYPHEN>, and <U+00AE> is the <REGISTERED SIGN>.  Preparing the raw
   user name with SASLprep returns 'Aladdin<U+00AE>' which we then
   encode into the UTF-8 string 'Aladdin\xC2\xAE' (shown here and below
   using C-style string format notation).  As before, the shared secret
   is 'Open, Sesame'.

     S: <92230559549732219941.0@localhost>
     C: Aladdin\xC2\xAE 9950ea407844a71e2f0cd3284cbd912d

A.2.  ACAP

   An example of using CRAM-MD5 with ACAP [RFC2244].

Nerenberg               Expires February 22, 2006               [Page 7]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

A.2.1.  Example 4: Simple ACAP

   This example uses the user name 'joe' and the shared secret

    S: * ACAP (IMPLEMENTATION "Infotrope ACAP Server, version 0.1.3,
        Copyright 2002-2004 Dave Cridland <dave@cridland.net>")
    S: + {43}
    S: <2262304172.6455022@gw2.gestalt.entity.net>
    C: {36+}
    C: joe 2aa383bf320a941d8209a7001ef6aeb6
    S: AUTH OK "You're logged in as joe. Frooby."

Appendix B.  IANA Considerations

   It is requested that the Internet Assigned Numbers Authority (IANA)
   update the SASL Mechanism Registry entry for CRAM-MD5 to refer to
   this document.

   To: iana@iana.org
   Subject: Updated Registration of SASL CRAM-MD5 mechanism.

   SASL mechanism name: CRAM-MD5
   Security considerations: See RFC XXXX
   Published specification: RFC XXXX
   Person & email address to contact for further information:
       Lyndon Nerenberg <lyndon+rfc-crammd5@orthanc.ca>
       IETF SASL WG     <ietf-sasl@imc.org>

Appendix C.  Contributors

   The CRAM-MD5 mechanism was originally specified in RFC 2095, IMAP/POP
   AUTHorize Extension for Simple Challenge/Response.  The authors of
   that document -- John C. Klensin, Paul Krumviede, and Randy Catoe --
   are to be credited with the design and specification of CRAM-MD5, and
   they are the original authors of the majority of the text in this
   document.  This memo serves only to re-state CRAM-MD5 within the
   formal context of SASL, which specification it preceded by several

   Dave Cridland and Simon Josefsson contributed updated examples.

Nerenberg               Expires February 22, 2006               [Page 8]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

Appendix D.  Changes since RFC 2195

   The syntax of the <challenge> has been relaxed.

   Both the user name and the shared secret (password) must be prepared
   using SASLprep, and the resulting values encoded as UTF-8 strings.

Nerenberg               Expires February 22, 2006               [Page 9]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

Author's Address

   Lyndon Nerenberg (editor)
   Orthanc Systems
   304 - 1755 Robson Street
   Vancouver, BC  V6G 3B7

   Email: lyndon+rfc-crammd5@orthanc.ca

Nerenberg               Expires February 22, 2006              [Page 10]

Internet-Draft         The CRAM-MD5 SASL Mechanism           August 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Nerenberg               Expires February 22, 2006              [Page 11]