idnits 2.17.1 draft-ietf-sasl-crammd5-03.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 334), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 7) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 82: '...ts). The client MUST NOT interpret or...' RFC 2119 keyword, line 96: '... The client MUST prepare the user na...' RFC 2119 keyword, line 98: '... [RFC3454] algorithm. The resulting values MUST be encoded as UTF-8...' == 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 (July 8, 2004) is 7232 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 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SASL Working Group L. Nerenberg, Ed. 2 Internet-Draft Orthanc Systems 3 Obsoletes: RFC2195 (if approved) July 8, 2004 4 Expires: January 6, 2005 6 The CRAM-MD5 SASL Mechanism 7 draft-ietf-sasl-crammd5-03 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 6, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document defines a simple challenge-response authentication 41 mechanism, using a keyed MD5 digest, for use with the Simple 42 Authentication and Security Layer (SASL). 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. The CRAM-MD5 SASL Mechanism . . . . . . . . . . . . . . . . . 3 48 3. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 4.1 Example 1: IMAP4 . . . . . . . . . . . . . . . . . . . . . 4 51 4.2 Example 2: IMAP4 with embedded spaces . . . . . . . . . . 5 52 4.3 Example 3: IMAP4 with Unicode characters . . . . . . . . . 5 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 54 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 56 6.2 Informative References . . . . . . . . . . . . . . . . . . . 7 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 58 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 B. Changes since RFC 2195 . . . . . . . . . . . . . . . . . . . . 8 60 Intellectual Property and Copyright Statements . . . . . . . . 9 62 1. Introduction 64 This document defines a simple challenge-response authentication 65 menthod, using a keyed MD5 [RFC2104] digest, for use with the Simple 66 Security and Authentication Layer (SASL) 67 [draft-ietf-sasl-rfc2222bis]. The mechanism name associated with 68 CRAM-MD5 is 'CRAM-MD5'. 70 This mechanism does not provide a security layer. 72 2. The CRAM-MD5 SASL Mechanism 74 The mechanism starts with the server issuing a challenge. The data 75 encoded in the challenge contains a presumptively arbitrary string of 76 random data. 78 The client makes note of the data and then responds with a string 79 consisting of the user name, a space, and a digest. The digest is 80 computed by applying the keyed MD5 algorithm from RFC 2104 where the 81 key is a shared secret and the digested text is the challenge 82 (including angle-brackets). The client MUST NOT interpret or attempt 83 to validate the contents of the challenge in any way. 85 This shared secret is a string known only to the client and server. 86 The digest parameter itself is a 16-octet value which is sent in a 87 restricted hexadecimal format (see the production in Section 88 3). 90 When the server receives this client response, it verifies the digest 91 provided. Since the user name may contain the space character, the 92 server must take care to ensure the right-most space is recognized as 93 the token seperating the user name from the digest. If the digest is 94 correct, the server should consider the client authenticated. 96 The client MUST prepare the user name and shared secret strings using 97 the SASLPrep [draft-ietf-sasl-saslprep] profile of the StringPrep 98 [RFC3454] algorithm. The resulting values MUST be encoded as UTF-8 99 [RFC2279] strings. The server may store the prepared string instead 100 of, or as well as, the unprepared string, so that it does not have to 101 prepare it every time it is needed for computation. However, if the 102 original, unprepared string, is not stored, it may render the 103 computed secret to be incompatible with a future revisions of 104 SASLPrep that support currently unassigned code points (compare 105 section 7 of StringPrep). It is therefor recommended to store the 106 unprepared string in the database. 108 3. Formal Grammar 110 The following grammar specification uses the Augmented Backus-Naur 111 Form (ABNF) as specified in [RFC2234], and incorporates by reference 112 the Core Rules defined in that document. 114 challenge = "<" 3*(%x21-3B / %x3D / %x3F-7E) ">" 115 ; a bracketed string of printing characters, not 116 ; containing embedded "<" or ">" 118 digest = 32(DIGIT / %x61-66) 119 ; A hexadecimal string, using ONLY lower-case 120 ; letters 122 response = user SP digest 124 user = 1*OCTET 126 4. Examples 128 The examples in this section do NOT form part of the specification. 129 Where conflicts exist between the examples and the formal grammar or 130 the normative text in Section 2, the latter are authoritative. 132 These examples show the use of the CRAM-MD5 mechanism with the IMAP4 133 [RFC3501] AUTHENTICATE command. The base64 encoding of the 134 challenges and responses is part of the IMAP4 AUTHENTICATE command, 135 and not part of the CRAM-MD5 specification itself. 137 4.1 Example 1: IMAP4 139 S: * OK [CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED AUTH=CRAM-MD5] 140 C: A0001 AUTHENTICATE CRAM-MD5 141 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UuZXhhbXBsZS5uZXQ+ 142 C: am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3 143 S: A0001 OK CRAM-MD5 authentication successful 145 In this example the shared secret is the string 'tanstaaftanstaaf'. 146 Hence, the keyed MD5 digest is produced by calculating 148 MD5((SASLprep(tanstaaftanstaaf) XOR opad), 149 MD5((SASLPrep(tanstaaftanstaaf) XOR ipad), 150 <1896.697170952@postoffice.example.net>)) 152 where ipad and opad are as defined in RFC 2104 and the string shown 153 in the challenge is the base64 encoding of 154 '<1896.697170952@postoffice.example.net>'. The shared secret is 155 null-padded to a length of 64 bytes. If the shared secret is longer 156 than 64 bytes, the MD5 digest of the shared secret is used as a 16 157 byte input to the keyed MD5 calculation. 159 This produces a digest value (in hexadecimal) of 160 '3dbc88f0624776a737b39093f6eb6427'. The user name is then prepended 161 to it, forming 'joe 3dbc88f0624776a737b39093f6eb6427', which is then 162 base64 encoded to meet the requirements of the IMAP4 AUTHENTICATE 163 command yielding 'am9lIDNkYmM4OGYwNjI0Nzc2YTczN2IzOTA5M2Y2ZWI2NDI3'. 165 4.2 Example 2: IMAP4 with embedded spaces 167 This example uses the user name 'Ali Baba' and the shared secret 168 'Open, Sesame'. It illustrates that both user names and passwords 169 may contain non-alphanumeric characters. 171 S: <68451038525716401353.0@localhost> 172 C: Ali Baba 6fa32b6e768f073132588e3418e00f71 174 4.3 Example 3: IMAP4 with Unicode characters 176 This example demonstrates the processing of Unicode strings. The raw 177 user name is 'Alddin' where is the 178 Unicode Latin symbol , is , and is the . Preparing the raw 180 user name with SASLPrep returns 'Aladdin' which we then 181 encode into the UTF-8 string 'Aladdin\xC2\xAE' (shown here and below 182 using C-style string format notation). As before, the shared secret 183 is 'Open, Sesame'. 185 S: <92230559549732219941.0@localhost> 186 C: Aladdin\xC2\xAE 9950ea407844a71e2f0cd3284cbd912d 188 5. 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. 194 Accordingly, a server that implements both a clear-text password 195 command 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 [RFC2104] for pre-computation 201 of intermediate results make it possible to avoid explicit clear-text 202 storage of the shared secret on the server system by instead storing 203 the intermediate results which are known as "contexts." While the 204 saving, on the server, of the MD5 context is marginally better than 205 saving the shared secrets in clear-text, it is not sufficient to 206 protect the secrets if the server itself is compromised. 207 Consequently, servers that store the secrets or contexts must both be 208 protected to a level appropriate to the potential information value 209 in the data and services protected by this mechanism. In other 210 words, techniques like this one involve a trade-off between 211 vulnerability to network sniffing and I/O buffer snooping and 212 vulnerability of the server host's databases. If one believes that 213 the host and its databases are subject to compromise, and the network 214 is not, this technique (and all others like it) is unattractive. It 215 is perhaps even less attractive than clear-text passwords, which are 216 typically stored on hosts in one-way hash form. On the other hand, 217 if the server databases are perceived as reasonably secure, and one 218 is concerned about client-side or network interception of the 219 passwords (secrets), then this (and similar) techniques are 220 preferable to clear-text passwords by a wide margin. 222 As the length of the shared secret increases, so does the difficulty 223 of deriving it. 225 While there are now suggestions in the literature that the use of MD5 226 and keyed MD5 in authentication procedures probably has a limited 227 effective lifetime, the technique is now widely deployed and widely 228 understood. It is believed that this general understanding may 229 assist with the rapid replacement, by CRAM-MD5, of the current uses 230 of permanent clear-text passwords in many protocols. This document 231 has been deliberately written to permit easy upgrading to use SHA (or 232 whatever alternatives emerge) when they are considered to be widely 233 available and adequately safe. 235 Even with the use of CRAM-MD5, users are still vulnerable to active 236 attacks. An example of an increasingly common active attack is 'TCP 237 Session Hijacking' as described in CERT Advisory CA-95:01. 239 CRAM-MD5 does not authenticate the server and does not include a 240 client-supplied nonce. As a result, it is possible to construct a 241 server with a fixed challenge string that has pre-computed the hashes 242 for all possible passwords up to a certain length (or from a 243 dictionary). Such a server could then immediately determine the 244 user's password if it is sufficiently short. 246 6. References 248 6.1 Normative References 250 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 251 Keyed-Hashing for Message Authentication", RFC 2104, 252 February 1997. 254 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 255 Specifications : ABNF", RFC 2234, November 1997. 257 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 258 10646", RFC 2279, January 1998. 260 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 261 Internationalized Strings ("stringprep")", RFC 3454, 262 December 2002. 264 [draft-ietf-sasl-rfc2222bis] 265 Melnikov, A., "Simple Authentication and Security Layer 266 (SASL)", draft-ietf-sasl-rfc2222bis-07 (work in progress), 267 March 2004. 269 [draft-ietf-sasl-saslprep] 270 Zeilenga, K., "SASLprep: Stringprep profile for user names 271 and passwords", draft-ietf-sasl-saslprep-09 (work in 272 progress), April 2004. 274 6.2 Informative References 276 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 277 4rev1", RFC 3501, March 2003. 279 Author's Address 281 Lyndon Nerenberg (editor) 282 Orthanc Systems 284 EMail: lyndon+rfc-crammd5@orthanc.ca 286 Appendix A. IANA Considerations 288 It is requested that the Internet Assigned Numbers Authority (IANA) 289 update the SASL Mechanism Registry entry for CRAM-MD5 to refer to 290 this document. 292 Appendix B. Changes since RFC 2195 294 To Be Done 296 Intellectual Property Statement 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at 318 ietf-ipr@ietf.org. 320 Disclaimer of Validity 322 This document and the information contained herein are provided on an 323 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 324 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 325 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 326 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 327 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 330 Copyright Statement 332 Copyright (C) The Internet Society (2004). This document is subject 333 to the rights, licenses and restrictions contained in BCP 78, and 334 except as set forth therein, the authors retain all their rights. 336 Acknowledgment 338 Funding for the RFC Editor function is currently provided by the 339 Internet Society.