idnits 2.17.1 draft-ietf-sasl-crammd5-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 61: '...ets). The client MUST NOT interpret or...' RFC 2119 keyword, line 70: '... ter, the server MUST scan the client ...' RFC 2119 keyword, line 75: '... The client MUST prepare the user ...' RFC 2119 keyword, line 77: '... resulting values MUST be encoded as UTF-8 [UTF8]....' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2003) is 7467 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'KEYWORD' on line 157 looks like a reference -- Missing reference section? 'SASL' on line 166 looks like a reference -- Missing reference section? 'KEYED-MD5' on line 200 looks like a reference -- Missing reference section? 'SASLPrep' on line 170 looks like a reference -- Missing reference section? 'StringPrep' on line 174 looks like a reference -- Missing reference section? 'UTF8' on line 178 looks like a reference -- Missing reference section? 'ABNF' on line 148 looks like a reference -- Missing reference section? 'IMAP4' on line 184 looks like a reference -- Missing reference section? 'MD5' on line 161 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Nerenberg, Editor 3 Internet Draft: The CRAM-MD5 SASL Mechanism Orthanc Systems 4 Document: draft-ietf-sasl-crammd5-01.txt November 2003 6 The CRAM-MD5 SASL Mechanism 8 Status of this Memo 10 This document is an Internet Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet 16 Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other docu- 20 ments at any time. It is inappropriate to use Internet Drafts as 21 reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet 26 Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright 2003, The Internet Society. All Rights Reserved. 31 Please see the Copyright section near the end of this document for 32 more information. 34 Abstract 36 This document defines a simple challenge-response authentication 37 mechanism, using a keyed-hash digest, for use with the Simple 38 Authentication and Security Layer (SASL). 40 1. Conventions Used in this Document 42 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 43 in this document are to be interpreted as defined in [KEYWORD]. 45 2. CRAM-MD5 Authentication Mechanism 47 This document defines a simple challenge-response [SASL] authenti- 48 cation mechanism, using a [KEYED-MD5] digest, for use with [SASL]. 49 The mechanism name associated with CRAM-MD5 is 'CRAM-MD5'. 51 This mechanism does not provide a security layer. 53 The data encoded in the challenge contains a presumptively arbi- 54 trary string of random digits, a time-stamp, and the fully-quali- 55 fied primary host name of the server. 57 The client makes note of the data and then responds with a string 58 consisting of the user name, a space, and a "digest." The latter 59 is computed by applying the keyed MD5 algorithm from [KEYED-MD5] 60 where the key is a shared secret and the digested text is the chal- 61 lenge (including angle-brackets). The client MUST NOT interpret or 62 attempt to validate the contents of the challenge in any way. 64 This shared secret is a string known only to the client and server. 65 The "digest" parameter itself is a 16-octet value which is sent in 66 hexadecimal format, using lower-case US-ASCII characters. 68 When the server receives this client response, it verifies the 69 digest provided. Since the user name may contain the space charac- 70 ter, the server MUST scan the client response from right to left; 71 the first space character encountered separates the digest from the 72 user name. If the digest is correct, the server should consider 73 the client authenticated and respond appropriately. 75 The client MUST prepare the user name and shared secret strings 76 using the [SASLPrep] profile of the [StringPrep] algorithm. The 77 resulting values MUST be encoded as UTF-8 [UTF8]. 79 2.1. Formal Syntax 81 The following syntax specification uses the augmented Backus-Naur 82 Form (ABNF) as specified in [ABNF], and incorporates by reference 83 the Core Rules defined in that document. 85 challenge = "<" 1*DIGIT "." 1*DIGIT "@" hostname ">" 87 digest = 32(DIGIT / %x61-66) 88 ; A hexadecimal string using only lower-case 89 ; letters 91 hostname = 1*(ALPHA / DIGIT) *("." / "-" / ALPHA / DIGIT) 93 response = user SP digest 95 user = 1*OCTET 97 2.2. Examples 99 The examples in this section do NOT form part of the specification. 100 Where conflicts exist between the examples and the formal grammar 101 or specification text, the latter are authoritative. 103 These examples show the use of the CRAM-MD5 mechanism with the 104 IMAP4 AUTHENTICATE command [IMAP4]. The base64 encoding of the 105 challenges and responses is part of the IMAP4 AUTHENTICATE command, 106 not part of the CRAM-MD5 specification itself. 108 S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] 109 C: A0001 AUTHENTICATE CRAM-MD5 110 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ 111 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 112 S: A0001 OK CRAM-MD5 authentication successful 114 In this example, the shared secret is the string 116 tanstaaftanstaaf 118 Hence, the Keyed MD5 digest is produced by calculating 120 MD5((tanstaaftanstaaf XOR opad), 121 MD5((tanstaaftanstaaf XOR ipad), 122 <1896.697170952@postoffice.example.net>)) 124 where ipad and opad are as defined in [KEYED-MD5] and the string 125 shown in the challenge is the base64 encoding of 126 <1896.697170952@postoffice.reston.mci.net>. The shared secret is 127 null-padded to a length of 64 bytes. If the shared secret is longer 128 than 64 bytes, the MD5 digest of the shared secret is used as a 16 129 byte input to the keyed MD5 calculation. 131 This produces a digest value (in hexadecimal) of 133 b913a602c7eda7a495b4e6e7334d3890 135 The user name is then prepended to it, forming 137 tim b913a602c7eda7a495b4e6e7334d3890 139 Which is then base64 encoded to meet the requirements of the IMAP4 140 AUTHENTICATE command (or the similar POP3 AUTH command), yielding 142 dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 144 3. References 146 3.1. Normative References 148 [ABNF] 149 Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: 150 ABNF", RFC2234, Internet Mail Consortium and Demon Internet Ltd., 151 November 1997. 153 [KEYED-MD5] 154 Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 155 Authentication", RFC 2104, IBM and UCSD, February 1997. 157 [KEYWORD] 158 Bradner, S., "Key words for use in RFCs to Indicate Requirement 159 Levels", BCP 14, RFC2119, Harvard University, March 1997. 161 [MD5] 162 Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT Labo- 163 ratory for Computer Science and RSA Data Security, Inc., April 164 1992. 166 [SASL] 167 Myers, J., "Simple Authentication and Security Layer (SASL)," RFC 168 2222, Netscape Communications, October 1997. 170 [SASLPrep] 171 Zeilenga, K., "SASL String Preparation Profiles", draft-ietf-sasl- 172 saslprep (work in progress) 174 [StringPrep] 175 Hoffman, P., M. Blanchet, "Preparation of Internationalized Strings 176 (stringprep)", RFC 3454, IMC and Viagenie, December 2002. 178 [UTF8] 179 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 180 2279, Alis Technologies, January 1998. 182 3.2. Informative References 184 [IMAP4] 185 Crispin, M., "Internet Message Access Protocol - Version 4rev1," 186 RFC 3501, University of Washington, March 2003. 188 4. Security Considerations 190 It is conjectured that use of the CRAM-MD5 authentication mechanism 191 provides replay protection for a session. 193 This mechanism does not obscure the user name in any way. Accord- 194 ingly, a server that implements both a clear-text password command 195 and this authentication type should not allow both methods of 196 access for a given user name. 198 Keyed MD5 is chosen for this application because of the greater 199 security imparted to authentication of short messages. In addition, 200 the use of the techniques described in [KEYED-MD5] for pre-computa- 201 tion of intermediate results make it possible to avoid explicit 202 clear-text storage of the shared secret on the server system by 203 instead storing the intermediate results which are known as "con- 204 texts." While the saving, on the server, of the MD5 "context" is 205 marginally better than saving the shared secrets in clear-text, it 206 is not sufficient to protect the secrets if the server itself is 207 compromised. Consequently, servers that store the secrets or con- 208 texts must both be protected to a level appropriate to the poten- 209 tial information value in the data and services protected by this 210 mechanism. In other words, techniques like this one involve a 211 trade-off between vulnerability to network sniffing and I/O buffer 212 snooping and vulnerability of the server host's databases. If one 213 believes that the host and its databases are subject to compromise, 214 and the network is not, this technique (and all others like it) is 215 unattractive. It is perhaps even less attractive than clear-text 216 passwords, which are typically stored on hosts in one-way hash 217 form. On the other hand, if the server databases are perceived as 218 reasonably secure, and one is concerned about client-side or net- 219 work interception of the passwords (secrets), then this (and simi- 220 lar) techniques are preferable to clear-text passwords by a wide 221 margin. 223 As the length of the shared secret increases, so does the diffi- 224 culty of deriving it. 226 While there are now suggestions in the literature that the use of 227 MD5 and keyed MD5 in authentication procedures probably has a lim- 228 ited effective lifetime, the technique is now widely deployed and 229 widely understood. It is believed that this general understanding 230 may assist with the rapid replacement, by CRAM-MD5, of the current 231 uses of permanent clear-text passwords in many protocols. This 232 document has been deliberately written to permit easy upgrading to 233 use SHA (or whatever alternatives emerge) when they are considered 234 to be widely available and adequately safe. 236 Even with the use of CRAM-MD5, users are still vulnerable to active 237 attacks. An example of an increasingly common active attack is 238 'TCP Session Hijacking' as described in CERT Advisory CA-95:01. 240 CRAM-MD5 does not authenticate the server and does not include a 241 client-supplied nonce. As a result, it is possible to construct a 242 server with a fixed challenge string that has pre-computed the 243 hashes for all possible passwords up to a certain length (or from a 244 dictionary). Such a server could then immediately determine the 245 user's password if it is sufficiently short. 247 5. IANA Considerations 249 The SASL Mechanism Registry entry for CRAM-MD5 must be updated to 250 reference this specification. 252 6. Contributors 254 The CRAM-MD5 mechanism was originally specified in RFC 2095, 255 IMAP/POP AUTHorize Extension for Simple Challenge/Response. The 256 authors of that document -- John C. Klensin, Paul Krumviede, and 257 Randy Catoe -- are to be credited with the design and specification 258 of CRAM-MD5. This memo serves only to re-state CRAM-MD5 within the 259 formal context of SASL, which specification it preceded by several 260 months. 262 7. Intellectual Property 264 The IETF takes no position regarding the validity or scope of any 265 intellectual property or other rights that might be claimed to per- 266 tain to the implementation or use of the technology described in 267 this document or the extent to which any license under such rights 268 might or might not be available; neither does it represent that it 269 has made any effort to identify any such rights. Information on 270 the IETF's procedures with respect to rights in standards-track and 271 standards-related documentation can be found in BCP-11. Copies of 272 claims of rights made available for publication and any assurances 273 of licenses to be made available, or the result of an attempt made 274 to obtain a general license or permission for the use of such pro- 275 prietary rights by implementers or users of this specification can 276 be obtained from the IETF Secretariat. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights which may cover technology that may be required to practice 281 this standard. Please address the information to the IETF Execu- 282 tive Director. 284 8. Editors' Address 286 Lyndon Nerenberg 287 Orthanc Systems 288 1606 - 10770 Winterburn Road 289 Edmonton, Alberta 290 Canada T5S 1T6 291 Email: lyndon+rfc-crammd5@orthanc.ca 293 9. Full Copyright Statement 295 Copyright 2003, The Internet Society. All Rights Reserved. 297 This document and translations of it may be copied and furnished to 298 others, and derivative works that comment on or otherwise explain 299 it or assist in its implementation may be prepared, copied, pub- 300 lished and distributed, in whole or in part, without restriction of 301 any kind, provided that the above copyright notice and this para- 302 graph are included on all such copies and derivative works. How- 303 ever, this document itself may not be modified in any way, such as 304 by removing the copyright notice or references to the Internet 305 Society or other Internet organizations, except as needed for the 306 purpose of developing Internet standards in which case the proce- 307 dures for copyrights defined in the Internet Standards process must 308 be followed, or as required to translate it into languages other 309 than English. The limited permissions granted above are perpetual 310 and will not be revoked by the Internet Society or its successors 311 or assigns. 313 This document and the information contained herein is provided on 314 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- 315 NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 316 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 317 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- 318 RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.