idnits 2.17.1 draft-newman-auth-scram-10.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (February 21, 2009) is 5536 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 584, but not defined == Unused Reference: 'RFC2195' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC2202' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC4086' is defined on line 659, 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) -- No information found for - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 5 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: August 2009 Sun Microsystems 6 Alexey Melnikov 7 Isode Ltd 8 February 21, 2009 10 Salted Challenge Response (SCRAM) SASL Mechanism 12 draft-newman-auth-scram-10.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 February 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 February 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 February 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 February 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 i. (Note that a server 231 implementation may chose to use the same iteration count for all 232 account.) The server sends the salt and the 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 client-final-message-without-proof 242 ClientSignature := HMAC(StoredKey, AuthMessage) 243 ClientProof := ClientKey XOR ClientSignature 244 ServerKey := HMAC(SaltedPassword, salt) 246 Internet-draft February 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 ServerKey. 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 With channel-binding data sent by the client this might look like this: 295 Internet-draft February 2009 297 C: n=Chris Newman,r=ClientNonce 298 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 299 C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 300 S: v=WxPv/siO5l+qxN4 302 <> 304 First, the client sends a message containing the username, and a 305 random, unique nonce. In response, the server sends the user's 306 iteration count i, the user's salt, and appends its own nonce to the 307 client-specified one. The client then responds with the same nonce 308 and a ClientProof computed using the selected hash function as 309 explained earlier. In this step the client can also include an 310 optional authorization identity. The server verifies the nonce and 311 the proof, verifies that the authorization identity (if supplied by 312 the client in the second message) is authorized to act as the 313 authentication identity, and, finally, it responds with a 314 ServerSignature, concluding the authentication exchange. The client 315 then authenticates the server by computing the ServerSignature and 316 comparing it to the value sent by the server. If the two are 317 different, the client MUST consider the authentication exchange to 318 be unsuccessful and it might have to drop the connection. 320 5.1 SCRAM attributes 322 This section describes the permissible attributes, their use, and 323 the format of their values. All attribute names are single US-ASCII 324 letters and are case-sensitive. 326 - a: This optional attribute specifies an authorization identity. A 327 client may include it in its second message to the server if it 328 wants to authenticate as one user, but subsequently act as a 329 different user. This is typically used by an administrator to 330 perform some management task on behalf of another user, or by a 331 proxy in some situations. 333 Upon the receipt of this value the server verifies its correctness 334 according to the used SASL protocol profile. Failed verification 335 results in failed authentication exchange. 337 If this attribute is omitted (as it normally would be), or 338 specified with an empty value, the authorization identity is 339 assumed to be derived from the username specified with the 340 (required) "n" attribute. 342 The server always authenticates the user specified by the "n" 343 attribute. If the "a" attribute specifies a different user, the 345 Internet-draft February 2009 347 server associates that identity with the connection after 348 successful authentication and authorization checks. 350 The syntax of this field is the same as that of the "n" field with 351 respect to quoting of '=' and ','. 353 - n: This attribute specifies the name of the user whose password is 354 used for authentication. A client must include it in its first 355 message to the server. If the "a" attribute is not specified 356 (which would normally be the case), this username is also the 357 identity which will be associated with the connection subsequent 358 to authentication and authorization. 360 Before sending the username to the server, the client MUST prepare 361 the username using the "SASLPrep" profile [SASLPrep] of the 362 "stringprep" algorithm [RFC3454]. If the preparation of the 363 username fails or results in an empty string, the client SHOULD 364 abort the authentication exchange (*). 366 (*) An interactive client can request a repeated entry of the 367 username value. 369 Upon receipt of the username by the server, the server SHOULD 370 prepare it using the "SASLPrep" profile [SASLPrep] of the 371 "stringprep" algorithm [RFC3454]. If the preparation of the 372 username fails or results in an empty string, the server SHOULD 373 abort the authentication exchange. 375 The characters ',' or '=' in usernames are sent as '=2C' and '=3D' 376 respectively. If the server receives a username which contains '=' 377 not followed by either '2C' or '3D', then the server MUST fail the 378 authentication. 380 - m: This attribute is reserved for future extensibility. In this 381 version of SCRAM, its presence in a client or a server message 382 MUST cause authentication failure when the attribute is parsed by 383 the other end. 385 - r: This attribute specifies a sequence of random printable 386 characters excluding ',' which forms the nonce used as input to 387 the hash function. No quoting is applied to this string (<>). 389 As described earlier, the client supplies an initial value in its 390 first message, and the server augments that value with its own 391 nonce in its first response. It is important that this be value 392 different for each authentication. The client MUST verify that the 393 initial part of the nonce used in subsequent messages is the same 394 as the nonce it initially specified. The server MUST verify that 396 Internet-draft February 2009 398 the nonce sent by the client in the second message is the same as 399 the one sent by the server in its first message. 401 - c: This optional attribute specifies base64-encoded channel- 402 binding data. It is sent by the client in the second step. If 403 specified by the client, if the server supports the specified 404 channel binding type and if the server can't verify it, then the 405 server MUST fail the authentication exchange. Whether this 406 attribute is included, and the meaning and contents of the 407 channel-binding data depends on the external security layer in 408 use. This is necessary to detect a man-in-the-middle attack on the 409 security layer. 411 - s: This attribute specifies the base64-encoded salt used by the 412 server for this user. It is sent by the server in its first 413 message to the client. 415 - i: This attribute specifies an iteration count for the selected 416 hash function and user, and must be sent by the server along with 417 the user's salt. 419 For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash 420 iteration-count of at least 128. 422 - p: This attribute specifies a base64-encoded ClientProof. The 423 client computes this value as described in the overview and sends 424 it to the server. 426 - v: This attribute specifies a base64-encoded ServerSignature. It 427 is sent by the server in its final message, and may be used by the 428 client to verify that the server has access to the user's 429 authentication information. This value is computed as explained in 430 the overview. 432 6. Formal Syntax 434 The following syntax specification uses the Augmented Backus-Naur 435 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 436 and "UTF8-4" non-terminal are defined in [UTF-8]. 438 generic-message = attr-val *("," attr-val) 439 ;; Generic syntax of any server challenge 440 ;; or client response 442 attr-val = ALPHA "=" value 444 value = 1*(value-char) 446 Internet-draft February 2009 448 value-safe-char = %01-2B / %2D-3C / %3E-7F / 449 UTF8-2 / UTF-3 / UTF8-4 450 ;; UTF8-char except NUL, "=", and ",". 452 value-char = value-safe-char / "=" 454 base64-char = ALPHA / DIGIT / "/" / "+" 456 base64-4 = 4*4(base64-char) 458 base64-3 = 3*3(base64-char) "=" 460 base64-2 = 2*2(base64-char) "==" 462 base64 = *(base64-4) [base64-3 / base64-2] 464 posit-number = (%x31-39) *DIGIT 465 ;; A positive number 467 saslname = 1*(value-safe-char / "=2C" / "=3D") 468 ;; Conforms to 470 authzid = "a=" saslname 471 ;; Protocol specific. 473 username = "n=" saslname 474 ;; Usernames are prepared using SASLPrep. 476 reserved-mext = "m=" 1*(value-char) 477 ;; Reserved for signalling mandatory extensions. 478 ;; The exact syntax will be defined in 479 ;; the future. 481 channel-binding = "c=" base64 483 proof = "p=" base64 485 nonce = "r=" c-nonce [s-nonce] 486 ;; Second part provided by server. 488 c-nonce = value 490 s-nonce = value 492 salt = "s=" base64 494 verifier = "v=" base64 495 ;; base-64 encoded ServerSignature. 497 Internet-draft February 2009 499 iteration-count = "i=" posit-number 500 ;; A positive number 502 client-first-message = 503 [reserved-mext ","] username "," nonce ["," 504 extensions] 506 server-first-message = 507 [reserved-mext ","] nonce "," salt "," 508 iteration-count ["," extensions] 510 client-final-message-without-proof = 511 [authzid ","] [channel-binding ","] nonce ["," 512 extensions] 514 client-final-message = 515 client-final-message-without-proof "," proof 517 server-final-message = 518 verifier ["," extensions] 520 extensions = attr-val *("," attr-val) 521 ;; All extensions are optional, 522 ;; i.e. unrecognized attributes 523 ;; not defined in this document 524 ;; MUST be ignored. 526 7. Security Considerations 528 If the authentication exchange is performed without a strong 529 security layer, then a passive eavesdropper can gain sufficient 530 information to mount an offline dictionary or brute-force attack 531 which can be used to recover the user's password. The amount of time 532 necessary for this attack depends on the cryptographic hash function 533 selected, the strength of the password and the iteration count 534 supplied by the server. An external security layer with strong 535 encryption will prevent this attack. 537 If the external security layer used to protect the SCRAM exchange 538 uses an anonymous key exchange, then the SCRAM channel binding 539 mechanism can be used to detect a man-in-the-middle attack on the 540 security layer and cause the authentication to fail as a result. 541 However, the man-in-the-middle attacker will have gained sufficient 542 information to mount an offline dictionary or brute-force attack. 543 For this reason, SCRAM includes the ability to increase the 544 iteration count over time. 546 Internet-draft February 2009 548 If the authentication information is stolen from the authentication 549 database, then an offline dictionary or brute-force attack can be 550 used to recover the user's password. The use of salt mitigates this 551 attack somewhat by requiring a separate attack on each password. 552 Authentication mechanisms which protect against this attack are 553 available (e.g., the EKE class of mechanisms), but the patent 554 situation is presently unclear. 556 If an attacker obtains the authentication information from the 557 authentication repository and either eavesdrops on one 558 authentication exchange or impersonates a server, the attacker gains 559 the ability to impersonate that user to all servers providing SCRAM 560 access using the same hash function, password, iteration count and 561 salt. For this reason, it is important to use randomly-generated 562 salt values. 564 If the server detects (from the value of the client-specified "h" 565 attribute) that both endpoints support a stronger hash function that 566 the one the client actually chooses to use, then it SHOULD treat 567 this as a downgrade attack and reject the authentication attempt. 569 A hostile server can perform a computational denial-of-service 570 attack on clients by sending a big iteration count value. 572 Internet-draft February 2009 574 8. IANA considerations 576 IANA is requested to add the following entry to the SASL Mechanism 577 registry established by [RFC4422]: 579 To: iana@iana.org 580 Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1 582 SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1 583 Security considerations: Section 7 of [RFCXXXX] 584 Published specification (optional, recommended): [RFCXXXX] 585 Person & email address to contact for further information: 586 IETF SASL WG 587 Intended usage: COMMON 588 Owner/Change controller: IESG 589 Note: 591 Note that even though this document defines a family of SCRAM-HMAC 592 mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in 593 the SASL Mechanisms registry. IANA is requested to prevent future 594 registrations of SASL mechanisms starting with SCRAM-HMAC- without 595 consulting the SASL mailing list first. 597 Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC 598 SASL mechanism MUST be explicitly registered with IANA and MUST 599 comply with SCRAM-HMAC mechanism naming convention defined in 600 Section 4 of this document. 602 9. Acknowedgements 604 The authors would like to thank Dave Cridland for his contributions 605 to this document. 607 10. Normative References 609 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 610 Encodings", RFC 4648, SJD, October 2006. 612 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 613 10646", STD 63, RFC 3629, November 2003. 615 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 616 Message Authentication", IBM, February 1997. 618 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 620 Internet-draft February 2009 622 Requirement Levels", RFC 2119, Harvard University, March 623 1997. 625 [RFC3174] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 626 3174, Motorola, September 2001 628 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax 629 Specifications: ABNF", RFC 5234, January 2008. 631 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 632 Layer (SASL)", RFC 4422, Isode Limited, June 2006. 634 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user 635 names and passwords", RFC 4013, February 2005. 637 [RFC3454] Hoffman, P., Blanchet, M., "Preparation of 638 Internationalized Strings ("stringprep")", RFC 3454, 639 December 2002. 641 11. Informative References 643 [RFC2195] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 644 for Simple Challenge/Response", RFC 2195, MCI, September 645 1997. 647 [RFC2202] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 648 RFC 2202, IBM, September 1997 650 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 651 Specification Version 2.0", RFC 2898, September 2000. 653 [TLS] Dierks, Rescorla, "The Transport Layer Security (TLS) 654 Protocol, Version 1.2", RFC 5246, August 2008. 656 [RFC4949] Shirey, "Internet Security Glossary, Version 2", RFC 657 4949, FYI 0036, August 2007. 659 [RFC4086] Eastlake, Schiller, Crocker, "Randomness Requirements for 660 Security", RFC 4086, BCP 0106, Motorola Laboratories, 661 June 2005. 663 [RFC4510] Zeilenga, "Lightweight Directory Access Protocol (LDAP): 664 Technical Specification Road Map", RFC 4510, June 2006. 666 [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication 667 as a SASL Mechanism", RFC 2831, May 2000. <> 673 [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in 674 progress, draft-ietf-sasl-digest-to-historic-00.txt, July 675 2008 677 [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress, 678 draft-ietf-sasl-crammd5-to-historic-00.txt, November 679 2008. 681 [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security 682 Layer (SASL) Mechanism" RFC 4616, August 2006. 684 12. Authors' Addresses 686 Abhijit Menon-Sen 687 Oryx Mail Systems GmbH 689 Email: ams@oryx.com 691 Alexey Melnikov 692 Isode Ltd 694 EMail: Alexey.Melnikov@isode.com 696 Chris Newman 697 Sun Microsystems 698 1050 Lakes Drive 699 West Covina, CA 91790 700 USA 702 Email: chris.newman@sun.com 704 Appendix A: Other Authentication Mechanisms 706 The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex 707 to implement and test, and thus has poor interoperability. The 708 security layer is often not implemented, and almost never used; 709 everyone uses TLS instead. For a more complete list of problems 710 with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST- 711 HISTORIC]. 713 The CRAM-MD5 SASL mechanism, while widely deployed has also some 714 problems, in particular it is missing some modern SASL features such 716 Internet-draft February 2009 718 as support for internationalized usernames and passwords, support 719 for passing of authorization identity, support for channel bindings. 720 It also doesn't support server authentication. For a more complete 721 list of problems with CRAM-MD5 see [CRAM-HISTORIC]. 723 The PLAIN [PLAIN] SASL mechanism allows a malicious server or 724 eavesdropper to impersonate the authenticating user to any other 725 server for which the user has the same password. It also sends the 726 password in the clear over the network, unless TLS is used. Server 727 authentication is not supported. 729 Appendix B: Design Motivations 731 The following design goals shaped this document. Note that some of 732 the goals have changed since the initial version of the document. 734 The SASL mechanism has all modern SASL features: support for 735 internationalized usernames and passwords, support for passing of 736 authorization identity, support for channel bindings. 738 Both the client and server can be authenticated by the protocol. 740 The authentication information stored in the authentication 741 database is not sufficient by itself to impersonate the client. 743 <> 747 The mechanism is extensible, but [hopefully] not overengineered in 748 this respect. 750 Easier to implement than DIGEST-MD5 in both clients and servers. 752 Appendix C: SCRAM Examples 754 <> 756 Internet-draft February 2009 758 (RFC Editor: Please delete everything after this point) 760 Open Issues 762 - The appendices need to be written. 764 - Should the server send a base64-encoded ServerSignature for the 765 value of the "v" attribute, or should it compute a ServerProof the 766 way the client computes a ClientProof? 768 Changes since -07 770 Updated References. 772 Clarified purpose of the m= attribute. 774 Fixed a problem with authentication/authorization identity's ABNF 775 not allowing for some characters. 777 Updated ABNF for nonce to show client-generated and server-generated 778 parts. 780 Only register SCRAM-HMAC-SHA-1 with IANA and require explicit 781 registrations of all other SCRAM-HMAC- mechanisms. 783 Changes since -06 785 Removed hash negotiation from SCRAM and turned it into a family of 786 SASL mechanisms. 788 Start using "Hash Function Textual Names" IANA registry for SCRAM 789 mechanism naming. 791 Fixed definition of Hi(str, salt) to be consistent with [RFC2898]. 793 Clarified extensibility of SCRAM: added m= attribute (for future 794 mandatory extensions) and specified that all unrecognized 795 attributes must be ignored. 797 Changes since -05 799 Changed the mandatory to implement hash algorithm to SHA-1 (as per 801 Internet-draft February 2009 803 WG consensus). 805 Added text about use of SASLPrep for username 806 canonicalization/validation. 808 Clarified that authorization identity is canonicalized/verified 809 according to SASL protocol profile. 811 Clarified that iteration count is per-user. 813 Clarified how clients select the authentication function. 815 Added IANA registration for the new mechanism. 817 Added missing normative references (UTF-8, SASLPrep). 819 Various editorial changes based on comments from Hallvard B 820 Furuseth, Nico William and Simon Josefsson. 822 Changes since -04 824 - Update Base64 and Security Glossary references. 826 - Add Formal Syntax section. 828 - Don't bother with "v=". 830 - Make MD5 mandatory to implement. Suggest i=128. 832 Changes since -03 834 - Seven years have passed, in which it became clear that DIGEST-MD5 835 suffered from unacceptably bad interoperability, so SCRAM-MD5 is 836 now back from the dead. 838 - Be hash agnostic, so MD5 can be replaced more easily. 840 - General simplification.