idnits 2.17.1 draft-newman-auth-scram-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 467. 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 : ---------------------------------------------------------------------------- No issues found here. 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 2007) is 6251 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: 'RFC3986' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC4422' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC1939' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC2195' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC2202' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC2289' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'DIGEST-MD5' is defined on line 411, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 2828 (Obsoleted by RFC 4949) == Outdated reference: A later version (-12) exists of draft-ietf-sasl-rfc2831bis-11 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Abhijit Menon-Sen 3 Internet-Draft Oryx Mail Systems GmbH 4 Intended Status: Proposed Standard Chris Newman 5 Expires: September 6, 2007 Sun Microsystems 6 March 2007 8 Salted Challenge Response Authentication Mechanism (SCRAM) 9 draft-newman-auth-scram-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 30 Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft expires in September 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The secure authentication mechanism most widely deployed and used by 42 Internet application protocols, is the transmission of clear-text 43 passwords over a channel protected by Transport Layer Security 44 (TLS). There are some significant security concerns with that 45 mechanism which could be addressed by the use of a challenge 46 response authentication mechanism protected by TLS. Unfortunately, 47 the challenge response mechanisms presently on the standards track 48 all fail to meet requirements necessary for widespread deployment 49 and have had success only in limited use. 51 This specification describes the Salted Challenge Response 52 Authentication Mechanism (SCRAM) which addresses the deployability 53 requirements. When used in combination with Transport Layer 54 Security or an equivalent security layer, this mechanism could 55 improve the status-quo for application protocol authentication and 56 provide a suitable choice for a mandatory-to-implement mechanism for 57 future application protocol standards. 59 1. Conventions Used in This Document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 Formal syntax is defined by [RFC4234] including the core rules 66 defined in Appendix B of [RFC4234]. 68 Example lines prefaced by "C:" are sent by the client and ones 69 prefaced by "S:" by the server. If a single "C:" or "S:" label 70 applies to multiple lines, then the line breaks between those lines 71 are for editorial clarity only and are not part of the actual 72 protocol exchange. 74 1.1. Terminology 76 This document uses several terms defined in [RFC2828] ("Internet 77 Security Glossary") including the following: authentication, 78 authentication exchange, authentication information, brute force, 79 challenge-response, cryptographic hash function, dictionary attack, 80 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 81 one-way encryption function, password, replay attack and salt. 82 Readers not familiar with these terms should use that glossary as a 83 reference. 85 Some clarifications and additional definitions follow: 87 - Authentication information: Information used to verify an identity 88 claimed by a SCRAM client. The authentication information for a 89 SCRAM identity consists of salt, and for each cryptographic hash 90 function supported, it includes the "StoredKey" and the 91 "ServerKey" (the latter two are defined in the algorithm 92 overview). 94 - Authentication database: The database used to look up the 95 authentication information associated with a particular identity. 96 For application protocols, LDAPv3 (see [RFC4510]) is frequently 97 used as the authentication database. For network-level protocols 98 such as PPP or 802.11x, the use of RADIUS is more common. 100 - Base64: An encoding mechanism defined in [RFC2045] which converts 101 an octet string input to a textual output string which can be 102 easily displayed to a human. Although MIME permits arbitrary 103 insertion of whitespace and other characters, use of base64 in 104 SCRAM is restricted to the canonical form with no whitespace. 106 - Octet: An 8-bit byte. 108 - Octet string: A sequence of 8-bit bytes. 110 - Salt: A random octet string that is combined with a password 111 before applying a one-way encryption function. This value is used 112 to protect passwords that are stored in an authentication 113 database. 115 1.2. Notation 117 The pseudocode description of the algorithm uses the following 118 notations: 120 - ":=": The variable on the left hand side represents the octet 121 string resulting from the expression on the right hand side. 123 - "+": Octet string concatenation. 125 - "[ ]": A portion of an expression enclosed in "[" and "]" may not 126 be included in the result under some circumstances. See the 127 associated text for a description of those circumstances. 129 - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 130 [RFC2104]) using the octet string represented by "key" as the key 131 and the octet string "str" as the input string. The size of the 132 result is the hash result size for the hash function in use. For 133 example, it is 20 octets for SHA-1 (see [RFC3174]). 135 - H(str): Apply the cryptographic hash function to the octet string 136 "str", producing an octet string as a result. The size of the 137 result depends on the hash result size for the hash function in 138 use. 140 - Hi(str): Apply the cryptographic hash function to the octet string 141 "str", then repeat the application on the output string for a 142 number of iterations equal to the integer i minus 1. 144 - XOR: Apply the exclusive-or operation to combine the octet string 145 on the left of this operator with the octet string on the right of 146 this operator. The length of the output and each of the two 147 inputs will be the same for this use. 149 2. Introduction 151 This specification describes the Salted Challenge Response 152 Authentication Mechanism (SCRAM) which addresses the requirements 153 necessary to deploy a challenge-response mechanism more widely than 154 past attempts. When used in combination with Transport Layer 155 Security (TLS, see [RFC4346]) or an equivalent security layer, this 156 mechanism could improve the status-quo for application protocol 157 authentication and provide a suitable choice for a mandatory-to- 158 implement mechanism for future application protocol standards. 160 For simplicity, this mechanism does not presently include 161 negotiation of a security layer. It is intended to be used with an 162 external security layer such as that provided by TLS or SSH. 164 SCRAM provides the following protocol features: 166 - The authentication information stored in the authentication 167 database is not sufficient by itself to impersonate the client. 168 The information is salted to prevent a pre-stored dictionary 169 attack if the database is stolen. 171 - The server does not gain the ability to impersonate the client to 172 other servers (with an exception for server-authorized proxies). 174 - The mechanism permits the use of a server-authorized proxy without 175 requiring that proxy to have super-user rights with the back-end 176 server. 178 - A standard attribute is defined to enable storage of the 179 authentication information in LDAPv3 (see [RFC4510]). 181 - Bindings to several authentication frameworks are provided so the 182 mechanism is not limited to a small subset of protocols. 184 - Both the client and server can be authenticated by the protocol. 186 - The cryptographic hash function used to authenticate can be 187 upgraded gracefully without breaking backwards compatibility or 188 risking downgrade attacks. 190 For an in-depth discussion of why other challenge response 191 mechanisms are not considered sufficient, see appendix A. For more 192 information about the motivations behind the design of this 193 mechanism, see appendix B. 195 Comments regarding this draft may be sent either to the ietf- 196 sasl@imc.org mailing list or to the authors. 198 3. SCRAM Algorithm Overview 200 Here is a psuedocode overview of the complete SCRAM algorithm: 202 SaltedPassword := Hi(HMAC(password, salt)) 203 ClientKey := H(SaltedPassword) 204 StoredKey := H(ClientKey) 205 Message := [FirstClientMessage + "," + 206 FirstServerMessage + "," +] 207 FinalClientMessageExcludingP 208 ClientSignature := HMAC(StoredKey, Message) 209 ClientProof := ClientKey XOR ClientSignature 210 ServerKey := HMAC(SaltedPassword, salt) 211 ServerSignature := HMAC(ServerKey, Message) 213 The client has access to the user's password and once it gets the 214 value of the salt and the value of i from the server, it can 215 determine all of the above values. The authentication information 216 which the server stores consists of the "salt", the "StoredKey" and 217 the "ServerKey". The server authenticates the client by computing 218 the ClientSignature, exclusive-oring that with the ClientProof to 219 recover the ClientKey and verifying the correctness of the ClientKey 220 by applying the hash function and comparing the result to the 221 StoredKey. 223 4. SCRAM Authentication Exchange 225 The SCRAM protocol is a textual protocol with a comma-separated list 226 of attribute value pairs. Each attribute has a name with one 227 letter. An example of a simple protocol exchange follows: 229 C: r=ClientNonce,n=Chris Newman 230 S: r=ClientNonceServerNonce,i=128,s=PxR/wv+epq 231 C: r=ClientNonceServerNonce, 232 c=QWBv+XbwcaI/wp,p=WxPv/siO5l+qxN4 234 S: v=WxPv/siO5l+qxN4 236 The client sends the first message to provide the user name whose 237 password will be used, a random and unique nonce and a list of the 238 cryptographic hash functions the client supports. The server 239 responds by appending additional randomness on the end of the nonce, 240 providing the list of hash functions it supports, and providing the 241 base64-encoded salt from that user's authentication information. 242 The client then authenticates by repeating the nonce, stating the 243 resource to which it is authenticating, an optional base64-encoded 244 channel binding (discussed later) and a proof that it has the user's 245 password. Unless the client has choosen to skip the server 246 authentication step (discussed later), the server responds with a 247 verification proof that the server has the appropriate password 248 verifier. 250 A more detailed description of the protocol elements follows: 252 - a: This attribute can be provided in the client's first message. 253 It specifies the authorization identity. When this is omitted or 254 empty, it is presumed to be the same as the "n" attribute. When 255 this is different from the "n" attribute, then the "n" attribute 256 specifies the user name whose password will be used for 257 authentication, while the "a" attribute specifies the user whose 258 identity will be associated with the connection subsequent to 259 successful authentication and authorization. This is typically 260 used when an administrative user wishes to impersonate another 261 user to perform some management role for that user. It can also 262 be used by proxies in some situations (see appendix A for more 263 information). The syntax of this field is the same as that of the 264 "n" field with respect to quoting of '=' and ','. 266 - c: This base64-encoded string is the channel binding. Whether 267 this is included and the meaning of the contents of this string 268 depends on the external security layer used with this mechanism. 269 See section XXX for more details. If this is present, the 270 authentication MUST fail unless this value is successfully 271 verified. In other words, if it appears when not expected then an 272 automatic authentication failure results. This is necessary to 273 detect a man-in-the-middle attack on the security layer (see 274 security considerations for details). 276 - n: This is the name of the user whose password is used for 277 authentication. In most cases, the "a" attribute is omitted and 278 this also specifies the identity which will be associated with the 279 connection subsequent to authentication and authorization. If the 280 actual name contains the characters ',' or '=', then a quoting 281 mechanism is applied which converts these characters to '=2C' and 282 '=3D' respectively. If the server receives a name string which 283 contains '=' not followed by either '2C' or '3D', then the server 284 MUST fail the authentication. 286 - p: This base64-encoded string provides the client's proof of 287 authentication. This is the last attribute in the message. See 288 the algorithm overview for the computation. 290 - r: This is a sequence of random printable characters excluding ',' 291 which forms the nonce used as input to the hash function. No 292 quoting is applied to this string (unless the binding of SCRAM to 293 a particular protocol states otherwise). The client provides the 294 first part of the string and the server provides the second part. 295 It is important that this be different for each authentication and 296 it is important that the client verifies the first part of this 297 string used in all messages was provided by the client. 299 - s: This is a base64-encoded string which represents the salt used 300 by the server for this user. 302 - v: This is used to verify the server has access to the user's 303 authentication information. If the client supplies the "v" 304 attribute with an empty value in the message with a "p", that 305 indicates the client does not want the server to provide 306 verification. When the server includes this in the final message, 307 it is always the last attribute in the message. See the next 308 section for the computation. 310 5. Security Considerations 312 If the authentication exchange is performed without a strong 313 security layer, then a passive eavesdropper can gain sufficient 314 information to mount an offline dictionary or brute-force attack 315 which can be used to recover the user's password. The amount of 316 time necessary for this attack depends on the cryptographic hash 317 function selected, the strength of the password and the iteration 318 count supplied by the server. An external security layer with 319 strong encryption will prevent this attack. 321 If the external security layer used to protect the SCRAM exchange 322 uses an anonymous key exchange, then the SCRAM channel binding 323 mechanism can be used to detect a man-in-the-middle attack on the 324 security layer and cause the authentication to fail as a result. 325 However, the man-in-the-middle attacker will have gained sufficient 326 information to mount an offline dictionary or brute-force attack. 327 For this reason, SCRAM includes the ability to increase the 328 iteration count over time. 330 If the authentication information is stolen from the authentication 331 database, then an offline dictionary or brute-force attack can be 332 used to recover the user's password. The use of salt mitigates this 333 attack somewhat by requiring a separate attack on each password. 334 Authentication mechanisms which protect against this attack are 335 available (e.g., the EKE class of mechanisms), but the patent 336 situation is presently unclear. 338 If an attacker obtains the authentication information from the 339 authentication repository and eavesdrops on one authentication 340 exchange, the attacker gains the ability to impersonate that user to 341 all servers providing SCRAM access using the same password and salt. 343 6. IANA considerations 345 (Hash function names registry, SASL mechanism registration.) 347 7. Acknowedgements 349 (Frank Ellermann already?) 351 8. Normative References 353 [RFC2045] Freed, Borenstein, "Multipurpose Internet Mail Extensions 354 (MIME) Part One: Format of Internet Message Bodies", RFC 355 2045, Innosoft, November 1996. 357 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 358 Message Authentication", IBM, February 1997. 360 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 361 pRequirement Levels", RFC 2119, Harvard University, March 362 1997. 364 [RFC3174] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 365 3174, Motorola, September 2001 367 [RFC3986] Berners-Lee, Fielding, Masinter, "Uniform Resource 368 Identifier (URI): Generic Syntax", RFC 3986, W3C/MIT, 369 January 2005. 371 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 372 Specifications: ABNF", RFC 4234, Brandenburg 373 Internetworking, Demon Internet Ltd, October 2005. 375 [RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS) 376 Protocol, Version 1.1", RFC 4346, Brandenburg 377 Internetworking, April 2006. 379 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 380 Layer (SASL)", RFC 4422, Isode Limited, June 2006. 382 9. Informative References 384 [RFC1939] Myers, Rose, "Post Office Protocol - Version 3", RFC 385 1939, Carnegie Mellon, May 1996. 387 [RFC2195] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 388 for Simple Challenge/Response", RFC 2195, MCI, September 389 1997. 391 [RFC2202] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 392 RFC 2202, IBM, September 1997 394 [RFC2289] Haller, Metz, Nesser, Straw, "A One-Time Password 395 System", RFC 2289, STD0061, February 1998. 397 [RFC2828] Shirey, "Internet Security Glossary", RFC 2828, FYI 0036, 398 May 2000. 400 [RFC4086] Eastlake, Schiller, Crocker, "Randomness Requirements for 401 Security", RFC 4086, BCP 0106, Motorola Laboratories, 402 June 2005. 404 [RFC4120] Neuman, Yo, Hartman, Raebun, "The Kerberos Network 405 Authentication Service (V5)", RFC 4120, USC-ISI, July 406 2005. 408 [RFC4510] Zeilenga, "Lightweight Directory Access Protocol (LDAP): 409 Technical Specification Road Map", RFC 4510, June 2006. 411 [DIGEST-MD5] Melnikov, "Using Digest Authentication as a SASL 412 Mechanism", draft-ietf-sasl-rfc2831bis-11.txt, Isode 413 Ltd., November 2006 415 10. Authors' Addresses 417 Abhijit Menon-Sen 418 Oryx Mail Systems GmbH 420 Email: ams@oryx.com 421 Chris Newman 422 Sun Microsystems 423 1050 Lakes Drive 424 West Covina, CA 91790 425 USA 427 Email: chris.newman@sun.com 429 Appendix A: Other Authentication Mechanisms 431 (To be written.) 433 Appendix B: Design Motivations 435 (To be written.) 437 Appendix C: SCRAM Examples 439 (To be written.) 441 Appendix D: SCRAM Interoperability Testing 443 (To be written.) 445 Intellectual Property Statement 447 The IETF takes no position regarding the validity or scope of any 448 Intellectual Property Rights or other rights that might be claimed 449 to pertain to the implementation or use of the technology described 450 in this document or the extent to which any license under such 451 rights might or might not be available; nor does it represent that 452 it has made any independent effort to identify any such rights. 453 Information on the procedures with respect to rights in RFC 454 documents can be found in BCP 78 and BCP 79. 456 Copies of IPR disclosures made to the IETF Secretariat and any 457 assurances of licenses to be made available, or the result of an 458 attempt made to obtain a general license or permission for the use 459 of such proprietary rights by implementers or users of this 460 specification can be obtained from the IETF on-line IPR repository 461 at http://www.ietf.org/ipr. 463 The IETF invites any interested party to bring to its attention any 464 copyrights, patents or patent applications, or other proprietary 465 rights that may cover technology that may be required to implement 466 this standard. Please address the information to the IETF at ietf- 467 ipr@ietf.org. 469 Full Copyright Statement 471 Copyright (C) The IETF Trust (2007). This document is subject to 472 the rights, licenses and restrictions contained in BCP 78, and 473 except as set forth therein, the authors retain all their rights. 475 This document and the information contained herein are provided on 476 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 477 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 478 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 479 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 480 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 481 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 482 FOR A PARTICULAR PURPOSE. 484 Acknowledgment 486 Funding for the RFC Editor function is currently provided by the 487 Internet Society. 489 (RFC Editor: Please delete everything after this point) 491 Open Issues 493 Appendixes A, B and C need to be written. 495 D too, and the framework implemented. 497 Should the title include the acronym SASL to help the greppers? 499 Changes since -03 501 - Seven years have passed, in which it became clear that DIGEST-MD5 502 suffered from unacceptably bad interoperability, so SCRAM-MD5 is 503 now bad from the dead. 505 - Be hash agnostic, so MD5 can be replaced more easily 507 - General simplification.