3 Network Working Group L. Nerenberg, Editor
4 Internet Draft: The CRAM-MD5 SASL Mechanism Orthanc Systems
5 Document: draft-ietf-sasl-crammd5-01.txt November 2003
9 The CRAM-MD5 SASL Mechanism
14 This document is an Internet Draft and is in full conformance with
15 all provisions of Section 10 of RFC 2026.
17 Internet Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet
22 Internet Drafts are draft documents valid for a maximum of six
23 months and may be updated, replaced, or obsoleted by other docu-
24 ments at any time. It is inappropriate to use Internet Drafts as
25 reference material or to cite them other than as "work in
28 The list of current Internet Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet
30 Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 Copyright 2003, The Internet Society. All Rights Reserved.
35 Please see the Copyright section near the end of this document for
40 This document defines a simple challenge-response authentication
41 mechanism, using a keyed-hash digest, for use with the Simple
42 Authentication and Security Layer (SASL).
44 1. Conventions Used in this Document
46 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
47 in this document are to be interpreted as defined in [KEYWORD].
50 2. CRAM-MD5 Authentication Mechanism
52 This document defines a simple challenge-response [SASL] authenti-
53 cation mechanism, using a [KEYED-MD5] digest, for use with [SASL].
54 The mechanism name associated with CRAM-MD5 is 'CRAM-MD5'.
56 This mechanism does not provide a security layer.
60 Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 1]
62 Internet Draft CRAM-MD5 SASL Mechanism November 2003
65 The data encoded in the challenge contains a presumptively arbi-
66 trary string of random digits, a time-stamp, and the fully-quali-
67 fied primary host name of the server.
69 The client makes note of the data and then responds with a string
70 consisting of the user name, a space, and a "digest." The latter
71 is computed by applying the keyed MD5 algorithm from [KEYED-MD5]
72 where the key is a shared secret and the digested text is the chal-
73 lenge (including angle-brackets). The client MUST NOT interpret or
74 attempt to validate the contents of the challenge in any way.
76 This shared secret is a string known only to the client and server.
77 The "digest" parameter itself is a 16-octet value which is sent in
78 hexadecimal format, using lower-case US-ASCII characters.
80 When the server receives this client response, it verifies the
81 digest provided. Since the user name may contain the space charac-
82 ter, the server MUST scan the client response from right to left;
83 the first space character encountered separates the digest from the
84 user name. If the digest is correct, the server should consider
85 the client authenticated and respond appropriately.
87 The client MUST prepare the user name and shared secret strings
88 using the [SASLPrep] profile of the [StringPrep] algorithm. The
89 resulting values MUST be encoded as UTF-8 [UTF8].
94 The following syntax specification uses the augmented Backus-Naur
95 Form (ABNF) as specified in [ABNF], and incorporates by reference
96 the Core Rules defined in that document.
98 challenge = "<" 1*DIGIT "." 1*DIGIT "@" hostname ">"
100 digest = 32(DIGIT / %x61-66)
101 ; A hexadecimal string using only lower-case
104 hostname = 1*(ALPHA / DIGIT) *("." / "-" / ALPHA / DIGIT)
106 response = user SP digest
113 The examples in this section do NOT form part of the specification.
114 Where conflicts exist between the examples and the formal grammar
115 or specification text, the latter are authoritative.
117 These examples show the use of the CRAM-MD5 mechanism with the
118 IMAP4 AUTHENTICATE command [IMAP4]. The base64 encoding of the
122 Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 2]
124 Internet Draft CRAM-MD5 SASL Mechanism November 2003
127 challenges and responses is part of the IMAP4 AUTHENTICATE command,
128 not part of the CRAM-MD5 specification itself.
130 S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5]
131 C: A0001 AUTHENTICATE CRAM-MD5
132 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
133 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
134 S: A0001 OK CRAM-MD5 authentication successful
136 In this example, the shared secret is the string
140 Hence, the Keyed MD5 digest is produced by calculating
142 MD5((tanstaaftanstaaf XOR opad),
143 MD5((tanstaaftanstaaf XOR ipad),
144 <1896.697170952@postoffice.example.net>))
146 where ipad and opad are as defined in [KEYED-MD5] and the string
147 shown in the challenge is the base64 encoding of
148 <1896.697170952@postoffice.reston.mci.net>. The shared secret is
149 null-padded to a length of 64 bytes. If the shared secret is longer
150 than 64 bytes, the MD5 digest of the shared secret is used as a 16
151 byte input to the keyed MD5 calculation.
153 This produces a digest value (in hexadecimal) of
155 b913a602c7eda7a495b4e6e7334d3890
157 The user name is then prepended to it, forming
159 tim b913a602c7eda7a495b4e6e7334d3890
161 Which is then base64 encoded to meet the requirements of the IMAP4
162 AUTHENTICATE command (or the similar POP3 AUTH command), yielding
164 dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
170 3.1. Normative References
173 Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications:
174 ABNF", RFC2234, Internet Mail Consortium and Demon Internet Ltd.,
178 Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
179 Authentication", RFC 2104, IBM and UCSD, February 1997.
184 Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 3]
186 Internet Draft CRAM-MD5 SASL Mechanism November 2003
190 Bradner, S., "Key words for use in RFCs to Indicate Requirement
191 Levels", BCP 14, RFC2119, Harvard University, March 1997.
194 Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT Labo-
195 ratory for Computer Science and RSA Data Security, Inc., April
199 Myers, J., "Simple Authentication and Security Layer (SASL)," RFC
200 2222, Netscape Communications, October 1997.
203 Zeilenga, K., "SASL String Preparation Profiles", draft-ietf-sasl-
204 saslprep (work in progress)
207 Hoffman, P., M. Blanchet, "Preparation of Internationalized Strings
208 (stringprep)", RFC 3454, IMC and Viagenie, December 2002.
211 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
212 2279, Alis Technologies, January 1998.
214 3.2. Informative References
217 Crispin, M., "Internet Message Access Protocol - Version 4rev1,"
218 RFC 3501, University of Washington, March 2003.
221 4. Security Considerations
223 It is conjectured that use of the CRAM-MD5 authentication mechanism
224 provides replay protection for a session.
226 This mechanism does not obscure the user name in any way. Accord-
227 ingly, a server that implements both a clear-text password command
228 and this authentication type should not allow both methods of
229 access for a given user name.
231 Keyed MD5 is chosen for this application because of the greater
232 security imparted to authentication of short messages. In addition,
233 the use of the techniques described in [KEYED-MD5] for pre-computa-
234 tion of intermediate results make it possible to avoid explicit
235 clear-text storage of the shared secret on the server system by
236 instead storing the intermediate results which are known as "con-
237 texts." While the saving, on the server, of the MD5 "context" is
238 marginally better than saving the shared secrets in clear-text, it
239 is not sufficient to protect the secrets if the server itself is
240 compromised. Consequently, servers that store the secrets or con-
241 texts must both be protected to a level appropriate to the poten-
242 tial information value in the data and services protected by this
246 Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 4]
248 Internet Draft CRAM-MD5 SASL Mechanism November 2003
251 mechanism. In other words, techniques like this one involve a
252 trade-off between vulnerability to network sniffing and I/O buffer
253 snooping and vulnerability of the server host's databases. If one
254 believes that the host and its databases are subject to compromise,
255 and the network is not, this technique (and all others like it) is
256 unattractive. It is perhaps even less attractive than clear-text
257 passwords, which are typically stored on hosts in one-way hash
258 form. On the other hand, if the server databases are perceived as
259 reasonably secure, and one is concerned about client-side or net-
260 work interception of the passwords (secrets), then this (and simi-
261 lar) techniques are preferable to clear-text passwords by a wide
264 As the length of the shared secret increases, so does the diffi-
265 culty of deriving it.
267 While there are now suggestions in the literature that the use of
268 MD5 and keyed MD5 in authentication procedures probably has a lim-
269 ited effective lifetime, the technique is now widely deployed and
270 widely understood. It is believed that this general understanding
271 may assist with the rapid replacement, by CRAM-MD5, of the current
272 uses of permanent clear-text passwords in many protocols. This
273 document has been deliberately written to permit easy upgrading to
274 use SHA (or whatever alternatives emerge) when they are considered
275 to be widely available and adequately safe.
277 Even with the use of CRAM-MD5, users are still vulnerable to active
278 attacks. An example of an increasingly common active attack is
279 'TCP Session Hijacking' as described in CERT Advisory CA-95:01.
281 CRAM-MD5 does not authenticate the server and does not include a
282 client-supplied nonce. As a result, it is possible to construct a
283 server with a fixed challenge string that has pre-computed the
284 hashes for all possible passwords up to a certain length (or from a
285 dictionary). Such a server could then immediately determine the
286 user's password if it is sufficiently short.
289 5. IANA Considerations
291 The SASL Mechanism Registry entry for CRAM-MD5 must be updated to
292 reference this specification.
297 The CRAM-MD5 mechanism was originally specified in RFC 2095,
298 IMAP/POP AUTHorize Extension for Simple Challenge/Response. The
299 authors of that document -- John C. Klensin, Paul Krumviede, and
300 Randy Catoe -- are to be credited with the design and specification
301 of CRAM-MD5. This memo serves only to re-state CRAM-MD5 within the
302 formal context of SASL, which specification it preceded by several
308 Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 5]
310 Internet Draft CRAM-MD5 SASL Mechanism November 2003
313 7. Intellectual Property
315 The IETF takes no position regarding the validity or scope of any
316 intellectual property or other rights that might be claimed to per-
317 tain to the implementation or use of the technology described in
318 this document or the extent to which any license under such rights
319 might or might not be available; neither does it represent that it
320 has made any effort to identify any such rights. Information on
321 the IETF's procedures with respect to rights in standards-track and
322 standards-related documentation can be found in BCP-11. Copies of
323 claims of rights made available for publication and any assurances
324 of licenses to be made available, or the result of an attempt made
325 to obtain a general license or permission for the use of such pro-
326 prietary rights by implementers or users of this specification can
327 be obtained from the IETF Secretariat.
329 The IETF invites any interested party to bring to its attention any
330 copyrights, patents or patent applications, or other proprietary
331 rights which may cover technology that may be required to practice
332 this standard. Please address the information to the IETF Execu-
340 1606 - 10770 Winterburn Road
343 Email: lyndon+rfc-crammd5@orthanc.ca
370 Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 6]
372 Internet Draft CRAM-MD5 SASL Mechanism November 2003
375 9. Full Copyright Statement
377 Copyright 2003, The Internet Society. All Rights Reserved.
379 This document and translations of it may be copied and furnished to
380 others, and derivative works that comment on or otherwise explain
381 it or assist in its implementation may be prepared, copied, pub-
382 lished and distributed, in whole or in part, without restriction of
383 any kind, provided that the above copyright notice and this para-
384 graph are included on all such copies and derivative works. How-
385 ever, this document itself may not be modified in any way, such as
386 by removing the copyright notice or references to the Internet
387 Society or other Internet organizations, except as needed for the
388 purpose of developing Internet standards in which case the proce-
389 dures for copyrights defined in the Internet Standards process must
390 be followed, or as required to translate it into languages other
391 than English. The limited permissions granted above are perpetual
392 and will not be revoked by the Internet Society or its successors
395 This document and the information contained herein is provided on
396 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI-
397 NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
398 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
399 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR-
400 RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
432 Nerenberg draft-ietf-sasl-crammd5-01.txt [Page 7]