idnits 2.17.1 draft-ietf-sasl-crammd5-08.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 429. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 93: '...ts). The client MUST NOT interpret or...' RFC 2119 keyword, line 103: '... server MUST ensure the right-most s...' RFC 2119 keyword, line 124: '... ; MUST be well-formed U...' RFC 2119 keyword, line 148: '... The client SHOULD prepare the user ...' RFC 2119 keyword, line 150: '... algorithm. The resulting values SHOULD be encoded as UTF-8 [RFC3629]...' (1 more instance...) == 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 IETF Trust 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 (March 5, 2007) is 6255 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) == Unused Reference: 'RFC4616' is defined on line 259, but no explicit reference was found in the text ** 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) -- Obsolete informational reference (is this intentional?): RFC 2095 (Obsoleted by RFC 2195) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 March 5, 2007 5 (if approved) 6 Intended status: Standards Track 7 Expires: September 6, 2007 9 The CRAM-MD5 SASL Mechanism 10 draft-ietf-sasl-crammd5-08 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 6, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines a simple challenge-response authentication 44 mechanism, using a keyed MD5 digest, for use with the Simple 45 Authentication and Security Layer (SASL). 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. The CRAM-MD5 SASL Mechanism . . . . . . . . . . . . . . . . . 3 51 3. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Interoperability Considerations . . . . . . . . . . . . . . . 4 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 54 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 56 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 57 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 58 A.1. IMAP4 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 A.1.1. Example 1: Simple IMAP . . . . . . . . . . . . . . . . 7 60 A.1.2. Example 2: IMAP4 with embedded spaces . . . . . . . . 8 61 A.1.3. Example 3: IMAP4 with Unicode characters . . . . . . . 8 62 A.2. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 A.2.1. Example 4: Simple ACAP . . . . . . . . . . . . . . . . 8 64 Appendix B. IANA Considerations . . . . . . . . . . . . . . . . . 9 65 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 9 66 Appendix D. Changes since RFC 2195 . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 Intellectual Property and Copyright Statements . . . . . . . . . . 10 70 1. Introduction 72 This document defines a simple challenge-response authentication 73 method, using a keyed MD5 [RFC2104] digest, for use with the Simple 74 Security and Authentication Layer (SASL) [RFC4422]. The mechanism 75 name associated with CRAM-MD5 is 'CRAM-MD5'. 77 This mechanism does not provide a security layer. 79 The CRAM-MD5 mechanism is intended to have limited use on the 80 Internet. The mechanism offers inadequate protection against common 81 attacks against application-level protocols (see Section 5) and is 82 prone to interoperability problems (see Section 4). 84 2. The CRAM-MD5 SASL Mechanism 86 The mechanism starts with the server issuing a . The data 87 contained in the challenge contains a string of random data. 89 The client makes note of the data and then responds with a 90 consisting of the , a space, and a . The digest is 91 computed by applying the keyed MD5 algorithm from [RFC2104] where the 92 key is a shared secret and the digested text is the 93 (including angle-brackets). The client MUST NOT interpret or attempt 94 to validate the contents of the challenge in any way. 96 This shared secret is a string known only to the client and server. 97 The digest parameter itself is a 16-octet value which is sent in a 98 restricted hexadecimal format (see the production in 99 Section 3). 101 When the server receives this client response, it verifies the digest 102 provided. Since the user name may contain the space character, the 103 server MUST ensure the right-most space character is recognised as 104 the token separating the user name from the digest. If the digest is 105 correct, the server should consider the client authenticated. 107 3. Formal Grammar 109 The following grammar specification uses the Augmented Backus-Naur 110 Form (ABNF) as specified in [RFC4234], and incorporates by reference 111 the Core Rules defined in that document. 113 challenge = "<" 3*(%x21-3B / %x3D / %x3F-7E) ">" 114 ; a bracketed string of printing ASCII characters, not 115 ; containing embedded "<" or ">" 117 digest = 32(DIGIT / %x61-66) 118 ; A hexadecimal string, using ONLY lower-case 119 ; letters 121 response = username SP digest 123 username = 1*OCTET 124 ; MUST be well-formed UTF-8. 126 4. Interoperability Considerations 128 The design of CRAM-MD5 [RFC2095] pre-dated any widespread use of 129 UTF-8 to encode protocol elements. It was initially deployed as an 130 extension to the IMAP4 protocol at a time when authentication and 131 authorization identifiers were almost exclusively encoded in the US- 132 ASCII character set, therefore it is silent about the encoding and 133 representation of non-US-ASCII data elements. When sites first began 134 using alternate character sets to encode user names (and passwords) 135 they simply used the raw 8-bit character representation. This works 136 - for the most part - but only because these enclaves tend to use a 137 common character set amongst themselves. When a second group of 138 users using a different character set is introduced into the mix, 139 interoperability suffers. 141 So as not to render existing implementations non-compliant, this 142 update preserves the existing opaque nature of user names and 143 passwords. However, implementors are strongly encouraged to process 144 the user name and password data as described in the next paragraph. 145 Doing so prevents interoperability problems caused by incompatible 146 character set encodings. 148 The client SHOULD prepare the user name and shared secret strings 149 using the SASLprep [RFC4013] profile of the Stringprep [RFC3454] 150 algorithm. The resulting values SHOULD be encoded as UTF-8 [RFC3629] 151 strings. The server may store the prepared string instead of, or as 152 well as, the unprepared string, so that it does not have to prepare 153 it every time it is needed for computation. However, if the original 154 (unprepared) string is not stored, it may render the computed secret 155 to be incompatible with a future revisions of SASLprep that support 156 currently unassigned code points (see section 7 of [RFC3454]). It is 157 therefor recommended to store the unprepared string in the database. 159 5. Security Considerations 161 CRAM-MD5 is no longer considered to provide adequate protection. 163 This mechanism is vulnerable to dictionary attack by any passive 164 listener able to observe the user name, challenge and response. An 165 attacker can use the user name and challenge to compute a series of 166 responses based on a pass-phrase dictionary, looking for a match to 167 the response sent by the client. 169 CRAM-MD5 does not authenticate the server and does not include a 170 client-supplied nonce. As a result, it is possible to construct a 171 server with a fixed challenge string that has pre-computed the hashes 172 for all possible passwords up to a certain length (or from a 173 dictionary). Such a server could then immediately determine the 174 user's password if it is sufficiently short or non-random. 176 This mechanism does not obscure the user name in any way. 177 Accordingly, a server that implements both a clear-text password 178 command and this authentication type should not allow both methods of 179 access for a given user name. 181 For the reasons described above, CRAM-MD5 SHOULD NOT be used unless 182 the application protocol session is protected by an encryption layer, 183 such as provided by TLS. 185 Keyed MD5 is chosen for this application because of the greater 186 security imparted to authentication of short messages. In addition, 187 the use of the techniques described in [RFC2104] for pre-computation 188 of intermediate results make it possible to avoid explicit clear-text 189 storage of the shared secret on the server system by instead storing 190 the intermediate results which are known as "contexts." While the 191 saving, on the server, of the MD5 context is marginally better than 192 saving the shared secrets in clear-text, it is not sufficient to 193 protect the secrets if the server itself is compromised. 194 Consequently, servers that store the secrets or contexts must both be 195 protected to a level appropriate to the potential information value 196 in the data and services protected by this mechanism. In other 197 words, techniques like this one involve a trade-off between 198 vulnerability to network sniffing and I/O buffer snooping and 199 vulnerability of the server host's databases. If one believes that 200 the host and its databases are subject to compromise, and the network 201 is not, this technique (and all others like it) is unattractive. It 202 is perhaps even less attractive than clear-text passwords, which are 203 typically stored on hosts in one-way hash form. On the other hand, 204 if the server databases are perceived as reasonably secure, and one 205 is concerned about client-side or network interception of the 206 passwords (secrets), then this (and similar) techniques are 207 preferable to clear-text passwords by a wide margin. 209 While there are now suggestions in the literature that the use of MD5 210 and keyed MD5 in authentication procedures probably has a limited 211 effective lifetime, the technique is now widely deployed and widely 212 understood. It is believed that this general understanding may 213 assist with the rapid replacement, by CRAM-MD5, of the current uses 214 of permanent clear-text passwords in many protocols. This document 215 has been deliberately written to permit easy upgrading to use SHA (or 216 whatever alternatives emerge) when they are considered to be widely 217 available and adequately safe. 219 Even with the use of CRAM-MD5, users are still vulnerable to active 220 attacks. An example of an increasingly common active attack is 'TCP 221 Session Hijacking' as described in CERT Advisory CA-95:01. 223 6. References 225 6.1. Normative References 227 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 228 Hashing for Message Authentication", RFC 2104, 229 February 1997. 231 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 232 Internationalized Strings ("stringprep")", RFC 3454, 233 December 2002. 235 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 236 10646", STD 63, RFC 3629, November 2003. 238 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 239 and Passwords", RFC 4013, February 2005. 241 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 242 Specifications: ABNF", RFC 4234, October 2005. 244 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 245 Security Layer (SASL)", RFC 4422, June 2006. 247 6.2. Informative References 249 [RFC2095] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 250 AUTHorize Extension for Simple Challenge/Response", 251 RFC 2095, January 1997. 253 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 254 Configuration Access Protocol", RFC 2244, November 1997. 256 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 257 4rev1", RFC 3501, March 2003. 259 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 260 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 262 Appendix A. Examples 264 The examples in this appendix DO NOT form part of the specification. 265 Where conflicts exist between the examples and the formal grammar or 266 the normative text in Section 2, the latter are authoritative. 268 A.1. IMAP4 270 These examples show the use of the CRAM-MD5 mechanism with the IMAP4 271 [RFC3501] AUTHENTICATE command. The base64 encoding of the 272 challenges and responses is part of the IMAP4 AUTHENTICATE command, 273 and not part of the CRAM-MD5 specification itself. 275 A.1.1. Example 1: Simple IMAP 277 In this example the shared secret is the string 'tanstaaftanstaaf'. 279 S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] 280 C: A0001 AUTHENTICATE CRAM-MD5 281 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ 282 C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 283 S: A0001 OK CRAM-MD5 authentication successful 285 Hence, the keyed MD5 digest is produced by calculating 287 MD5((SASLprep(tanstaaftanstaaf) XOR opad), 288 MD5((SASLprep(tanstaaftanstaaf) XOR ipad), 289 <1896.697170952@postoffice.example.net>)) 291 where ipad and opad are as defined in RFC 2104 and the string shown 292 in the challenge is the base64 encoding of 293 '<1896.697170952@postoffice.example.net>'. The shared secret is 294 null-padded to a length of 64 bytes. If the shared secret is longer 295 than 64 bytes, the MD5 digest of the shared secret is used as a 16 296 byte input to the keyed MD5 calculation. 298 This produces a digest value (in hexadecimal) of 299 '3dbc88f0624776a737b39093f6eb6427'. The user name is then prepended 300 to it, forming 'joe 3dbc88f0624776a737b39093f6eb6427', which is then 301 base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE 302 command yielding 'am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3'. 304 A.1.2. Example 2: IMAP4 with embedded spaces 306 This example uses the user name 'Ali Baba' and the shared secret 307 'Open, Sesame'. It illustrates that both user names and passwords 308 may contain non-alphanumeric characters. 310 S: <68451038525716401353.0@localhost> 311 C: Ali Baba 6fa32b6e768f073132588e3418e00f71 313 A.1.3. Example 3: IMAP4 with Unicode characters 315 This example demonstrates the processing of Unicode strings. The raw 316 user name is 'Alddin' where is the 317 Unicode Latin symbol , is , and is the . Preparing the raw 319 user name with SASLprep returns 'Aladdin' which we then 320 encode into the UTF-8 string 'Aladdin\xC2\xAE' (shown here and below 321 using C-style string format notation). As before, the shared secret 322 is 'Open, Sesame'. 324 S: <92230559549732219941.0@localhost> 325 C: Aladdin\xC2\xAE 9950ea407844a71e2f0cd3284cbd912d 327 A.2. ACAP 329 An example of using CRAM-MD5 with ACAP [RFC2244]. 331 A.2.1. Example 4: Simple ACAP 333 This example uses the user name 'joe' and the shared secret 334 'tanstaaftanstaaf'. 336 S: * ACAP (IMPLEMENTATION "Infotrope ACAP Server, version 0.1.3, 337 Copyright 2002-2004 Dave Cridland ") 338 (SASL "PLAIN" "DIGEST-MD5" "CRAM-MD5" "ANONYMOUS") (STARTTLS) 339 C: AUTH AUTHENTICATE "CRAM-MD5" 340 S: + {43} 341 S: <2262304172.6455022@gw2.gestalt.entity.net> 342 C: {36+} 343 C: joe 2aa383bf320a941d8209a7001ef6aeb6 344 S: AUTH OK "You're logged in as joe. Frooby." 346 Appendix B. IANA Considerations 348 It is requested that the Internet Assigned Numbers Authority (IANA) 349 update the SASL Mechanism Registry entry for CRAM-MD5 to refer to 350 this document. 352 To: iana@iana.org 353 Subject: Updated Registration of SASL CRAM-MD5 mechanism. 355 SASL mechanism name: CRAM-MD5 356 Security considerations: See RFC XXXX 357 Published specification: RFC XXXX 358 Person & email address to contact for further information: 359 Lyndon Nerenberg 360 IETF SASL WG 362 Appendix C. Contributors 364 The CRAM-MD5 mechanism was originally specified in RFC 2095, IMAP/POP 365 AUTHorize Extension for Simple Challenge/Response. The authors of 366 that document -- John C. Klensin, Paul Krumviede, and Randy Catoe -- 367 are to be credited with the design and specification of CRAM-MD5, and 368 they are the original authors of the majority of the text in this 369 document. This memo serves only to re-state CRAM-MD5 within the 370 formal context of SASL, which specification it preceded by several 371 months. 373 Dave Cridland and Simon Josefsson contributed updated examples. 375 Appendix D. Changes since RFC 2195 377 The syntax of the has been relaxed. 379 A section on interoperability concerns has been added. 381 The security considerations have been updated to reflect the current 382 views of the security community. 384 Author's Address 386 Lyndon Nerenberg (editor) 387 Orthanc Systems 389 Email: lyndon+rfc-crammd5@orthanc.ca 391 Full Copyright Statement 393 Copyright (C) The IETF Trust (2007). 395 This document is subject to the rights, licenses and restrictions 396 contained in BCP 78, and except as set forth therein, the authors 397 retain all their rights. 399 This document and the information contained herein are provided on an 400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 402 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 403 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 404 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 407 Intellectual Property 409 The IETF takes no position regarding the validity or scope of any 410 Intellectual Property Rights or other rights that might be claimed to 411 pertain to the implementation or use of the technology described in 412 this document or the extent to which any license under such rights 413 might or might not be available; nor does it represent that it has 414 made any independent effort to identify any such rights. Information 415 on the procedures with respect to rights in RFC documents can be 416 found in BCP 78 and BCP 79. 418 Copies of IPR disclosures made to the IETF Secretariat and any 419 assurances of licenses to be made available, or the result of an 420 attempt made to obtain a general license or permission for the use of 421 such proprietary rights by implementers or users of this 422 specification can be obtained from the IETF on-line IPR repository at 423 http://www.ietf.org/ipr. 425 The IETF invites any interested party to bring to its attention any 426 copyrights, patents or patent applications, or other proprietary 427 rights that may cover technology that may be required to implement 428 this standard. Please address the information to the IETF at 429 ietf-ipr@ietf.org. 431 Acknowledgment 433 Funding for the RFC Editor function is provided by the IETF 434 Administrative Support Activity (IASA).