SASL Working Group L. Nerenberg, Ed. Internet-Draft Orthanc Systems Obsoletes: RFC2195 (if approved) July 8, 2004 Expires: January 6, 2005 The CRAM-MD5 SASL Mechanism draft-ietf-sasl-crammd5-03 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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-Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract 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 January 6, 2005 [Page 1]
Internet-Draft The CRAM-MD5 SASL Mechanism July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The CRAM-MD5 SASL Mechanism . . . . . . . . . . . . . . . . . 3 3. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Example 1: IMAP4 . . . . . . . . . . . . . . . . . . . . . 4 4.2 Example 2: IMAP4 with embedded spaces . . . . . . . . . . 5 4.3 Example 3: IMAP4 with Unicode characters . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 6.2 Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 B. Changes since RFC 2195 . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Nerenberg Expires January 6, 2005 [Page 2]
Internet-Draft The CRAM-MD5 SASL Mechanism July 2004 1. Introduction This document defines a simple challenge-response authentication menthod, using a keyed MD5 [RFC2104] digest, for use with the Simple Security and Authentication Layer (SASL) [draft-ietf-sasl-rfc2222bis]. The mechanism name associated with CRAM-MD5 is 'CRAM-MD5'. 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 string consisting of the user name, a space, and a digest. The digest is computed by applying the keyed MD5 algorithm from RFC 2104 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 recognized as the token seperating 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 [draft-ietf-sasl-saslprep] 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). It is therefor recommended to store the unprepared string in the database. Nerenberg Expires January 6, 2005 [Page 3]
Internet-Draft The CRAM-MD5 SASL Mechanism July 2004 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 characters, not ; containing embedded "<" or ">" digest = 32(DIGIT / %x61-66) ; A hexadecimal string, using ONLY lower-case ; letters response = user SP digest user = 1*OCTET 4. Examples The examples in this section 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. 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. 4.1 Example 1: IMAP4 S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] C: A0001 AUTHENTICATE CRAM-MD5 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 S: A0001 OK CRAM-MD5 authentication successful In this example the shared secret is the string 'tanstaaftanstaaf'. Hence, the keyed MD5 digest is produced by calculating MD5((SASLprep(tanstaaftanstaaf) XOR opad), MD5((SASLPrep(tanstaaftanstaaf) XOR ipad), <1896.697170952@postoffice.example.net>)) where ipad and opad are as defined in RFC 2104 and the string shown in the challenge is the base64 encoding of Nerenberg Expires January 6, 2005 [Page 4]
Internet-Draft The CRAM-MD5 SASL Mechanism July 2004 '<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'. 4.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 4.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 5. 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, Nerenberg Expires January 6, 2005 [Page 5]
Internet-Draft The CRAM-MD5 SASL Mechanism July 2004 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 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. Nerenberg Expires January 6, 2005 [Page 6]
Internet-Draft The CRAM-MD5 SASL Mechanism July 2004 6. References 6.1 Normative References [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2234] Crocker, D. 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. [draft-ietf-sasl-rfc2222bis] Melnikov, A., "Simple Authentication and Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-07 (work in progress), March 2004. [draft-ietf-sasl-saslprep] Zeilenga, K., "SASLprep: Stringprep profile for user names and passwords", draft-ietf-sasl-saslprep-09 (work in progress), April 2004. 6.2 Informative References [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. Author's Address Lyndon Nerenberg (editor) Orthanc Systems EMail: lyndon+rfc-crammd5@orthanc.ca Appendix A. 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. Nerenberg Expires January 6, 2005 [Page 7]
Internet-Draft The CRAM-MD5 SASL Mechanism July 2004 Appendix B. Changes since RFC 2195 To Be Done Nerenberg Expires January 6, 2005 [Page 8]
Internet-Draft The CRAM-MD5 SASL Mechanism July 2004 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Nerenberg Expires January 6, 2005 [Page 9]
