idnits 2.17.1 draft-newman-auth-scram-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 31, 2009) is 5564 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) == Missing Reference: 'RFCXXXX' is mentioned on line 568, but not defined == Unused Reference: 'RFC2195' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC2202' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 644, 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 4013 (ref. 'SASLPrep') (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 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: July 2009 Sun Microsystems 6 Alexey Melnikov 7 Isode Ltd 8 January 31, 2009 10 Salted Challenge Response (SCRAM) SASL Mechanism 12 draft-newman-auth-scram-08.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and 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 25 months and may be updated, replaced, or obsoleted by other documents 26 at any 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. The list of Internet- 31 Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft expires in July 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. 48 Internet-draft January 2009 50 Abstract 52 The secure authentication mechanism most widely deployed and used by 53 Internet application protocols is the transmission of clear-text 54 passwords over a channel protected by Transport Layer Security 55 (TLS). There are some significant security concerns with that 56 mechanism, which could be addressed by the use of a challenge 57 response authentication mechanism protected by TLS. Unfortunately, 58 the challenge response mechanisms presently on the standards track 59 all fail to meet requirements necessary for widespread deployment, 60 and have had success only in limited use. 62 This specification describes a family of authentication mechanisms 63 called the Salted Challenge Response Authentication Mechanism 64 (SCRAM), which addresses the security concerns and meets the 65 deployability requirements. When used in combination with TLS or an 66 equivalent security layer, a mechanism from this family could 67 improve the status-quo for application protocol authentication and 68 provide a suitable choice for a mandatory-to-implement mechanism for 69 future application protocol standards. 71 1. Conventions Used in This Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 Formal syntax is defined by [RFC5234] including the core rules 78 defined in Appendix B of [RFC5234]. 80 Example lines prefaced by "C:" are sent by the client and ones 81 prefaced by "S:" by the server. If a single "C:" or "S:" label 82 applies to multiple lines, then the line breaks between those lines 83 are for editorial clarity only, and are not part of the actual 84 protocol exchange. 86 1.1. Terminology 88 This document uses several terms defined in [RFC4949] ("Internet 89 Security Glossary") including the following: authentication, 90 authentication exchange, authentication information, brute force, 91 challenge-response, cryptographic hash function, dictionary attack, 92 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 93 one-way encryption function, password, replay attack and salt. 94 Readers not familiar with these terms should use that glossary as a 95 reference. 97 Internet-draft January 2009 99 Some clarifications and additional definitions follow: 101 - Authentication information: Information used to verify an identity 102 claimed by a SCRAM client. The authentication information for a 103 SCRAM identity consists of salt, iteration count, the "StoredKey" 104 and "ServerKey" (as defined in the algorithm overview) for each 105 supported cryptographic hash function. 107 - Authentication database: The database used to look up the 108 authentication information associated with a particular identity. 109 For application protocols, LDAPv3 (see [RFC4510]) is frequently 110 used as the authentication database. For network-level protocols 111 such as PPP or 802.11x, the use of RADIUS is more common. 113 - Base64: An encoding mechanism defined in [RFC4648] which converts 114 an octet string input to a textual output string which can be 115 easily displayed to a human. The use of base64 in SCRAM is 116 restricted to the canonical form with no whitespace. 118 - Octet: An 8-bit byte. 120 - Octet string: A sequence of 8-bit bytes. 122 - Salt: A random octet string that is combined with a password 123 before applying a one-way encryption function. This value is used 124 to protect passwords that are stored in an authentication 125 database. 127 1.2. Notation 129 The pseudocode description of the algorithm uses the following 130 notations: 132 - ":=": The variable on the left hand side represents the octet 133 string resulting from the expression on the right hand side. 135 - "+": Octet string concatenation. 137 - "[ ]": A portion of an expression enclosed in "[" and "]" may not 138 be included in the result under some circumstances. See the 139 associated text for a description of those circumstances. 141 - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 142 [RFC2104]) using the octet string represented by "key" as the key 143 and the octet string "str" as the input string. The size of the 144 result is the hash result size for the hash function in use. For 145 example, it is 20 octets for SHA-1 (see [RFC3174]). 147 Internet-draft January 2009 149 - H(str): Apply the cryptographic hash function to the octet string 150 "str", producing an octet string as a result. The size of the 151 result depends on the hash result size for the hash function in 152 use. 154 - XOR: Apply the exclusive-or operation to combine the octet string 155 on the left of this operator with the octet string on the right of 156 this operator. The length of the output and each of the two inputs 157 will be the same for this use. 159 - Hi(str, salt): 161 U0 := HMAC(str, salt || INT(1)) 162 U1 := HMAC(str, U0) 163 U2 := HMAC(str, U1) 164 ... 165 Ui-1 := HMAC(str, Ui-2) 166 Ui := HMAC(str, Ui-1) 168 Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui 169 where "i" is the iteration count, "||" is the string concatenation 170 operator and INT(g) is a four-octet encoding of the integer g, 171 most significant octet first. 173 This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 174 with dkLen == output length of HMAC() == output length of H(). 176 2. Introduction 178 This specification describes a family of authentication mechanisms 179 called the Salted Challenge Response Authentication Mechanism 180 (SCRAM) which addresses the requirements necessary to deploy a 181 challenge-response mechanism more widely than past attempts. When 182 used in combination with Transport Layer Security (TLS, see [TLS]) 183 or an equivalent security layer, a mechanism from this family could 184 improve the status-quo for application protocol authentication and 185 provide a suitable choice for a mandatory-to-implement mechanism for 186 future application protocol standards. 188 For simplicity, this family of mechanism does not presently include 189 negotiation of a security layer. It is intended to be used with an 190 external security layer such as that provided by TLS or SSH. 192 SCRAM provides the following protocol features: 194 - The authentication information stored in the authentication 196 Internet-draft January 2009 198 database is not sufficient by itself to impersonate the client. 199 The information is salted to prevent a pre-stored dictionary 200 attack if the database is stolen. 202 - The server does not gain the ability to impersonate the client to 203 other servers (with an exception for server-authorized proxies). 205 - The mechanism permits the use of a server-authorized proxy without 206 requiring that proxy to have super-user rights with the back-end 207 server. 209 - A standard attribute is defined to enable storage of the 210 authentication information in LDAPv3 (see [RFC4510]). 212 - Both the client and server can be authenticated by the protocol. 214 For an in-depth discussion of why other challenge response 215 mechanisms are not considered sufficient, see appendix A. For more 216 information about the motivations behind the design of this 217 mechanism, see appendix B. 219 Comments regarding this draft may be sent either to the ietf- 220 sasl@imc.org mailing list or to the authors. 222 3. SCRAM Algorithm Overview 224 Note that this section omits some details, such as client and server 225 nonces. See Section 5 for more details. 227 To begin with, the client is in possession of a username and 228 password. It sends the username to the server, which retrieves the 229 corresponding authentication information, i.e. a salt, StoredKey, 230 ServerKey and the iteration count. (Note that a server 231 implementation may chose to use the same iteration count for all 232 account.) The server sends the salt and an iteration count to the 233 client, which then computes the following values and sends a 234 ClientProof to the server: 236 SaltedPassword := Hi(password, salt) 237 ClientKey := H(SaltedPassword) 238 StoredKey := H(ClientKey) 239 AuthMessage := client-first-message + "," + 240 server-first-message + "," + 241 final-client-message-without-proof 242 ClientSignature := HMAC(StoredKey, AuthMessage) 243 ClientProof := ClientKey XOR ClientSignature 244 ServerKey := HMAC(SaltedPassword, salt) 246 Internet-draft January 2009 248 ServerSignature := HMAC(ServerKey, AuthMessage) 250 The server authenticates the client by computing the 251 ClientSignature, exclusive-ORing that with the ClientProof to 252 recover the ClientKey and verifying the correctness of the ClientKey 253 by applying the hash function and comparing the result to the 254 StoredKey. If the ClientKey is correct, this proves that the client 255 has access to the user's password. 257 Similarly, the client authenticates the server by computing the 258 ServerSignature and comparing it to the value sent by the server. 259 If the two are equal, it proves that the server had access to the 260 user's SaltedPassword. 262 The AuthMessage is computed by concatenating messages from the 263 authentication exchange. The format of these messages is defined in 264 the Formal Syntax section. 266 4. SCRAM mechanism names 268 A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the 269 uppercased name of the underlying hashed function taken from the 270 IANA "Hash Function Textual Names" registry (see 271 http://www.iana.org). 273 For interoperability, all SCRAM clients and servers MUST implement 274 the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an 275 authentication mechanism from the SCRAM family that uses the SHA-1 276 hash function as defined in [RFC3174]. 278 5. SCRAM Authentication Exchange 280 SCRAM is a text protocol where the client and server exchange 281 messages containing one or more attribute-value pairs separated by 282 commas. Each attribute has a one-letter name. The messages and their 283 attributes are described in section 5.1, and defined in the Formal 284 Syntax section. 286 This is a simple example of a SCRAM-HMAC-SHA-1 authentication 287 exchange: 288 C: n=Chris Newman,r=ClientNonce 289 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 290 C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 291 S: v=WxPv/siO5l+qxN4 293 First, the client sends a message containing the username, an 295 Internet-draft January 2009 297 optional authorization identity and a random, unique nonce. In 298 response, the server sends the user's iteration count i, the user's 299 salt, and appends its own nonce to the client-specified one. The 300 client then responds with the same nonce and a ClientProof computed 301 using the selected hash function as explained earlier. The server 302 verifies the nonce and the proof, verifies that the authorization 303 identity (if supplied by the client in the initial message) is 304 authorized to act as the authentication identity, and, finally, it 305 responds with a ServerSignature, concluding the authentication 306 exchange. The client then authenticates the server by computing the 307 ServerSignature and comparing it to the value sent by the server. 308 If the two are different, the client MUST consider the 309 authentication exchange to be unsuccessful and it might have to drop 310 the connection. 312 5.1 SCRAM attributes 314 This section describes the permissible attributes, their use, and 315 the format of their values. All attribute names are single US-ASCII 316 letters and are case-sensitive. 318 - a: This optional attribute specifies an authorization identity. A 319 client may include it in its first message to the server if it 320 wants to authenticate as one user, but subsequently act as a 321 different user. This is typically used by an administrator to 322 perform some management task on behalf of another user, or by a 323 proxy in some situations (see appendix A for more details). 325 Upon the receipt of this value the server verifies its correctness 326 according to the used SASL protocol profile. Failed verification 327 results in failed authentication exchange. 329 If this attribute is omitted (as it normally would be), or 330 specified with an empty value, the authorization identity is 331 assumed to be derived from the username specified with the 332 (required) "n" attribute. 334 The server always authenticates the user specified by the "n" 335 attribute. If the "a" attribute specifies a different user, the 336 server associates that identity with the connection after 337 successful authentication and authorization checks. 339 The syntax of this field is the same as that of the "n" field with 340 respect to quoting of '=' and ','. 342 - n: This attribute specifies the name of the user whose password is 343 used for authentication. A client must include it in its first 345 Internet-draft January 2009 347 message to the server. If the "a" attribute is not specified 348 (which would normally be the case), this username is also the 349 identity which will be associated with the connection subsequent 350 to authentication and authorization. 352 Before sending the username to the server, the client MUST prepare 353 the username using the "SASLPrep" profile [SASLPrep] of the 354 "stringprep" algorithm [RFC3454]. If the preparation of the 355 username fails or results in an empty string, the client SHOULD 356 abort the authentication exchange (*). 358 (*) An interactive client can request a repeated entry of the 359 username value. 361 Upon receipt of the username by the server, the server SHOULD 362 prepare it using the "SASLPrep" profile [SASLPrep] of the 363 "stringprep" algorithm [RFC3454]. If the preparation of the 364 username fails or results in an empty string, the server SHOULD 365 abort the authentication exchange. 367 The characters ',' or '=' in usernames are sent as '=2C' and '=3D' 368 respectively. If the server receives a username which contains '=' 369 not followed by either '2C' or '3D', then the server MUST fail the 370 authentication. 372 - m: This attribute is reserved for future extensibility. In this 373 version of SCRAM, its presence in a client or a server message 374 MUST cause authentication failure when the attribute is parsed by 375 the other end. 377 - r: This attribute specifies a sequence of random printable 378 characters excluding ',' which forms the nonce used as input to 379 the hash function. No quoting is applied to this string (unless 380 the binding of SCRAM to a particular protocol states otherwise). 381 As described earlier, the client supplies an initial value in its 382 first message, and the server augments that value with its own 383 nonce in its first response. It is important that this be value 384 different for each authentication. The client MUST verify that the 385 initial part of the nonce used in subsequent messages is the same 386 as the nonce it initially specified. The server MUST verify that 387 the nonce sent by the client in the second message is the same as 388 the one sent by the server in its first message. 390 - c: This optional attribute specifies base64-encoded channel- 391 binding data. It may be sent by either the client or the server. 392 If specified, the authentication MUST fail unless the value is 393 successfully verified. Whether this attribute is included, and 394 the meaning and contents of the channel-binding data depends on 396 Internet-draft January 2009 398 the external security layer in use. This is necessary to detect a 399 man-in-the-middle attack on the security layer. 401 - s: This attribute specifies the base64-encoded salt used by the 402 server for this user. It is sent by the server in its first 403 message to the client. 405 - i: This attribute specifies an iteration count for the selected 406 hash function and user, and must be sent by the server along with 407 the user's salt. 409 For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash 410 iteration-count of at least 128. 412 - p: This attribute specifies a base64-encoded ClientProof. The 413 client computes this value as described in the overview and sends 414 it to the server. 416 - v: This attribute specifies a base64-encoded ServerSignature. It 417 is sent by the server in its final message, and may be used by the 418 client to verify that the server has access to the user's 419 authentication information. This value is computed as explained in 420 the overview. 422 6. Formal Syntax 424 The following syntax specification uses the Augmented Backus-Naur 425 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 426 and "UTF8-4" non-terminal are defined in [UTF-8]. 428 generic-message = attr-val *("," attr-val) 430 attr-val = ALPHA "=" value 432 value = *(value-char) 434 value-safe-char = %01-2B / %2D-3C / %3E-7F / 435 UTF8-2 / UTF-3 / UTF8-4 436 ;; UTF8-char except NUL, "=", and ",". 438 value-char = value-safe-char / "=" 440 base64-char = ALPHA / DIGIT / "/" / "+" 442 base64-4 = 4*4(base64-char) 444 base64-3 = 3*3(base64-char) "=" 446 Internet-draft January 2009 448 base64-2 = 2*2(base64-char) "==" 450 base64 = *(base64-4) [base64-3 / base64-2] 452 saslname = 1*(value-safe-char / "=2C" / "=3D") 453 ;; Conforms to 455 authzid = "a=" saslname 456 ;; Protocol specific. 458 username = "n=" saslname 459 ;; Usernames are prepared using SASLPrep. 461 reserved-mext = "m=" 1*(value-char) 462 ;; Reserved for signalling mandatory extensions. 463 ;; The exact syntax will be defined in the 464 future. 466 channel-binding = "c=" base64 468 proof = "p=" base64 470 nonce = "r=" c-nonce [s-nonce] 471 ;; Second part provided by server. 473 c-nonce = value 475 s-nonce = value 477 salt = "s=" base64 479 verifier = "v=" base64 480 ;; base-64 encoded ServerSignature. 482 iteration-count = "i=" (%x31-39) *DIGIT 483 ;; A positive number 485 client-first-message = 486 [reserved-mext ","] [authzid ","] username "," 487 nonce ["," extensions] 489 server-first-message = 490 [reserved-mext ","] nonce "," salt "," 491 iteration-count ["," extensions] 493 client-final-message-without-proof = 494 nonce "," channel-binding ["," extensions] 496 Internet-draft January 2009 498 client-final-message = 499 client-final-message-without-proof "," proof 501 server-final-message = 502 verifier ["," extensions] 504 extensions = 505 511 7. Security Considerations 513 If the authentication exchange is performed without a strong 514 security layer, then a passive eavesdropper can gain sufficient 515 information to mount an offline dictionary or brute-force attack 516 which can be used to recover the user's password. The amount of time 517 necessary for this attack depends on the cryptographic hash function 518 selected, the strength of the password and the iteration count 519 supplied by the server. An external security layer with strong 520 encryption will prevent this attack. 522 If the external security layer used to protect the SCRAM exchange 523 uses an anonymous key exchange, then the SCRAM channel binding 524 mechanism can be used to detect a man-in-the-middle attack on the 525 security layer and cause the authentication to fail as a result. 526 However, the man-in-the-middle attacker will have gained sufficient 527 information to mount an offline dictionary or brute-force attack. 528 For this reason, SCRAM includes the ability to increase the 529 iteration count over time. 531 If the authentication information is stolen from the authentication 532 database, then an offline dictionary or brute-force attack can be 533 used to recover the user's password. The use of salt mitigates this 534 attack somewhat by requiring a separate attack on each password. 535 Authentication mechanisms which protect against this attack are 536 available (e.g., the EKE class of mechanisms), but the patent 537 situation is presently unclear. 539 If an attacker obtains the authentication information from the 540 authentication repository and either eavesdrops on one 541 authentication exchange or impersonates a server, the attacker gains 542 the ability to impersonate that user to all servers providing SCRAM 543 access using the same hash function, password, iteration count and 544 salt. For this reason, it is important to use randomly-generated 546 Internet-draft January 2009 548 salt values. 550 If the server detects (from the value of the client-specified "h" 551 attribute) that both endpoints support a stronger hash function that 552 the one the client actually chooses to use, then it SHOULD treat 553 this as a downgrade attack and reject the authentication attempt. 555 A hostile server can perform a computational denial-of-service 556 attack on clients by sending a big iteration count value. 558 8. IANA considerations 560 IANA is requested to add the following entry to the SASL Mechanism 561 registry established by [RFC4422]: 563 To: iana@iana.org 564 Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1 566 SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1 567 Security considerations: Section 7 of [RFCXXXX] 568 Published specification (optional, recommended): [RFCXXXX] 569 Person & email address to contact for further information: 570 IETF SASL WG 571 Intended usage: COMMON 572 Owner/Change controller: IESG 573 Note: 575 Note that even though this document defines a family of SCRAM-HMAC 576 mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in 577 the SASL Mechanisms registry. IANA is requested to prevent future 578 registrations of SASL mechanisms starting with SCRAM-HMAC- without 579 consulting the SASL mailing list first. 581 Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC 582 SASL mechanism MUST be explicitly registered with IANA and MUST 583 comply with SCRAM-HMAC mechanism naming convention defined in 584 Section 4 of this document. 586 9. Acknowedgements 588 The authors would like to thank Dave Cridland for his contributions 589 to this document. 591 Internet-draft January 2009 593 10. Normative References 595 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 596 Encodings", RFC 4648, SJD, October 2006. 598 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 599 10646", STD 63, RFC 3629, November 2003. 601 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 602 Message Authentication", IBM, February 1997. 604 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 605 Requirement Levels", RFC 2119, Harvard University, March 606 1997. 608 [RFC3174] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 609 3174, Motorola, September 2001 611 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax 612 Specifications: ABNF", RFC 5234, January 2008. 614 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 615 Layer (SASL)", RFC 4422, Isode Limited, June 2006. 617 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user 618 names and passwords", RFC 4013, February 2005. 620 [RFC3454] Hoffman, P., Blanchet, M., "Preparation of 621 Internationalized Strings ("stringprep")", RFC 3454, 622 December 2002. 624 11. Informative References 626 [RFC2195] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 627 for Simple Challenge/Response", RFC 2195, MCI, September 628 1997. 630 [RFC2202] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 631 RFC 2202, IBM, September 1997 633 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 634 Specification Version 2.0", RFC 2898, September 2000. 636 [TLS] Dierks, Rescorla, "The Transport Layer Security (TLS) 637 Protocol, Version 1.2", RFC 5246, August 2008. 639 Internet-draft January 2009 641 [RFC4949] Shirey, "Internet Security Glossary, Version 2", RFC 642 4949, FYI 0036, August 2007. 644 [RFC4086] Eastlake, Schiller, Crocker, "Randomness Requirements for 645 Security", RFC 4086, BCP 0106, Motorola Laboratories, 646 June 2005. 648 [RFC4510] Zeilenga, "Lightweight Directory Access Protocol (LDAP): 649 Technical Specification Road Map", RFC 4510, June 2006. 651 [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication 652 as a SASL Mechanism", RFC 2831, May 2000. <> 655 [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in 656 progress, draft-ietf-sasl-digest-to-historic-00.txt, July 657 2008 659 [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress, 660 draft-ietf-sasl-crammd5-to-historic-00.txt, November 661 2008. 663 [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security 664 Layer (SASL) Mechanism" RFC 4616, August 2006. 666 12. Authors' Addresses 668 Abhijit Menon-Sen 669 Oryx Mail Systems GmbH 671 Email: ams@oryx.com 673 Alexey Melnikov 674 Isode Ltd 676 EMail: Alexey.Melnikov@isode.com 678 Chris Newman 679 Sun Microsystems 680 1050 Lakes Drive 681 West Covina, CA 91790 682 USA 684 Email: chris.newman@sun.com 686 Internet-draft January 2009 688 Appendix A: Other Authentication Mechanisms 690 The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex 691 to implement and test, and thus has poor interoperability. The 692 security layer is often not implemented, and almost never used; 693 everyone uses TLS instead. For a more complete list of problems 694 with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST- 695 HISTORIC]. 697 The CRAM-MD5 SASL mechanism, while widely deployed has also some 698 problems, in particular it is missing some modern SASL features such 699 as support for internationalized usernames and passwords, support 700 for passing of authorization identity, support for channel bindings. 701 It also doesn't support server authentication. For a more complete 702 list of problems with CRAM-MD5 see [CRAM-HISTORIC]. 704 The PLAIN [PLAIN] SASL mechanism allows a malicious server or 705 eavesdropper to impersonate the authenticating user to any other 706 server for which the user has the same password. It also sends the 707 password in the clear over the network, unless TLS is used. Server 708 authentication is not supported. 710 Appendix B: Design Motivations 712 The following design goals shaped this document. Note that some of 713 the goals have changed since the initial version of the document. 715 The SASL mechanism has all modern SASL features: support for 716 internationalized usernames and passwords, support for passing of 717 authorization identity, support for channel bindings. 719 Both the client and server can be authenticated by the protocol. 721 The authentication information stored in the authentication 722 database is not sufficient by itself to impersonate the client. 724 <> 728 The mechanism can be used with Unix hashed password databases. 730 The mechanism is extensible, but [hopefully] not overengineered in 731 this respect. 733 Easier to implement than DIGEST-MD5 in both clients and servers. 735 Internet-draft January 2009 737 Appendix C: SCRAM Examples 739 <> 741 Internet-draft January 2009 743 (RFC Editor: Please delete everything after this point) 745 Open Issues 747 - The appendices need to be written. 749 - Should the server send a base64-encoded ServerSignature for the 750 value of the "v" attribute, or should it compute a ServerProof the 751 way the client computes a ClientProof? 753 Changes since -07 755 Updated References. 757 Clarified purpose of the m= attribute. 759 Fixed a problem with authentication/authorization identity's ABNF 760 not allowing for some characters. 762 Updated ABNF for nonce to show client-generated and server-generated 763 parts. 765 Only register SCRAM-HMAC-SHA-1 with IANA and require explicit 766 registrations of all other SCRAM-HMAC- mechanisms. 768 Changes since -06 770 Removed hash negotiation from SCRAM and turned it into a family of 771 SASL mechanisms. 773 Start using "Hash Function Textual Names" IANA registry for SCRAM 774 mechanism naming. 776 Fixed definition of Hi(str, salt) to be consistent with [RFC2898]. 778 Clarified extensibility of SCRAM: added m= attribute (for future 779 mandatory extensions) and specified that all unrecognized 780 attributes must be ignored. 782 Changes since -05 784 Changed the mandatory to implement hash algorithm to SHA-1 (as per 786 Internet-draft January 2009 788 WG consensus). 790 Added text about use of SASLPrep for username 791 canonicalization/validation. 793 Clarified that authorization identity is canonicalized/verified 794 according to SASL protocol profile. 796 Clarified that iteration count is per-user. 798 Clarified how clients select the authentication function. 800 Added IANA registration for the new mechanism. 802 Added missing normative references (UTF-8, SASLPrep). 804 Various editorial changes based on comments from Hallvard B 805 Furuseth, Nico William and Simon Josefsson. 807 Changes since -04 809 - Update Base64 and Security Glossary references. 811 - Add Formal Syntax section. 813 - Don't bother with "v=". 815 - Make MD5 mandatory to implement. Suggest i=128. 817 Changes since -03 819 - Seven years have passed, in which it became clear that DIGEST-MD5 820 suffered from unacceptably bad interoperability, so SCRAM-MD5 is 821 now back from the dead. 823 - Be hash agnostic, so MD5 can be replaced more easily. 825 - General simplification.