idnits 2.17.1 draft-ietf-sasl-crammd5-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 391. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. RFC 2119 keyword, line 90: '...ts). The client MUST NOT interpret or...' RFC 2119 keyword, line 100: '... server MUST ensure the right-most s...' RFC 2119 keyword, line 104: '... The client MUST prepare the user na...' RFC 2119 keyword, line 106: '... The resulting values MUST be encoded as UTF-8 [RFC3629] strings. The...' RFC 2119 keyword, line 132: '... ; MUST be well-formed U...' == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 12, 2006) is 6522 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-09) exists of draft-ietf-sasl-plain-08 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SASL Working Group L. Nerenberg, Ed. 3 Internet-Draft Orthanc Systems 4 Obsoletes: RFC2195 (if approved) June 12, 2006 5 Expires: December 14, 2006 7 The CRAM-MD5 SASL Mechanism 8 draft-ietf-sasl-crammd5-07 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 14, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines a simple challenge-response authentication 42 mechanism, using a keyed MD5 digest, for use with the Simple 43 Authentication and Security Layer (SASL). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. The CRAM-MD5 SASL Mechanism . . . . . . . . . . . . . . . . . 3 49 3. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4 50 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 51 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 53 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 54 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 6 55 A.1. IMAP4 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 A.1.1. Example 1: Simple IMAP . . . . . . . . . . . . . . . . 7 57 A.1.2. Example 2: IMAP4 with embedded spaces . . . . . . . . 7 58 A.1.3. Example 3: IMAP4 with Unicode characters . . . . . . . 7 59 A.2. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 A.2.1. Example 4: Simple ACAP . . . . . . . . . . . . . . . . 8 61 Appendix B. IANA Considerations . . . . . . . . . . . . . . . . . 8 62 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 8 63 Appendix D. Changes since RFC 2195 . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Intellectual Property and Copyright Statements . . . . . . . . . . 11 67 1. Introduction 69 This document defines a simple challenge-response authentication 70 method, using a keyed MD5 [RFC2104] digest, for use with the Simple 71 Security and Authentication Layer (SASL) [RFC4422]. The mechanism 72 name associated with CRAM-MD5 is 'CRAM-MD5'. 74 This mechanism is an improvement over plain text authentication 75 schemes, such as the SASL PLAIN [I-D.ietf-sasl-plain] mechanism, in 76 that it transmits the clients' authentication credentials in a secure 77 manner. 79 This mechanism does not provide a security layer. 81 2. The CRAM-MD5 SASL Mechanism 83 The mechanism starts with the server issuing a . The data 84 contained in the challenge contains a string of random data. 86 The client makes note of the data and then responds with a 87 consisting of the , a space, and a . The digest is 88 computed by applying the keyed MD5 algorithm from [RFC2104] where the 89 key is a shared secret and the digested text is the 90 (including angle-brackets). The client MUST NOT interpret or attempt 91 to validate the contents of the challenge in any way. 93 This shared secret is a string known only to the client and server. 94 The digest parameter itself is a 16-octet value which is sent in a 95 restricted hexadecimal format (see the production in 96 Section 3). 98 When the server receives this client response, it verifies the digest 99 provided. Since the user name may contain the space character, the 100 server MUST ensure the right-most space character is recognised as 101 the token separating the user name from the digest. If the digest is 102 correct, the server should consider the client authenticated. 104 The client MUST prepare the user name and shared secret strings using 105 the SASLprep [RFC4013] profile of the Stringprep [RFC3454] algorithm. 106 The resulting values MUST be encoded as UTF-8 [RFC3629] strings. The 107 server may store the prepared string instead of, or as well as, the 108 unprepared string, so that it does not have to prepare it every time 109 it is needed for computation. However, if the original (unprepared) 110 string is not stored, it may render the computed secret to be 111 incompatible with a future revisions of SASLprep that support 112 currently unassigned code points (see section 7 of [RFC3454]). It is 113 therefor recommended to store the unprepared string in the database. 115 3. Formal Grammar 117 The following grammar specification uses the Augmented Backus-Naur 118 Form (ABNF) as specified in [RFC4234], and incorporates by reference 119 the Core Rules defined in that document. 121 challenge = "<" 3*(%x21-3B / %x3D / %x3F-7E) ">" 122 ; a bracketed string of printing ASCII characters, not 123 ; containing embedded "<" or ">" 125 digest = 32(DIGIT / %x61-66) 126 ; A hexadecimal string, using ONLY lower-case 127 ; letters 129 response = username SP digest 131 username = 1*OCTET 132 ; MUST be well-formed UTF-8. 134 4. Security Considerations 136 It is conjectured that use of the CRAM-MD5 authentication mechanism 137 provides replay protection for a session. 139 This mechanism does not obscure the user name in any way. 140 Accordingly, a server that implements both a clear-text password 141 command and this authentication type should not allow both methods of 142 access for a given user name. 144 Keyed MD5 is chosen for this application because of the greater 145 security imparted to authentication of short messages. In addition, 146 the use of the techniques described in [RFC2104] for pre-computation 147 of intermediate results make it possible to avoid explicit clear-text 148 storage of the shared secret on the server system by instead storing 149 the intermediate results which are known as "contexts." While the 150 saving, on the server, of the MD5 context is marginally better than 151 saving the shared secrets in clear-text, it is not sufficient to 152 protect the secrets if the server itself is compromised. 153 Consequently, servers that store the secrets or contexts must both be 154 protected to a level appropriate to the potential information value 155 in the data and services protected by this mechanism. In other 156 words, techniques like this one involve a trade-off between 157 vulnerability to network sniffing and I/O buffer snooping and 158 vulnerability of the server host's databases. If one believes that 159 the host and its databases are subject to compromise, and the network 160 is not, this technique (and all others like it) is unattractive. It 161 is perhaps even less attractive than clear-text passwords, which are 162 typically stored on hosts in one-way hash form. On the other hand, 163 if the server databases are perceived as reasonably secure, and one 164 is concerned about client-side or network interception of the 165 passwords (secrets), then this (and similar) techniques are 166 preferable to clear-text passwords by a wide margin. 168 As the length of the shared secret increases, so does the difficulty 169 of deriving it. 171 While there are now suggestions in the literature that the use of MD5 172 and keyed MD5 in authentication procedures probably has a limited 173 effective lifetime, the technique is now widely deployed and widely 174 understood. It is believed that this general understanding may 175 assist with the rapid replacement, by CRAM-MD5, of the current uses 176 of permanent clear-text passwords in many protocols. This document 177 has been deliberately written to permit easy upgrading to use SHA (or 178 whatever alternatives emerge) when they are considered to be widely 179 available and adequately safe. 181 Even with the use of CRAM-MD5, users are still vulnerable to active 182 attacks. An example of an increasingly common active attack is 'TCP 183 Session Hijacking' as described in CERT Advisory CA-95:01. 185 CRAM-MD5 does not authenticate the server and does not include a 186 client-supplied nonce. As a result, it is possible to construct a 187 server with a fixed challenge string that has pre-computed the hashes 188 for all possible passwords up to a certain length (or from a 189 dictionary). Such a server could then immediately determine the 190 user's password if it is sufficiently short. 192 Many people have expressed concerns over the suitability of CRAM-MD5 193 to current and future internet protocols. While lacking modern 194 features (such as integrity protection and encryption), this 195 mechanism can still provide a useful service when deployed in a 196 suitable security context. One example of this involves networks 197 utilizing radio links licensed in the amateur radio service, where by 198 law the use of codes to obscure communications is prohibited, but 199 exceptions are permitted soley for the purposes of authentication. 201 5. References 203 5.1. Normative References 205 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 206 Hashing for Message Authentication", RFC 2104, 207 February 1997. 209 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 210 Internationalized Strings ("stringprep")", RFC 3454, 211 December 2002. 213 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 214 10646", STD 63, RFC 3629, November 2003. 216 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 217 and Passwords", RFC 4013, February 2005. 219 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 220 Specifications: ABNF", RFC 4234, October 2005. 222 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 223 Security Layer (SASL)", RFC 4422, June 2006. 225 5.2. Informative References 227 [I-D.ietf-sasl-plain] 228 Zeilenga, K., "The Plain SASL Mechanism", 229 draft-ietf-sasl-plain-08 (work in progress), March 2005. 231 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 232 Configuration Access Protocol", RFC 2244, November 1997. 234 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 235 4rev1", RFC 3501, March 2003. 237 Appendix A. Examples 239 The examples in this appendix DO NOT form part of the specification. 240 Where conflicts exist between the examples and the formal grammar or 241 the normative text in Section 2, the latter are authoritative. 243 A.1. IMAP4 245 These examples show the use of the CRAM-MD5 mechanism with the IMAP4 246 [RFC3501] AUTHENTICATE command. The base64 encoding of the 247 challenges and responses is part of the IMAP4 AUTHENTICATE command, 248 and not part of the CRAM-MD5 specification itself. 250 A.1.1. Example 1: Simple IMAP 252 In this example the shared secret is the string 'tanstaaftanstaaf'. 254 S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] 255 C: A0001 AUTHENTICATE CRAM-MD5 256 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ 257 C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 258 S: A0001 OK CRAM-MD5 authentication successful 260 Hence, the keyed MD5 digest is produced by calculating 262 MD5((SASLprep(tanstaaftanstaaf) XOR opad), 263 MD5((SASLprep(tanstaaftanstaaf) XOR ipad), 264 <1896.697170952@postoffice.example.net>)) 266 where ipad and opad are as defined in RFC 2104 and the string shown 267 in the challenge is the base64 encoding of 268 '<1896.697170952@postoffice.example.net>'. The shared secret is 269 null-padded to a length of 64 bytes. If the shared secret is longer 270 than 64 bytes, the MD5 digest of the shared secret is used as a 16 271 byte input to the keyed MD5 calculation. 273 This produces a digest value (in hexadecimal) of 274 '3dbc88f0624776a737b39093f6eb6427'. The user name is then prepended 275 to it, forming 'joe 3dbc88f0624776a737b39093f6eb6427', which is then 276 base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE 277 command yielding 'am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3'. 279 A.1.2. Example 2: IMAP4 with embedded spaces 281 This example uses the user name 'Ali Baba' and the shared secret 282 'Open, Sesame'. It illustrates that both user names and passwords 283 may contain non-alphanumeric characters. 285 S: <68451038525716401353.0@localhost> 286 C: Ali Baba 6fa32b6e768f073132588e3418e00f71 288 A.1.3. Example 3: IMAP4 with Unicode characters 290 This example demonstrates the processing of Unicode strings. The raw 291 user name is 'Alddin' where is the 292 Unicode Latin symbol , is , and is the . Preparing the raw 294 user name with SASLprep returns 'Aladdin' which we then 295 encode into the UTF-8 string 'Aladdin\xC2\xAE' (shown here and below 296 using C-style string format notation). As before, the shared secret 297 is 'Open, Sesame'. 299 S: <92230559549732219941.0@localhost> 300 C: Aladdin\xC2\xAE 9950ea407844a71e2f0cd3284cbd912d 302 A.2. ACAP 304 An example of using CRAM-MD5 with ACAP [RFC2244]. 306 A.2.1. Example 4: Simple ACAP 308 This example uses the user name 'joe' and the shared secret 309 'tanstaaftanstaaf'. 311 S: * ACAP (IMPLEMENTATION "Infotrope ACAP Server, version 0.1.3, 312 Copyright 2002-2004 Dave Cridland ") 313 (SASL "PLAIN" "DIGEST-MD5" "CRAM-MD5" "ANONYMOUS") (STARTTLS) 314 C: AUTH AUTHENTICATE "CRAM-MD5" 315 S: + {43} 316 S: <2262304172.6455022@gw2.gestalt.entity.net> 317 C: {36+} 318 C: joe 2aa383bf320a941d8209a7001ef6aeb6 319 S: AUTH OK "You're logged in as joe. Frooby." 321 Appendix B. IANA Considerations 323 It is requested that the Internet Assigned Numbers Authority (IANA) 324 update the SASL Mechanism Registry entry for CRAM-MD5 to refer to 325 this document. 327 To: iana@iana.org 328 Subject: Updated Registration of SASL CRAM-MD5 mechanism. 330 SASL mechanism name: CRAM-MD5 331 Security considerations: See RFC XXXX 332 Published specification: RFC XXXX 333 Person & email address to contact for further information: 334 Lyndon Nerenberg 335 IETF SASL WG 337 Appendix C. Contributors 339 The CRAM-MD5 mechanism was originally specified in RFC 2095, IMAP/POP 340 AUTHorize Extension for Simple Challenge/Response. The authors of 341 that document -- John C. Klensin, Paul Krumviede, and Randy Catoe -- 342 are to be credited with the design and specification of CRAM-MD5, and 343 they are the original authors of the majority of the text in this 344 document. This memo serves only to re-state CRAM-MD5 within the 345 formal context of SASL, which specification it preceded by several 346 months. 348 Dave Cridland and Simon Josefsson contributed updated examples. 350 Appendix D. Changes since RFC 2195 352 The syntax of the has been relaxed. 354 Both the user name and the shared secret (password) must be prepared 355 using SASLprep, and the resulting values encoded as UTF-8 strings. 357 Minor editorial changes to clarify the text. 359 Author's Address 361 Lyndon Nerenberg (editor) 362 Orthanc Systems 363 304 - 1755 Robson Street 364 Vancouver, BC V6G 3B7 365 Canada 367 Email: lyndon+rfc-crammd5@orthanc.ca 369 Intellectual Property Statement 371 The IETF takes no position regarding the validity or scope of any 372 Intellectual Property Rights or other rights that might be claimed to 373 pertain to the implementation or use of the technology described in 374 this document or the extent to which any license under such rights 375 might or might not be available; nor does it represent that it has 376 made any independent effort to identify any such rights. Information 377 on the procedures with respect to rights in RFC documents can be 378 found in BCP 78 and BCP 79. 380 Copies of IPR disclosures made to the IETF Secretariat and any 381 assurances of licenses to be made available, or the result of an 382 attempt made to obtain a general license or permission for the use of 383 such proprietary rights by implementers or users of this 384 specification can be obtained from the IETF on-line IPR repository at 385 http://www.ietf.org/ipr. 387 The IETF invites any interested party to bring to its attention any 388 copyrights, patents or patent applications, or other proprietary 389 rights that may cover technology that may be required to implement 390 this standard. Please address the information to the IETF at 391 ietf-ipr@ietf.org. 393 Disclaimer of Validity 395 This document and the information contained herein are provided on an 396 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 397 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 398 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 399 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 400 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 401 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 403 Copyright Statement 405 Copyright (C) The Internet Society (2006). This document is subject 406 to the rights, licenses and restrictions contained in BCP 78, and 407 except as set forth therein, the authors retain all their rights. 409 Acknowledgment 411 Funding for the RFC Editor function is currently provided by the 412 Internet Society.