1 2 3 4 5 6 7Network Working Group Abhijit Menon-Sen 8Internet-Draft Oryx Mail Systems GmbH 9Intended Status: Proposed Standard Chris Newman 10Expires: August 2009 Sun Microsystems 11 Alexey Melnikov 12 Isode Ltd 13 February 15, 2009 14 15 16 Salted Challenge Response (SCRAM) SASL Mechanism 17 18 draft-newman-auth-scram-09.txt 19 20 21Status of this Memo 22 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 25 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 30 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 35 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 38 Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 40 41 This Internet-Draft expires in July 2009. 42 43 44Copyright Notice 45 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 48 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. 55 56 57 58Menon-Sen & Co Expires August 2009 FF[Page 1] 59 60 61 62 63 64Internet-draft February 2009 65 66 67Abstract 68 69 The secure authentication mechanism most widely deployed and used by 70 Internet application protocols is the transmission of clear-text 71 passwords over a channel protected by Transport Layer Security 72 (TLS). There are some significant security concerns with that 73 mechanism, which could be addressed by the use of a challenge 74 response authentication mechanism protected by TLS. Unfortunately, 75 the challenge response mechanisms presently on the standards track 76 all fail to meet requirements necessary for widespread deployment, 77 and have had success only in limited use. 78 79 This specification describes a family of authentication mechanisms 80 called the Salted Challenge Response Authentication Mechanism 81 (SCRAM), which addresses the security concerns and meets the 82 deployability requirements. When used in combination with TLS or an 83 equivalent security layer, a mechanism from this family could 84 improve the status-quo for application protocol authentication and 85 provide a suitable choice for a mandatory-to-implement mechanism for 86 future application protocol standards. 87 88 891. Conventions Used in This Document 90 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 94 95 Formal syntax is defined by [RFC5234] including the core rules 96 defined in Appendix B of [RFC5234]. 97 98 Example lines prefaced by "C:" are sent by the client and ones 99 prefaced by "S:" by the server. If a single "C:" or "S:" label 100 applies to multiple lines, then the line breaks between those lines 101 are for editorial clarity only, and are not part of the actual 102 protocol exchange. 103 104 1051.1. Terminology 106 107 This document uses several terms defined in [RFC4949] ("Internet 108 Security Glossary") including the following: authentication, 109 authentication exchange, authentication information, brute force, 110 challenge-response, cryptographic hash function, dictionary attack, 111 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 112 one-way encryption function, password, replay attack and salt. 113 Readers not familiar with these terms should use that glossary as a 114 reference. 115 116 117 118Menon-Sen & Co Expires August 2009 FF[Page 2] 119 120 121 122 123 124Internet-draft February 2009 125 126 127 Some clarifications and additional definitions follow: 128 129 - Authentication information: Information used to verify an identity 130 claimed by a SCRAM client. The authentication information for a 131 SCRAM identity consists of salt, iteration count, the "StoredKey" 132 and "ServerKey" (as defined in the algorithm overview) for each 133 supported cryptographic hash function. 134 135 - Authentication database: The database used to look up the 136 authentication information associated with a particular identity. 137 For application protocols, LDAPv3 (see [RFC4510]) is frequently 138 used as the authentication database. For network-level protocols 139 such as PPP or 802.11x, the use of RADIUS is more common. 140 141 - Base64: An encoding mechanism defined in [RFC4648] which converts 142 an octet string input to a textual output string which can be 143 easily displayed to a human. The use of base64 in SCRAM is 144 restricted to the canonical form with no whitespace. 145 146 - Octet: An 8-bit byte. 147 148 - Octet string: A sequence of 8-bit bytes. 149 150 - Salt: A random octet string that is combined with a password 151 before applying a one-way encryption function. This value is used 152 to protect passwords that are stored in an authentication 153 database. 154 155 1561.2. Notation 157 158 The pseudocode description of the algorithm uses the following 159 notations: 160 161 - ":=": The variable on the left hand side represents the octet 162 string resulting from the expression on the right hand side. 163 164 - "+": Octet string concatenation. 165 166 - "[ ]": A portion of an expression enclosed in "[" and "]" may not 167 be included in the result under some circumstances. See the 168 associated text for a description of those circumstances. 169 170 - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 171 [RFC2104]) using the octet string represented by "key" as the key 172 and the octet string "str" as the input string. The size of the 173 result is the hash result size for the hash function in use. For 174 example, it is 20 octets for SHA-1 (see [RFC3174]). 175 176 177 178Menon-Sen & Co Expires August 2009 FF[Page 3] 179 180 181 182 183 184Internet-draft February 2009 185 186 187 - H(str): Apply the cryptographic hash function to the octet string 188 "str", producing an octet string as a result. The size of the 189 result depends on the hash result size for the hash function in 190 use. 191 192 - XOR: Apply the exclusive-or operation to combine the octet string 193 on the left of this operator with the octet string on the right of 194 this operator. The length of the output and each of the two inputs 195 will be the same for this use. 196 197 - Hi(str, salt): 198 199 U0 := HMAC(str, salt || INT(1)) 200 U1 := HMAC(str, U0) 201 U2 := HMAC(str, U1) 202 ... 203 Ui-1 := HMAC(str, Ui-2) 204 Ui := HMAC(str, Ui-1) 205 206 Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui 207 where "i" is the iteration count, "||" is the string concatenation 208 operator and INT(g) is a four-octet encoding of the integer g, 209 most significant octet first. 210 211 This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 212 with dkLen == output length of HMAC() == output length of H(). 213 214 215 2162. Introduction 217 218 This specification describes a family of authentication mechanisms 219 called the Salted Challenge Response Authentication Mechanism 220 (SCRAM) which addresses the requirements necessary to deploy a 221 challenge-response mechanism more widely than past attempts. When 222 used in combination with Transport Layer Security (TLS, see [TLS]) 223 or an equivalent security layer, a mechanism from this family could 224 improve the status-quo for application protocol authentication and 225 provide a suitable choice for a mandatory-to-implement mechanism for 226 future application protocol standards. 227 228 For simplicity, this family of mechanism does not presently include 229 negotiation of a security layer. It is intended to be used with an 230 external security layer such as that provided by TLS or SSH. 231 232 SCRAM provides the following protocol features: 233 234 - The authentication information stored in the authentication 235 236 237 238Menon-Sen & Co Expires August 2009 FF[Page 4] 239 240 241 242 243 244Internet-draft February 2009 245 246 247 database is not sufficient by itself to impersonate the client. 248 The information is salted to prevent a pre-stored dictionary 249 attack if the database is stolen. 250 251 - The server does not gain the ability to impersonate the client to 252 other servers (with an exception for server-authorized proxies). 253 254 - The mechanism permits the use of a server-authorized proxy without 255 requiring that proxy to have super-user rights with the back-end 256 server. 257 258 - A standard attribute is defined to enable storage of the 259 authentication information in LDAPv3 (see [RFC4510]). 260 261 - Both the client and server can be authenticated by the protocol. 262 263 For an in-depth discussion of why other challenge response 264 mechanisms are not considered sufficient, see appendix A. For more 265 information about the motivations behind the design of this 266 mechanism, see appendix B. 267 268 Comments regarding this draft may be sent either to the ietf- 269 sasl@imc.org mailing list or to the authors. 270 271 2723. SCRAM Algorithm Overview 273 274 Note that this section omits some details, such as client and server 275 nonces. See Section 5 for more details. 276 277 To begin with, the client is in possession of a username and 278 password. It sends the username to the server, which retrieves the 279 corresponding authentication information, i.e. a salt, StoredKey, 280 ServerKey and the iteration count i. (Note that a server 281 implementation may chose to use the same iteration count for all 282 account.) The server sends the salt and the iteration count to the 283 client, which then computes the following values and sends a 284 ClientProof to the server: 285 286 SaltedPassword := Hi(password, salt) 287 ClientKey := H(SaltedPassword) 288 StoredKey := H(ClientKey) 289 AuthMessage := client-first-message + "," + 290 server-first-message + "," + 291 final-client-message-without-proof 292 ClientSignature := HMAC(StoredKey, AuthMessage) 293 ClientProof := ClientKey XOR ClientSignature 294 ServerKey := HMAC(SaltedPassword, salt) 295 296 297 298Menon-Sen & Co Expires August 2009 FF[Page 5] 299 300 301 302 303 304Internet-draft February 2009 305 306 307 ServerSignature := HMAC(ServerKey, AuthMessage) 308 309 The server authenticates the client by computing the 310 ClientSignature, exclusive-ORing that with the ClientProof to 311 recover the ClientKey and verifying the correctness of the ClientKey 312 by applying the hash function and comparing the result to the 313 StoredKey. If the ClientKey is correct, this proves that the client 314 has access to the user's password. 315 316 Similarly, the client authenticates the server by computing the 317 ServerSignature and comparing it to the value sent by the server. 318 If the two are equal, it proves that the server had access to the 319 user's ServerKey. 320 321 The AuthMessage is computed by concatenating messages from the 322 authentication exchange. The format of these messages is defined in 323 the Formal Syntax section. 324 325 3264. SCRAM mechanism names 327 328 A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the 329 uppercased name of the underlying hashed function taken from the 330 IANA "Hash Function Textual Names" registry (see 331 http://www.iana.org). 332 333 For interoperability, all SCRAM clients and servers MUST implement 334 the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an 335 authentication mechanism from the SCRAM family that uses the SHA-1 336 hash function as defined in [RFC3174]. 337 338 3395. SCRAM Authentication Exchange 340 341 SCRAM is a text protocol where the client and server exchange 342 messages containing one or more attribute-value pairs separated by 343 commas. Each attribute has a one-letter name. The messages and their 344 attributes are described in section 5.1, and defined in the Formal 345 Syntax section. 346 347 This is a simple example of a SCRAM-HMAC-SHA-1 authentication 348 exchange: 349 C: n=Chris Newman,r=ClientNonce 350 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 351 C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 352 S: v=WxPv/siO5l+qxN4 353 354 With channel-binding data sent by the client this might look like this: 355 356 357 358Menon-Sen & Co Expires August 2009 FF[Page 6] 359 360 361 362 363 364Internet-draft February 2009 365 366 367 C: n=Chris Newman,r=ClientNonce 368 S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128 369 C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4 370 S: v=WxPv/siO5l+qxN4 371 372 <<Note that the channel-bind data above, as well as all hashes are fake>> 373 374 First, the client sends a message containing the username, and a 375 random, unique nonce. In response, the server sends the user's 376 iteration count i, the user's salt, and appends its own nonce to the 377 client-specified one. The client then responds with the same nonce 378 and a ClientProof computed using the selected hash function as 379 explained earlier. In this step the client can also include an 380 optional authorization identity. The server verifies the nonce and 381 the proof, verifies that the authorization identity (if supplied by 382 the client in the second message) is authorized to act as the 383 authentication identity, and, finally, it responds with a 384 ServerSignature, concluding the authentication exchange. The client 385 then authenticates the server by computing the ServerSignature and 386 comparing it to the value sent by the server. If the two are 387 different, the client MUST consider the authentication exchange to 388 be unsuccessful and it might have to drop the connection. 389 390 3915.1 SCRAM attributes 392 393 This section describes the permissible attributes, their use, and 394 the format of their values. All attribute names are single US-ASCII 395 letters and are case-sensitive. 396 397 - a: This optional attribute specifies an authorization identity. A 398 client may include it in its second message to the server if it 399 wants to authenticate as one user, but subsequently act as a 400 different user. This is typically used by an administrator to 401 perform some management task on behalf of another user, or by a 402 proxy in some situations. 403 404 Upon the receipt of this value the server verifies its correctness 405 according to the used SASL protocol profile. Failed verification 406 results in failed authentication exchange. 407 408 If this attribute is omitted (as it normally would be), or 409 specified with an empty value, the authorization identity is 410 assumed to be derived from the username specified with the 411 (required) "n" attribute. 412 413 The server always authenticates the user specified by the "n" 414 attribute. If the "a" attribute specifies a different user, the 415 416 417 418Menon-Sen & Co Expires August 2009 FF[Page 7] 419 420 421 422 423 424Internet-draft February 2009 425 426 427 server associates that identity with the connection after 428 successful authentication and authorization checks. 429 430 The syntax of this field is the same as that of the "n" field with 431 respect to quoting of '=' and ','. 432 433 - n: This attribute specifies the name of the user whose password is 434 used for authentication. A client must include it in its first 435 message to the server. If the "a" attribute is not specified 436 (which would normally be the case), this username is also the 437 identity which will be associated with the connection subsequent 438 to authentication and authorization. 439 440 Before sending the username to the server, the client MUST prepare 441 the username using the "SASLPrep" profile [SASLPrep] of the 442 "stringprep" algorithm [RFC3454]. If the preparation of the 443 username fails or results in an empty string, the client SHOULD 444 abort the authentication exchange (*). 445 446 (*) An interactive client can request a repeated entry of the 447 username value. 448 449 Upon receipt of the username by the server, the server SHOULD 450 prepare it using the "SASLPrep" profile [SASLPrep] of the 451 "stringprep" algorithm [RFC3454]. If the preparation of the 452 username fails or results in an empty string, the server SHOULD 453 abort the authentication exchange. 454 455 The characters ',' or '=' in usernames are sent as '=2C' and '=3D' 456 respectively. If the server receives a username which contains '=' 457 not followed by either '2C' or '3D', then the server MUST fail the 458 authentication. 459 460 - m: This attribute is reserved for future extensibility. In this 461 version of SCRAM, its presence in a client or a server message 462 MUST cause authentication failure when the attribute is parsed by 463 the other end. 464 465 - r: This attribute specifies a sequence of random printable 466 characters excluding ',' which forms the nonce used as input to 467 the hash function. No quoting is applied to this string (unless 468 the binding of SCRAM to a particular protocol states otherwise). 469 As described earlier, the client supplies an initial value in its 470 first message, and the server augments that value with its own 471 nonce in its first response. It is important that this be value 472 different for each authentication. The client MUST verify that the 473 initial part of the nonce used in subsequent messages is the same 474 as the nonce it initially specified. The server MUST verify that 475 476 477 478Menon-Sen & Co Expires August 2009 FF[Page 8] 479 480 481 482 483 484Internet-draft February 2009 485 486 487 the nonce sent by the client in the second message is the same as 488 the one sent by the server in its first message. 489 490 - c: This optional attribute specifies base64-encoded channel- 491 binding data. It is sent by the client in the second step. If 492 specified by the client, if the server supports the specified 493 channel binding type and if the server can't verify it, then the 494 server MUST fail the authentication exchange. Whether this 495 attribute is included, and the meaning and contents of the 496 channel-binding data depends on the external security layer in 497 use. This is necessary to detect a man-in-the-middle attack on the 498 security layer. 499 500 - s: This attribute specifies the base64-encoded salt used by the 501 server for this user. It is sent by the server in its first 502 message to the client. 503 504 - i: This attribute specifies an iteration count for the selected 505 hash function and user, and must be sent by the server along with 506 the user's salt. 507 508 For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash 509 iteration-count of at least 128. 510 511 - p: This attribute specifies a base64-encoded ClientProof. The 512 client computes this value as described in the overview and sends 513 it to the server. 514 515 - v: This attribute specifies a base64-encoded ServerSignature. It 516 is sent by the server in its final message, and may be used by the 517 client to verify that the server has access to the user's 518 authentication information. This value is computed as explained in 519 the overview. 520 521 5226. Formal Syntax 523 524 The following syntax specification uses the Augmented Backus-Naur 525 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 526 and "UTF8-4" non-terminal are defined in [UTF-8]. 527 528 generic-message = attr-val *("," attr-val) 529 ;; Generic syntax of any server challenge 530 ;; or client response 531 532 attr-val = ALPHA "=" value 533 534 value = *(value-char) 535 536 537 538Menon-Sen & Co Expires August 2009 FF[Page 9] 539 540 541 542 543 544Internet-draft February 2009 545 546 547 value-safe-char = %01-2B / %2D-3C / %3E-7F / 548 UTF8-2 / UTF-3 / UTF8-4 549 ;; UTF8-char except NUL, "=", and ",". 550 551 value-char = value-safe-char / "=" 552 553 base64-char = ALPHA / DIGIT / "/" / "+" 554 555 base64-4 = 4*4(base64-char) 556 557 base64-3 = 3*3(base64-char) "=" 558 559 base64-2 = 2*2(base64-char) "==" 560 561 base64 = *(base64-4) [base64-3 / base64-2] 562 563 posit-number = (%x31-39) *DIGIT 564 ;; A positive number 565 566 saslname = 1*(value-safe-char / "=2C" / "=3D") 567 ;; Conforms to <value> 568 569 authzid = "a=" saslname 570 ;; Protocol specific. 571 572 username = "n=" saslname 573 ;; Usernames are prepared using SASLPrep. 574 575 reserved-mext = "m=" 1*(value-char) 576 ;; Reserved for signalling mandatory extensions. 577 ;; The exact syntax will be defined in 578 ;; the future. 579 580 channel-binding = "c=" base64 581 582 proof = "p=" base64 583 584 nonce = "r=" c-nonce [s-nonce] 585 ;; Second part provided by server. 586 587 c-nonce = value 588 589 s-nonce = value 590 591 salt = "s=" base64 592 593 verifier = "v=" base64 594 ;; base-64 encoded ServerSignature. 595 596 597 598Menon-Sen & Co Expires August 2009 FF[Page 10] 599 600 601 602 603 604Internet-draft February 2009 605 606 607 iteration-count = "i=" posit-number 608 ;; A positive number 609 610 client-first-message = 611 [reserved-mext ","] username "," nonce ["," 612 extensions] 613 614 server-first-message = 615 [reserved-mext ","] nonce "," salt "," 616 iteration-count ["," extensions] 617 618 client-final-message-without-proof = 619 [authzid ","] [channel-binding ","] nonce ["," 620 extensions] 621 622 client-final-message = 623 client-final-message-without-proof "," proof 624 625 server-final-message = 626 verifier ["," extensions] 627 628 extensions = attr-val *("," attr-val) 629 ;; All extensions are optional, 630 ;; i.e. unrecognized attributes 631 ;; not defined in this document 632 ;; MUST be ignored. 633 634 6357. Security Considerations 636 637 If the authentication exchange is performed without a strong 638 security layer, then a passive eavesdropper can gain sufficient 639 information to mount an offline dictionary or brute-force attack 640 which can be used to recover the user's password. The amount of time 641 necessary for this attack depends on the cryptographic hash function 642 selected, the strength of the password and the iteration count 643 supplied by the server. An external security layer with strong 644 encryption will prevent this attack. 645 646 If the external security layer used to protect the SCRAM exchange 647 uses an anonymous key exchange, then the SCRAM channel binding 648 mechanism can be used to detect a man-in-the-middle attack on the 649 security layer and cause the authentication to fail as a result. 650 However, the man-in-the-middle attacker will have gained sufficient 651 information to mount an offline dictionary or brute-force attack. 652 For this reason, SCRAM includes the ability to increase the 653 iteration count over time. 654 655 656 657 658Menon-Sen & Co Expires August 2009 FF[Page 11] 659 660 661 662 663 664Internet-draft February 2009 665 666 667 If the authentication information is stolen from the authentication 668 database, then an offline dictionary or brute-force attack can be 669 used to recover the user's password. The use of salt mitigates this 670 attack somewhat by requiring a separate attack on each password. 671 Authentication mechanisms which protect against this attack are 672 available (e.g., the EKE class of mechanisms), but the patent 673 situation is presently unclear. 674 675 If an attacker obtains the authentication information from the 676 authentication repository and either eavesdrops on one 677 authentication exchange or impersonates a server, the attacker gains 678 the ability to impersonate that user to all servers providing SCRAM 679 access using the same hash function, password, iteration count and 680 salt. For this reason, it is important to use randomly-generated 681 salt values. 682 683 If the server detects (from the value of the client-specified "h" 684 attribute) that both endpoints support a stronger hash function that 685 the one the client actually chooses to use, then it SHOULD treat 686 this as a downgrade attack and reject the authentication attempt. 687 688 A hostile server can perform a computational denial-of-service 689 attack on clients by sending a big iteration count value. 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718Menon-Sen & Co Expires August 2009 FF[Page 12] 719 720 721 722 723 724Internet-draft February 2009 725 726 7278. IANA considerations 728 729 IANA is requested to add the following entry to the SASL Mechanism 730 registry established by [RFC4422]: 731 732 To: iana@iana.org 733 Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1 734 735 SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1 736 Security considerations: Section 7 of [RFCXXXX] 737 Published specification (optional, recommended): [RFCXXXX] 738 Person & email address to contact for further information: 739 IETF SASL WG <ietf-sasl@imc.org> 740 Intended usage: COMMON 741 Owner/Change controller: IESG <iesg@ietf.org> 742 Note: 743 744 Note that even though this document defines a family of SCRAM-HMAC 745 mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in 746 the SASL Mechanisms registry. IANA is requested to prevent future 747 registrations of SASL mechanisms starting with SCRAM-HMAC- without 748 consulting the SASL mailing list <ietf-sasl@imc.org> first. 749 750 Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC 751 SASL mechanism MUST be explicitly registered with IANA and MUST 752 comply with SCRAM-HMAC mechanism naming convention defined in 753 Section 4 of this document. 754 755 756 7579. Acknowedgements 758 759 The authors would like to thank Dave Cridland for his contributions 760 to this document. 761 762 76310. Normative References 764 765 [RFC4648] Josefsson, "The Base16, Base32, and Base64 Data 766 Encodings", RFC 4648, SJD, October 2006. 767 768 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 769 10646", STD 63, RFC 3629, November 2003. 770 771 [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 772 Message Authentication", IBM, February 1997. 773 774 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 775 776 777 778Menon-Sen & Co Expires August 2009 FF[Page 13] 779 780 781 782 783 784Internet-draft February 2009 785 786 787 Requirement Levels", RFC 2119, Harvard University, March 788 1997. 789 790 [RFC3174] Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 791 3174, Motorola, September 2001 792 793 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax 794 Specifications: ABNF", RFC 5234, January 2008. 795 796 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 797 Layer (SASL)", RFC 4422, Isode Limited, June 2006. 798 799 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user 800 names and passwords", RFC 4013, February 2005. 801 802 [RFC3454] Hoffman, P., Blanchet, M., "Preparation of 803 Internationalized Strings ("stringprep")", RFC 3454, 804 December 2002. 805 806 807 80811. Informative References 809 810 [RFC2195] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension 811 for Simple Challenge/Response", RFC 2195, MCI, September 812 1997. 813 814 [RFC2202] Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 815 RFC 2202, IBM, September 1997 816 817 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 818 Specification Version 2.0", RFC 2898, September 2000. 819 820 [TLS] Dierks, Rescorla, "The Transport Layer Security (TLS) 821 Protocol, Version 1.2", RFC 5246, August 2008. 822 823 [RFC4949] Shirey, "Internet Security Glossary, Version 2", RFC 824 4949, FYI 0036, August 2007. 825 826 [RFC4086] Eastlake, Schiller, Crocker, "Randomness Requirements for 827 Security", RFC 4086, BCP 0106, Motorola Laboratories, 828 June 2005. 829 830 [RFC4510] Zeilenga, "Lightweight Directory Access Protocol (LDAP): 831 Technical Specification Road Map", RFC 4510, June 2006. 832 833 [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication 834 as a SASL Mechanism", RFC 2831, May 2000. <<Also draft- 835 836 837 838Menon-Sen & Co Expires August 2009 FF[Page 14] 839 840 841 842 843 844Internet-draft February 2009 845 846 847 ietf-sasl-rfc2831bis-12.txt>> 848 849 [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in 850 progress, draft-ietf-sasl-digest-to-historic-00.txt, July 851 2008 852 853 [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress, 854 draft-ietf-sasl-crammd5-to-historic-00.txt, November 855 2008. 856 857 [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security 858 Layer (SASL) Mechanism" RFC 4616, August 2006. 859 860 86112. Authors' Addresses 862 863 Abhijit Menon-Sen 864 Oryx Mail Systems GmbH 865 866 Email: ams@oryx.com 867 868 869 Alexey Melnikov 870 Isode Ltd 871 872 EMail: Alexey.Melnikov@isode.com 873 874 875 Chris Newman 876 Sun Microsystems 877 1050 Lakes Drive 878 West Covina, CA 91790 879 USA 880 881 Email: chris.newman@sun.com 882 883 884Appendix A: Other Authentication Mechanisms 885 886 The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex 887 to implement and test, and thus has poor interoperability. The 888 security layer is often not implemented, and almost never used; 889 everyone uses TLS instead. For a more complete list of problems 890 with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST- 891 HISTORIC]. 892 893 The CRAM-MD5 SASL mechanism, while widely deployed has also some 894 problems, in particular it is missing some modern SASL features such 895 896 897 898Menon-Sen & Co Expires August 2009 FF[Page 15] 899 900 901 902 903 904Internet-draft February 2009 905 906 907 as support for internationalized usernames and passwords, support 908 for passing of authorization identity, support for channel bindings. 909 It also doesn't support server authentication. For a more complete 910 list of problems with CRAM-MD5 see [CRAM-HISTORIC]. 911 912 The PLAIN [PLAIN] SASL mechanism allows a malicious server or 913 eavesdropper to impersonate the authenticating user to any other 914 server for which the user has the same password. It also sends the 915 password in the clear over the network, unless TLS is used. Server 916 authentication is not supported. 917 918 919Appendix B: Design Motivations 920 921 The following design goals shaped this document. Note that some of 922 the goals have changed since the initial version of the document. 923 924 The SASL mechanism has all modern SASL features: support for 925 internationalized usernames and passwords, support for passing of 926 authorization identity, support for channel bindings. 927 928 Both the client and server can be authenticated by the protocol. 929 930 The authentication information stored in the authentication 931 database is not sufficient by itself to impersonate the client. 932 933 <<The server does not gain the ability to impersonate the client 934 to other servers (with an exception for server-authorized 935 proxies).>> 936 937 The mechanism is extensible, but [hopefully] not overengineered in 938 this respect. 939 940 Easier to implement than DIGEST-MD5 in both clients and servers. 941 942 943Appendix C: SCRAM Examples 944 945 <<To be written.>> 946 947 948 949 950 951 952 953 954 955 956 957 958Menon-Sen & Co Expires August 2009 FF[Page 16] 959 960 961 962 963 964Internet-draft February 2009 965 966 967 (RFC Editor: Please delete everything after this point) 968 969 970Open Issues 971 972 - The appendices need to be written. 973 974 - Should the server send a base64-encoded ServerSignature for the 975 value of the "v" attribute, or should it compute a ServerProof the 976 way the client computes a ClientProof? 977 978 979Changes since -07 980 981 Updated References. 982 983 Clarified purpose of the m= attribute. 984 985 Fixed a problem with authentication/authorization identity's ABNF 986 not allowing for some characters. 987 988 Updated ABNF for nonce to show client-generated and server-generated 989 parts. 990 991 Only register SCRAM-HMAC-SHA-1 with IANA and require explicit 992 registrations of all other SCRAM-HMAC- mechanisms. 993 994 995 996Changes since -06 997 998 Removed hash negotiation from SCRAM and turned it into a family of 999 SASL mechanisms. 1000 1001 Start using "Hash Function Textual Names" IANA registry for SCRAM 1002 mechanism naming. 1003 1004 Fixed definition of Hi(str, salt) to be consistent with [RFC2898]. 1005 1006 Clarified extensibility of SCRAM: added m= attribute (for future 1007 mandatory extensions) and specified that all unrecognized 1008 attributes must be ignored. 1009 1010 1011 1012Changes since -05 1013 1014 Changed the mandatory to implement hash algorithm to SHA-1 (as per 1015 1016 1017 1018Menon-Sen & Co Expires August 2009 FF[Page 17] 1019 1020 1021 1022 1023 1024Internet-draft February 2009 1025 1026 1027 WG consensus). 1028 1029 Added text about use of SASLPrep for username 1030 canonicalization/validation. 1031 1032 Clarified that authorization identity is canonicalized/verified 1033 according to SASL protocol profile. 1034 1035 Clarified that iteration count is per-user. 1036 1037 Clarified how clients select the authentication function. 1038 1039 Added IANA registration for the new mechanism. 1040 1041 Added missing normative references (UTF-8, SASLPrep). 1042 1043 Various editorial changes based on comments from Hallvard B 1044 Furuseth, Nico William and Simon Josefsson. 1045 1046 1047 1048Changes since -04 1049 1050 - Update Base64 and Security Glossary references. 1051 1052 - Add Formal Syntax section. 1053 1054 - Don't bother with "v=". 1055 1056 - Make MD5 mandatory to implement. Suggest i=128. 1057 1058 1059 1060Changes since -03 1061 1062 - Seven years have passed, in which it became clear that DIGEST-MD5 1063 suffered from unacceptably bad interoperability, so SCRAM-MD5 is 1064 now back from the dead. 1065 1066 - Be hash agnostic, so MD5 can be replaced more easily. 1067 1068 - General simplification. 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078Menon-Sen & Co Expires August 2009 FF[Page 18] 1079 1080 1081