idnits 2.17.00 (12 Aug 2021) /tmp/idnits60870/draft-nerenberg-sasl-crammd5-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2002) is 7126 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: 'MD5' is defined on line 165, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KEYED-MD5') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'NFKC' ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 5 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-nerenberg-sasl-crammd5-03.txt November 2002 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 20 documents at any time. It is inappropriate to use Internet Drafts 21 as 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 27 The list of Internet Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 A revised version of this draft document will be submitted to the 31 RFC editor as a Proposed Standard for the Internet Community. 32 Discussion and suggestions for improvement are requested. 33 Distribution of this draft is unlimited. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 How to Read This Document 41 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 42 in this document are to be interpreted as defined in [KEYWORDS]. 44 1. Introduction 46 This document defines a simple challenge-response [SASL] 47 authentication mechanism, using a [KEYED-MD5] digest. 49 2. CRAM-MD5 Authentication Mechanism 51 The mechanism name associated with CRAM-MD5 is 'CRAM-MD5'. 53 This mechanism does not provide a security layer. 55 The data encoded in the challenge contains a presumptively 56 arbitrary string of random digits, a timestamp, and the fully- 57 qualified primary host name of the server. 59 The client makes note of the data and then responds with a string 60 consisting of the user name, a space, and a "digest." The latter 61 is computed by applying the keyed MD5 algorithm from [KEYED-MD5] 62 where the key is a shared secret and the digested text is the 63 challenge (including angle-brackets). The client MUST NOT interpret 64 or attempt to validate the contents of the challenge in any way. 66 This shared secret is a string known only to the client and server. 67 The "digest" parameter itself is a 16-octet value which is sent in 68 hexadecimal format, using lower-case US-ASCII characters. 70 When the server receives this client response, it verifies the 71 digest provided. Since the user name may contain the space 72 character, the server MUST scan the client response from right to 73 left; the first space character encountered separates the digest 74 from the user name. If the digest is correct, the server should 75 consider the client authenticated and respond appropriately. 77 The user name and shared secret MUST be represented in the Unicode 78 character set [UNICODE], and MUST be normalised using the Unicode 79 Normalisation Form KC [NFKC]. The resulting values MUST be encoded 80 as UTF-8 [UTF8]. 82 2.1. Formal Syntax 84 The following syntax specification uses the augmented Backus-Naur 85 Form (ABNF) as specified in [ABNF], and incorporates by reference 86 the Core Rules defined in that document. 88 challenge = "<" 1*DIGIT "." 1*DIGIT "@" hostname ">" 90 digest = 32(DIGIT / %x61-66) 91 ; A hexadecimal string using only lower-case 92 ; letters 94 hostname = 1*(ALPHA / DIGIT) *("." / "-" / ALPHA / DIGIT) 96 response = user SP digest 98 user = 1*OCTET 100 2.2. Examples 102 The examples in this section do NOT form part of the specification. 103 Where conflicts exist between the examples and the formal grammar 104 or specification text, the latter are authoritative. 106 These examples show the use of the CRAM-MD5 mechanism with the 107 IMAP4 AUTHENTICATE command [IMAP4]. The base64 encoding of the 108 challenges and responses is part of the IMAP4 AUTHENTICATE command, 109 not part of the CRAM-MD5 specification itself. 111 S: * OK IMAP4rev1 Server 112 C: A0001 AUTHENTICATE CRAM-MD5 113 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ 114 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 115 S: A0001 OK CRAM-MD5 authentication successful 117 In this example, the shared secret is the string 119 tanstaaftanstaaf 121 Hence, the Keyed MD5 digest is produced by calculating 123 MD5((tanstaaftanstaaf XOR opad), 124 MD5((tanstaaftanstaaf XOR ipad), 125 <1896.697170952@postoffice.reston.mci.net>)) 127 where ipad and opad are as defined in [KEYED-MD5] and the string 128 shown in the challenge is the base64 encoding of 129 <1896.697170952@postoffice.reston.mci.net>. The shared secret is 130 null-padded to a length of 64 bytes. If the shared secret is longer 131 than 64 bytes, the MD5 digest of the shared secret is used as a 16 132 byte input to the keyed MD5 calculation. 134 This produces a digest value (in hexadecimal) of 136 b913a602c7eda7a495b4e6e7334d3890 138 The user name is then prepended to it, forming 140 tim b913a602c7eda7a495b4e6e7334d3890 142 Which is then base64 encoded to meet the requirements of the IMAP4 143 AUTHENTICATE command (or the similar POP3 AUTH command), yielding 145 dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw 147 3. References 149 3.1. Normative References 151 [ABNF] 152 Crocker, D., P. Overell, "Augmented BNF for Syntax 153 Specifications: ABNF", RFC2234, Internet Mail Consortium and 154 Demon Internet Ltd., November 1997. 156 [KEYED-MD5] 157 Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 158 Authentication", RFC 2104, IBM and UCSD, February 1997. 160 [KEYWORDS] 161 Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC2119, Harvard University, 163 March 1997. 165 [MD5] 166 Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT 167 Laboratory for Computer Science and RSA Data Security, Inc., 168 April 1992. 170 [NFKC] 171 Davis, M., M. Durst, "Unicode Standard Annex #15: Unicode 172 Normalisation Forms", An integral part of The Unicode 173 Standard, Version 3.2.0 174 (http://www.unicode.org/reports/tr15/). 176 [SASL] 177 Myers, J., "Simple Authentication and Security Layer (SASL)," 178 RFC 2222, Netscape Communications, October 1997. 180 [UNICODE] 181 The Unicode Consortium, The Unicode Standard, Version 3.2.0, 182 defined by: The Unicode Standard, Version 3.0 (Reading, MA, 183 Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the 184 Unicode Standard Annex #27: Unicode 3.1 185 (http://www.unicode.org/reports/tr27/) and the Unicode 186 Standard Annex #28: Unicode 3.2 187 (http://www.unicode.org/reports/tr28/) 189 [UTF8] 190 Yergeau, F., "UTF-8, a transformation format of ISO 10646", 191 RFC 2279, Alis Technologies, January 1998. 193 3.2. Informative References 195 [IMAP4] 196 Crispin, M., "Internet Message Access Protocol - Version 197 4rev1," Work in progress (son of RFC2060) 199 4. Security Considerations 201 It is conjectured that use of the CRAM-MD5 authentication mechanism 202 provides replay protection for a session. 204 This mechanism does not obscure the user name in any way. 205 Accordingly, a server that implements both a cleartext password 206 command and this authentication type should not allow both methods 207 of access for a given user name. 209 Keyed MD5 is chosen for this application because of the greater 210 security imparted to authentication of short messages. In addition, 211 the use of the techniques described in [KEYED-MD5] for 212 precomputation of intermediate results make it possible to avoid 213 explicit cleartext storage of the shared secret on the server 214 system by instead storing the intermediate results which are known 215 as "contexts." 217 While the saving, on the server, of the MD5 "context" is marginally 218 better than saving the shared secrets in cleartext, it is not 219 sufficient to protect the secrets if the server itself is 220 compromised. Consequently, servers that store the secrets or 221 contexts must both be protected to a level appropriate to the 222 potential information value in the data and services protected by 223 this mechanism. In other words, techniques like this one involve a 224 tradeoff between vulnerability to network sniffing and I/O buffer 225 snooping and vulnerability of the server host's databases. If one 226 believes that the host and its databases are subject to compromise, 227 and the network is not, this technique (and all others like it) is 228 unattractive. It is perhaps even less attractive than cleartext 229 passwords, which are typically stored on hosts in one-way hash 230 form. On the other hand, if the server databases are perceived as 231 reasonably secure, and one is concerned about client-side or 232 network interception of the passwords (secrets), then this (and 233 similar) techniques are preferable to clear-text passwords by a 234 wide margin. 236 As the length of the shared secret increases, so does the 237 difficulty of deriving it. 239 While there are now suggestions in the literature that the use of 240 MD5 and keyed MD5 in authentication procedures probably has a 241 limited effective lifetime, the technique is now widely deployed 242 and widely understood. It is believed that this general 243 understanding may assist with the rapid replacement, by CRAM-MD5, 244 of the current uses of permanent cleartext passwords in many 245 protocols. This document has been deliberately written to permit 246 easy upgrading to use SHA (or whatever alternatives emerge) when 247 they are considered to be widely available and adequately safe. 249 Even with the use of CRAM-MD5, users are still vulnerable to active 250 attacks. An example of an increasingly common active attack is 251 'TCP Session Hijacking' as described in CERT Advisory CA-95:01. 253 5. Contributors 255 The CRAM-MD5 mechanism was originally specified in RFC 2095, 256 IMAP/POP AUTHorize Extension for Simple Challenge/Response. The 257 authors of that document -- John C. Klensin, Paul Krumviede, and 258 Randy Catoe -- are to be credited with the design and specification 259 of CRAM-MD5. This memo serves only to re-state CRAM-MD5 within the 260 formal context of SASL, which specification it preceeded by several 261 months. 263 6. Intellectual Property 265 The IETF takes no position regarding the validity or scope of any 266 intellectual property or other rights that might be claimed to 267 pertain to the implementation or use of the technology described in 268 this document or the extent to which any license under such rights 269 might or might not be available; neither does it represent that it 270 has made any effort to identify any such rights. Information on 271 the IETF's procedures with respect to rights in standards-track and 272 standards-related documentation can be found in BCP-11. Copies of 273 claims of rights made available for publication and any assurances 274 of licenses to be made available, or the result of an attempt made 275 to obtain a general license or permission for the use of such 276 proprietary rights by implementors or users of this specification 277 can be obtained from the IETF Secretariat. 279 The IETF invites any interested party to bring to its attention any 280 copyrights, patents or patent applications, or other proprietary 281 rights which may cover technology that may be required to practice 282 this standard. Please address the information to the IETF 283 Executive Director. 285 7. Authors' Address 287 Lyndon Nerenberg 288 Orthanc Systems 289 508 - 11025 Jasper Avenue 290 Edmonton, Alberta 291 Canada T5K 0K7 292 Email: lyndon@orthanc.ab.ca 294 8. Full Copyright Statement 296 Copyright (C) The Internet Society (2002). All Rights Reserved. 298 This document and translations of it may be copied and furnished to 299 others, and derivative works that comment on or otherwise explain 300 it or assist in its implmentation may be prepared, copied, 301 published and distributed, in whole or in part, without restriction 302 of any kind, provided that the above copyright notice and this 303 paragraph are included on all such copies and derivative works. 304 However, this document itself may not be modified in any way, such 305 as by removing the copyright notice or references to the Internet 306 Society or other Internet organizations, except as needed for the 307 purpose of developing Internet standards in which case the 308 procedures for copyrights defined in the Internet Standards process 309 must be followed, or as required to translate it into languages 310 other than English. 311 The limited permissions granted above are perpetual and will not be 312 revoked by the Internet Society or its successors or assigns. 314 This document and the information contained herein is provided on 315 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 316 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 317 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 318 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 319 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.