1 2 3 4 5 6 7Internet Engineering Task Force (IETF) C. Newman 8Request for Comments: 5802 Oracle 9Category: Standards Track A. Menon-Sen 10ISSN: 2070-1721 Oryx Mail Systems GmbH 11 A. Melnikov 12 Isode, Ltd. 13 N. Williams 14 Oracle 15 July 2010 16 17 18 Salted Challenge Response Authentication Mechanism (SCRAM) 19 SASL and GSS-API Mechanisms 20 21Abstract 22 23 The secure authentication mechanism most widely deployed and used by 24 Internet application protocols is the transmission of clear-text 25 passwords over a channel protected by Transport Layer Security (TLS). 26 There are some significant security concerns with that mechanism, 27 which could be addressed by the use of a challenge response 28 authentication mechanism protected by TLS. Unfortunately, the 29 challenge response mechanisms presently on the standards track all 30 fail to meet requirements necessary for widespread deployment, and 31 have had success only in limited use. 32 33 This specification describes a family of Simple Authentication and 34 Security Layer (SASL; RFC 4422) authentication mechanisms called the 35 Salted Challenge Response Authentication Mechanism (SCRAM), which 36 addresses the security concerns and meets the deployability 37 requirements. When used in combination with TLS or an equivalent 38 security layer, a mechanism from this family could improve the status 39 quo for application protocol authentication and provide a suitable 40 choice for a mandatory-to-implement mechanism for future application 41 protocol standards. 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Newman, et al. Standards Track [Page 1] 59 60RFC 5802 SCRAM July 2010 61 62 63Status of This Memo 64 65 This is an Internet Standards Track document. 66 67 This document is a product of the Internet Engineering Task Force 68 (IETF). It represents the consensus of the IETF community. It has 69 received public review and has been approved for publication by the 70 Internet Engineering Steering Group (IESG). Further information on 71 Internet Standards is available in Section 2 of RFC 5741. 72 73 Information about the current status of this document, any errata, 74 and how to provide feedback on it may be obtained at 75 http://www.rfc-editor.org/info/rfc5802. 76 77Copyright Notice 78 79 Copyright (c) 2010 IETF Trust and the persons identified as the 80 document authors. All rights reserved. 81 82 This document is subject to BCP 78 and the IETF Trust's Legal 83 Provisions Relating to IETF Documents 84 (http://trustee.ietf.org/license-info) in effect on the date of 85 publication of this document. Please review these documents 86 carefully, as they describe your rights and restrictions with respect 87 to this document. Code Components extracted from this document must 88 include Simplified BSD License text as described in Section 4.e of 89 the Trust Legal Provisions and are provided without warranty as 90 described in the Simplified BSD License. 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114Newman, et al. Standards Track [Page 2] 115 116RFC 5802 SCRAM July 2010 117 118 119Table of Contents 120 121 1. Introduction ....................................................4 122 2. Conventions Used in This Document ...............................5 123 2.1. Terminology ................................................5 124 2.2. Notation ...................................................6 125 3. SCRAM Algorithm Overview ........................................7 126 4. SCRAM Mechanism Names ...........................................8 127 5. SCRAM Authentication Exchange ...................................9 128 5.1. SCRAM Attributes ..........................................10 129 5.2. Compliance with SASL Mechanism Requirements ...............13 130 6. Channel Binding ................................................14 131 6.1. Default Channel Binding ...................................15 132 7. Formal Syntax ..................................................15 133 8. SCRAM as a GSS-API Mechanism ...................................19 134 8.1. GSS-API Principal Name Types for SCRAM ....................19 135 8.2. GSS-API Per-Message Tokens for SCRAM ......................20 136 8.3. GSS_Pseudo_random() for SCRAM .............................20 137 9. Security Considerations ........................................20 138 10. IANA Considerations ...........................................22 139 11. Acknowledgements ..............................................23 140 12. References ....................................................24 141 12.1. Normative References .....................................24 142 12.2. Normative References for GSS-API Implementors ............24 143 12.3. Informative References ...................................25 144 Appendix A. Other Authentication Mechanisms .......................27 145 Appendix B. Design Motivations ....................................27 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170Newman, et al. Standards Track [Page 3] 171 172RFC 5802 SCRAM July 2010 173 174 1751. Introduction 176 177 This specification describes a family of authentication mechanisms 178 called the Salted Challenge Response Authentication Mechanism (SCRAM) 179 which addresses the requirements necessary to deploy a challenge- 180 response mechanism more widely than past attempts (see Appendix A and 181 Appendix B). When used in combination with Transport Layer Security 182 (TLS; see [RFC5246]) or an equivalent security layer, a mechanism 183 from this family could improve the status quo for application 184 protocol authentication and provide a suitable choice for a 185 mandatory-to-implement mechanism for future application protocol 186 standards. 187 188 For simplicity, this family of mechanisms does not presently include 189 negotiation of a security layer [RFC4422]. It is intended to be used 190 with an external security layer such as that provided by TLS or SSH, 191 with optional channel binding [RFC5056] to the external security 192 layer. 193 194 SCRAM is specified herein as a pure Simple Authentication and 195 Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new 196 bridge between SASL and the Generic Security Service Application 197 Program Interface (GSS-API) called "GS2" [RFC5801]. This means that 198 this document defines both, a SASL mechanism and a GSS-API mechanism. 199 200 SCRAM provides the following protocol features: 201 202 o The authentication information stored in the authentication 203 database is not sufficient by itself to impersonate the client. 204 The information is salted to prevent a pre-stored dictionary 205 attack if the database is stolen. 206 207 o The server does not gain the ability to impersonate the client to 208 other servers (with an exception for server-authorized proxies). 209 210 o The mechanism permits the use of a server-authorized proxy without 211 requiring that proxy to have super-user rights with the back-end 212 server. 213 214 o Mutual authentication is supported, but only the client is named 215 (i.e., the server has no name). 216 217 o When used as a SASL mechanism, SCRAM is capable of transporting 218 authorization identities (see [RFC4422], Section 2) from the 219 client to the server. 220 221 222 223 224 225 226Newman, et al. Standards Track [Page 4] 227 228RFC 5802 SCRAM July 2010 229 230 231 A separate document defines a standard LDAPv3 [RFC4510] attribute 232 that enables storage of the SCRAM authentication information in LDAP. 233 See [RFC5803]. 234 235 For an in-depth discussion of why other challenge response mechanisms 236 are not considered sufficient, see Appendix A. For more information 237 about the motivations behind the design of this mechanism, see 238 Appendix B. 239 2402. Conventions Used in This Document 241 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 244 document are to be interpreted as described in [RFC2119]. 245 246 Formal syntax is defined by [RFC5234] including the core rules 247 defined in Appendix B of [RFC5234]. 248 249 Example lines prefaced by "C:" are sent by the client and ones 250 prefaced by "S:" by the server. If a single "C:" or "S:" label 251 applies to multiple lines, then the line breaks between those lines 252 are for editorial clarity only, and are not part of the actual 253 protocol exchange. 254 2552.1. Terminology 256 257 This document uses several terms defined in [RFC4949] ("Internet 258 Security Glossary") including the following: authentication, 259 authentication exchange, authentication information, brute force, 260 challenge-response, cryptographic hash function, dictionary attack, 261 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 262 one-way encryption function, password, replay attack, and salt. 263 Readers not familiar with these terms should use that glossary as a 264 reference. 265 266 Some clarifications and additional definitions follow: 267 268 o Authentication information: Information used to verify an identity 269 claimed by a SCRAM client. The authentication information for a 270 SCRAM identity consists of salt, iteration count, "StoredKey" and 271 "ServerKey" (as defined in the algorithm overview) for each 272 supported cryptographic hash function. 273 274 o Authentication database: The database used to look up the 275 authentication information associated with a particular identity. 276 For application protocols, LDAPv3 (see [RFC4510]) is frequently 277 278 279 280 281 282Newman, et al. Standards Track [Page 5] 283 284RFC 5802 SCRAM July 2010 285 286 287 used as the authentication database. For network-level protocols 288 such as PPP or 802.11x, the use of RADIUS [RFC2865] is more 289 common. 290 291 o Base64: An encoding mechanism defined in [RFC4648] that converts 292 an octet string input to a textual output string that can be 293 easily displayed to a human. The use of base64 in SCRAM is 294 restricted to the canonical form with no whitespace. 295 296 o Octet: An 8-bit byte. 297 298 o Octet string: A sequence of 8-bit bytes. 299 300 o Salt: A random octet string that is combined with a password 301 before applying a one-way encryption function. This value is used 302 to protect passwords that are stored in an authentication 303 database. 304 3052.2. Notation 306 307 The pseudocode description of the algorithm uses the following 308 notations: 309 310 o ":=": The variable on the left-hand side represents the octet 311 string resulting from the expression on the right-hand side. 312 313 o "+": Octet string concatenation. 314 315 o "[ ]": A portion of an expression enclosed in "[" and "]" may not 316 be included in the result under some circumstances. See the 317 associated text for a description of those circumstances. 318 319 o Normalize(str): Apply the SASLprep profile [RFC4013] of the 320 "stringprep" algorithm [RFC3454] as the normalization algorithm to 321 a UTF-8 [RFC3629] encoded "str". The resulting string is also in 322 UTF-8. When applying SASLprep, "str" is treated as a "stored 323 strings", which means that unassigned Unicode codepoints are 324 prohibited (see Section 7 of [RFC3454]). Note that 325 implementations MUST either implement SASLprep or disallow use of 326 non US-ASCII Unicode codepoints in "str". 327 328 o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 329 [RFC2104]) using the octet string represented by "key" as the key 330 and the octet string "str" as the input string. The size of the 331 result is the hash result size for the hash function in use. For 332 example, it is 20 octets for SHA-1 (see [RFC3174]). 333 334 335 336 337 338Newman, et al. Standards Track [Page 6] 339 340RFC 5802 SCRAM July 2010 341 342 343 o H(str): Apply the cryptographic hash function to the octet string 344 "str", producing an octet string as a result. The size of the 345 result depends on the hash result size for the hash function in 346 use. 347 348 o XOR: Apply the exclusive-or operation to combine the octet string 349 on the left of this operator with the octet string on the right of 350 this operator. The length of the output and each of the two 351 inputs will be the same for this use. 352 353 o Hi(str, salt, i): 354 355 U1 := HMAC(str, salt + INT(1)) 356 U2 := HMAC(str, U1) 357 ... 358 Ui-1 := HMAC(str, Ui-2) 359 Ui := HMAC(str, Ui-1) 360 361 Hi := U1 XOR U2 XOR ... XOR Ui 362 363 where "i" is the iteration count, "+" is the string concatenation 364 operator, and INT(g) is a 4-octet encoding of the integer g, most 365 significant octet first. 366 367 Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the 368 pseudorandom function (PRF) and with dkLen == output length of 369 HMAC() == output length of H(). 370 3713. SCRAM Algorithm Overview 372 373 The following is a description of a full, uncompressed SASL SCRAM 374 authentication exchange. Nothing in SCRAM prevents either sending 375 the client-first message with the SASL authentication request defined 376 by an application protocol ("initial client response"), or sending 377 the server-final message as additional data of the SASL outcome of 378 authentication exchange defined by an application protocol. See 379 [RFC4422] for more details. 380 381 Note that this section omits some details, such as client and server 382 nonces. See Section 5 for more details. 383 384 To begin with, the SCRAM client is in possession of a username and 385 password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends 386 the username to the server, which retrieves the corresponding 387 authentication information, i.e., a salt, StoredKey, ServerKey, and 388 the iteration count i. (Note that a server implementation may choose 389 390 391 392 393 394Newman, et al. Standards Track [Page 7] 395 396RFC 5802 SCRAM July 2010 397 398 399 to use the same iteration count for all accounts.) The server sends 400 the salt and the iteration count to the client, which then computes 401 the following values and sends a ClientProof to the server: 402 403 (*) Note that both the username and the password MUST be encoded in 404 UTF-8 [RFC3629]. 405 406 Informative Note: Implementors are encouraged to create test cases 407 that use both usernames and passwords with non-ASCII codepoints. In 408 particular, it's useful to test codepoints whose "Unicode 409 Normalization Form C" and "Unicode Normalization Form KC" are 410 different. Some examples of such codepoints include Vulgar Fraction 411 One Half (U+00BD) and Acute Accent (U+00B4). 412 413 SaltedPassword := Hi(Normalize(password), salt, i) 414 ClientKey := HMAC(SaltedPassword, "Client Key") 415 StoredKey := H(ClientKey) 416 AuthMessage := client-first-message-bare + "," + 417 server-first-message + "," + 418 client-final-message-without-proof 419 ClientSignature := HMAC(StoredKey, AuthMessage) 420 ClientProof := ClientKey XOR ClientSignature 421 ServerKey := HMAC(SaltedPassword, "Server Key") 422 ServerSignature := HMAC(ServerKey, AuthMessage) 423 424 The server authenticates the client by computing the ClientSignature, 425 exclusive-ORing that with the ClientProof to recover the ClientKey 426 and verifying the correctness of the ClientKey by applying the hash 427 function and comparing the result to the StoredKey. If the ClientKey 428 is correct, this proves that the client has access to the user's 429 password. 430 431 Similarly, the client authenticates the server by computing the 432 ServerSignature and comparing it to the value sent by the server. If 433 the two are equal, it proves that the server had access to the user's 434 ServerKey. 435 436 The AuthMessage is computed by concatenating messages from the 437 authentication exchange. The format of these messages is defined in 438 Section 7. 439 4404. SCRAM Mechanism Names 441 442 A SCRAM mechanism name is a string "SCRAM-" followed by the 443 uppercased name of the underlying hash function taken from the IANA 444 "Hash Function Textual Names" registry (see http://www.iana.org), 445 optionally followed by the suffix "-PLUS" (see below). Note that 446 SASL mechanism names are limited to 20 octets, which means that only 447 448 449 450Newman, et al. Standards Track [Page 8] 451 452RFC 5802 SCRAM July 2010 453 454 455 hash function names with lengths shorter or equal to 9 octets 456 (20-length("SCRAM-")-length("-PLUS") can be used. For cases when the 457 underlying hash function name is longer than 9 octets, an alternative 458 9-octet (or shorter) name can be used to construct the corresponding 459 SCRAM mechanism name, as long as this alternative name doesn't 460 conflict with any other hash function name from the IANA "Hash 461 Function Textual Names" registry. In order to prevent future 462 conflict, such alternative names SHOULD be registered in the IANA 463 "Hash Function Textual Names" registry. 464 465 For interoperability, all SCRAM clients and servers MUST implement 466 the SCRAM-SHA-1 authentication mechanism, i.e., an authentication 467 mechanism from the SCRAM family that uses the SHA-1 hash function as 468 defined in [RFC3174]. 469 470 The "-PLUS" suffix is used only when the server supports channel 471 binding to the external channel. If the server supports channel 472 binding, it will advertise both the "bare" and "plus" versions of 473 whatever mechanisms it supports (e.g., if the server supports only 474 SCRAM with SHA-1, then it will advertise support for both SCRAM-SHA-1 475 and SCRAM-SHA-1-PLUS). If the server does not support channel 476 binding, then it will advertise only the "bare" version of the 477 mechanism (e.g., only SCRAM-SHA-1). The "-PLUS" exists to allow 478 negotiation of the use of channel binding. See Section 6. 479 4805. SCRAM Authentication Exchange 481 482 SCRAM is a SASL mechanism whose client response and server challenge 483 messages are text-based messages containing one or more attribute- 484 value pairs separated by commas. Each attribute has a one-letter 485 name. The messages and their attributes are described in 486 Section 5.1, and defined in Section 7. 487 488 SCRAM is a client-first SASL mechanism (see [RFC4422], Section 5, 489 item 2a), and returns additional data together with a server's 490 indication of a successful outcome. 491 492 This is a simple example of a SCRAM-SHA-1 authentication exchange 493 when the client doesn't support channel bindings (username 'user' and 494 password 'pencil' are used): 495 496 C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL 497 S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92, 498 i=4096 499 C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 500 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 501 S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 502 503 504 505 506Newman, et al. Standards Track [Page 9] 507 508RFC 5802 SCRAM July 2010 509 510 511 First, the client sends the "client-first-message" containing: 512 513 o a GS2 header consisting of a flag indicating whether channel 514 binding is supported-but-not-used, not supported, or used, and an 515 optional SASL authorization identity; 516 517 o SCRAM username and a random, unique nonce attributes. 518 519 Note that the client's first message will always start with "n", "y", 520 or "p"; otherwise, the message is invalid and authentication MUST 521 fail. This is important, as it allows for GS2 extensibility (e.g., 522 to add support for security layers). 523 524 In response, the server sends a "server-first-message" containing the 525 user's iteration count i and the user's salt, and appends its own 526 nonce to the client-specified one. 527 528 The client then responds by sending a "client-final-message" with the 529 same nonce and a ClientProof computed using the selected hash 530 function as explained earlier. 531 532 The server verifies the nonce and the proof, verifies that the 533 authorization identity (if supplied by the client in the first 534 message) is authorized to act as the authentication identity, and, 535 finally, it responds with a "server-final-message", concluding the 536 authentication exchange. 537 538 The client then authenticates the server by computing the 539 ServerSignature and comparing it to the value sent by the server. If 540 the two are different, the client MUST consider the authentication 541 exchange to be unsuccessful, and it might have to drop the 542 connection. 543 5445.1. SCRAM Attributes 545 546 This section describes the permissible attributes, their use, and the 547 format of their values. All attribute names are single US-ASCII 548 letters and are case-sensitive. 549 550 Note that the order of attributes in client or server messages is 551 fixed, with the exception of extension attributes (described by the 552 "extensions" ABNF production), which can appear in any order in the 553 designated positions. See Section 7 for authoritative reference. 554 555 o a: This is an optional attribute, and is part of the GS2 [RFC5801] 556 bridge between the GSS-API and SASL. This attribute specifies an 557 authorization identity. A client may include it in its first 558 message to the server if it wants to authenticate as one user, but 559 560 561 562Newman, et al. Standards Track [Page 10] 563 564RFC 5802 SCRAM July 2010 565 566 567 subsequently act as a different user. This is typically used by 568 an administrator to perform some management task on behalf of 569 another user, or by a proxy in some situations. 570 571 Upon the receipt of this value the server verifies its 572 correctness according to the used SASL protocol profile. 573 Failed verification results in failed authentication exchange. 574 575 If this attribute is omitted (as it normally would be), the 576 authorization identity is assumed to be derived from the 577 username specified with the (required) "n" attribute. 578 579 The server always authenticates the user specified by the "n" 580 attribute. If the "a" attribute specifies a different user, 581 the server associates that identity with the connection after 582 successful authentication and authorization checks. 583 584 The syntax of this field is the same as that of the "n" field 585 with respect to quoting of '=' and ','. 586 587 o n: This attribute specifies the name of the user whose password is 588 used for authentication (a.k.a. "authentication identity" 589 [RFC4422]). A client MUST include it in its first message to the 590 server. If the "a" attribute is not specified (which would 591 normally be the case), this username is also the identity that 592 will be associated with the connection subsequent to 593 authentication and authorization. 594 595 Before sending the username to the server, the client SHOULD 596 prepare the username using the "SASLprep" profile [RFC4013] of 597 the "stringprep" algorithm [RFC3454] treating it as a query 598 string (i.e., unassigned Unicode code points are allowed). If 599 the preparation of the username fails or results in an empty 600 string, the client SHOULD abort the authentication exchange 601 (*). 602 603 (*) An interactive client can request a repeated entry of the 604 username value. 605 606 Upon receipt of the username by the server, the server MUST 607 either prepare it using the "SASLprep" profile [RFC4013] of the 608 "stringprep" algorithm [RFC3454] treating it as a query string 609 (i.e., unassigned Unicode codepoints are allowed) or otherwise 610 be prepared to do SASLprep-aware string comparisons and/or 611 index lookups. If the preparation of the username fails or 612 results in an empty string, the server SHOULD abort the 613 614 615 616 617 618Newman, et al. Standards Track [Page 11] 619 620RFC 5802 SCRAM July 2010 621 622 623 authentication exchange. Whether or not the server prepares 624 the username using "SASLprep", it MUST use it as received in 625 hash calculations. 626 627 The characters ',' or '=' in usernames are sent as '=2C' and 628 '=3D' respectively. If the server receives a username that 629 contains '=' not followed by either '2C' or '3D', then the 630 server MUST fail the authentication. 631 632 o m: This attribute is reserved for future extensibility. In this 633 version of SCRAM, its presence in a client or a server message 634 MUST cause authentication failure when the attribute is parsed by 635 the other end. 636 637 o r: This attribute specifies a sequence of random printable ASCII 638 characters excluding ',' (which forms the nonce used as input to 639 the hash function). No quoting is applied to this string. As 640 described earlier, the client supplies an initial value in its 641 first message, and the server augments that value with its own 642 nonce in its first response. It is important that this value be 643 different for each authentication (see [RFC4086] for more details 644 on how to achieve this). The client MUST verify that the initial 645 part of the nonce used in subsequent messages is the same as the 646 nonce it initially specified. The server MUST verify that the 647 nonce sent by the client in the second message is the same as the 648 one sent by the server in its first message. 649 650 o c: This REQUIRED attribute specifies the base64-encoded GS2 header 651 and channel binding data. It is sent by the client in its second 652 authentication message. The attribute data consist of: 653 654 * the GS2 header from the client's first message (recall that the 655 GS2 header contains a channel binding flag and an optional 656 authzid). This header is going to include channel binding type 657 prefix (see [RFC5056]), if and only if the client is using 658 channel binding; 659 660 * followed by the external channel's channel binding data, if and 661 only if the client is using channel binding. 662 663 o s: This attribute specifies the base64-encoded salt used by the 664 server for this user. It is sent by the server in its first 665 message to the client. 666 667 o i: This attribute specifies an iteration count for the selected 668 hash function and user, and MUST be sent by the server along with 669 the user's salt. 670 671 672 673 674Newman, et al. Standards Track [Page 12] 675 676RFC 5802 SCRAM July 2010 677 678 679 For the SCRAM-SHA-1/SCRAM-SHA-1-PLUS SASL mechanism, servers 680 SHOULD announce a hash iteration-count of at least 4096. Note 681 that a client implementation MAY cache ClientKey&ServerKey (or 682 just SaltedPassword) for later reauthentication to the same 683 service, as it is likely that the server is going to advertise 684 the same salt value upon reauthentication. This might be 685 useful for mobile clients where CPU usage is a concern. 686 687 o p: This attribute specifies a base64-encoded ClientProof. The 688 client computes this value as described in the overview and sends 689 it to the server. 690 691 o v: This attribute specifies a base64-encoded ServerSignature. It 692 is sent by the server in its final message, and is used by the 693 client to verify that the server has access to the user's 694 authentication information. This value is computed as explained 695 in the overview. 696 697 o e: This attribute specifies an error that occurred during 698 authentication exchange. It is sent by the server in its final 699 message and can help diagnose the reason for the authentication 700 exchange failure. On failed authentication, the entire server- 701 final-message is OPTIONAL; specifically, a server implementation 702 MAY conclude the SASL exchange with a failure without sending the 703 server-final-message. This results in an application-level error 704 response without an extra round-trip. If the server-final-message 705 is sent on authentication failure, then the "e" attribute MUST be 706 included. 707 708 o As-yet unspecified mandatory and optional extensions. Mandatory 709 extensions are encoded as values of the 'm' attribute (see ABNF 710 for reserved-mext in section 7). Optional extensions use as-yet 711 unassigned attribute names. 712 713 Mandatory extensions sent by one peer but not understood by the 714 other MUST cause authentication failure (the server SHOULD send 715 the "extensions-not-supported" server-error-value). 716 717 Unknown optional extensions MUST be ignored upon receipt. 718 7195.2. Compliance with SASL Mechanism Requirements 720 721 This section describes compliance with SASL mechanism requirements 722 specified in Section 5 of [RFC4422]. 723 724 1) "SCRAM-SHA-1" and "SCRAM-SHA-1-PLUS". 725 726 2a) SCRAM is a client-first mechanism. 727 728 729 730Newman, et al. Standards Track [Page 13] 731 732RFC 5802 SCRAM July 2010 733 734 735 2b) SCRAM sends additional data with success. 736 737 3) SCRAM is capable of transferring authorization identities from 738 the client to the server. 739 740 4) SCRAM does not offer any security layers (SCRAM offers channel 741 binding instead). 742 743 5) SCRAM has a hash protecting the authorization identity. 744 7456. Channel Binding 746 747 SCRAM supports channel binding to external secure channels, such as 748 TLS. Clients and servers may or may not support channel binding, 749 therefore the use of channel binding is negotiable. SCRAM does not 750 provide security layers, however, therefore it is imperative that 751 SCRAM provide integrity protection for the negotiation of channel 752 binding. 753 754 Use of channel binding is negotiated as follows: 755 756 o Servers that support the use of channel binding SHOULD advertise 757 both the non-PLUS (SCRAM-<hash-function>) and PLUS-variant (SCRAM- 758 <hash-function>-PLUS) mechanism name. If the server cannot 759 support channel binding, it SHOULD advertise only the non-PLUS- 760 variant. If the server would never succeed in the authentication 761 of the non-PLUS-variant due to policy reasons, it MUST advertise 762 only the PLUS-variant. 763 764 o If the client supports channel binding and the server does not 765 appear to (i.e., the client did not see the -PLUS name advertised 766 by the server), then the client MUST NOT use an "n" gs2-cbind- 767 flag. 768 769 o Clients that support mechanism negotiation and channel binding 770 MUST use a "p" gs2-cbind-flag when the server offers the PLUS- 771 variant of the desired GS2 mechanism. 772 773 o If the client does not support channel binding, then it MUST use 774 an "n" gs2-cbind-flag. Conversely, if the client requires the use 775 of channel binding then it MUST use a "p" gs2-cbind-flag. Clients 776 that do not support mechanism negotiation never use a "y" gs2- 777 cbind-flag, they use either "p" or "n" according to whether they 778 require and support the use of channel binding or whether they do 779 not, respectively. 780 781 o Upon receipt of the client-first message, the server checks the 782 channel binding flag (gs2-cbind-flag). 783 784 785 786Newman, et al. Standards Track [Page 14] 787 788RFC 5802 SCRAM July 2010 789 790 791 * If the flag is set to "y" and the server supports channel 792 binding, the server MUST fail authentication. This is because 793 if the client sets the channel binding flag to "y", then the 794 client must have believed that the server did not support 795 channel binding -- if the server did in fact support channel 796 binding, then this is an indication that there has been a 797 downgrade attack (e.g., an attacker changed the server's 798 mechanism list to exclude the -PLUS suffixed SCRAM mechanism 799 name(s)). 800 801 * If the channel binding flag was "p" and the server does not 802 support the indicated channel binding type, then the server 803 MUST fail authentication. 804 805 The server MUST always validate the client's "c=" field. The server 806 does this by constructing the value of the "c=" attribute and then 807 checking that it matches the client's c= attribute value. 808 809 For more discussions of channel bindings, and the syntax of channel 810 binding data for various security protocols, see [RFC5056]. 811 8126.1. Default Channel Binding 813 814 A default channel binding type agreement process for all SASL 815 application protocols that do not provide their own channel binding 816 type agreement is provided as follows. 817 818 'tls-unique' is the default channel binding type for any application 819 that doesn't specify one. 820 821 Servers MUST implement the "tls-unique" [RFC5929] channel binding 822 type, if they implement any channel binding. Clients SHOULD 823 implement the "tls-unique" [RFC5929] channel binding type, if they 824 implement any channel binding. Clients and servers SHOULD choose the 825 highest-layer/innermost end-to-end TLS channel as the channel to 826 which to bind. 827 828 Servers MUST choose the channel binding type indicated by the client, 829 or fail authentication if they don't support it. 830 8317. Formal Syntax 832 833 The following syntax specification uses the Augmented Backus-Naur 834 form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3", 835 and "UTF8-4" non-terminal are defined in [RFC3629]. 836 837 838 839 840 841 842Newman, et al. Standards Track [Page 15] 843 844RFC 5802 SCRAM July 2010 845 846 847 ALPHA = <as defined in RFC 5234 appendix B.1> 848 DIGIT = <as defined in RFC 5234 appendix B.1> 849 UTF8-2 = <as defined in RFC 3629 (STD 63)> 850 UTF8-3 = <as defined in RFC 3629 (STD 63)> 851 UTF8-4 = <as defined in RFC 3629 (STD 63)> 852 853 attr-val = ALPHA "=" value 854 ;; Generic syntax of any attribute sent 855 ;; by server or client 856 857 value = 1*value-char 858 859 value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / 860 UTF8-2 / UTF8-3 / UTF8-4 861 ;; UTF8-char except NUL, "=", and ",". 862 863 value-char = value-safe-char / "=" 864 865 printable = %x21-2B / %x2D-7E 866 ;; Printable ASCII except ",". 867 ;; Note that any "printable" is also 868 ;; a valid "value". 869 870 base64-char = ALPHA / DIGIT / "/" / "+" 871 872 base64-4 = 4base64-char 873 874 base64-3 = 3base64-char "=" 875 876 base64-2 = 2base64-char "==" 877 878 base64 = *base64-4 [base64-3 / base64-2] 879 880 posit-number = %x31-39 *DIGIT 881 ;; A positive number. 882 883 saslname = 1*(value-safe-char / "=2C" / "=3D") 884 ;; Conforms to <value>. 885 886 authzid = "a=" saslname 887 ;; Protocol specific. 888 889 cb-name = 1*(ALPHA / DIGIT / "." / "-") 890 ;; See RFC 5056, Section 7. 891 ;; E.g., "tls-server-end-point" or 892 ;; "tls-unique". 893 894 895 896 897 898Newman, et al. Standards Track [Page 16] 899 900RFC 5802 SCRAM July 2010 901 902 903 gs2-cbind-flag = ("p=" cb-name) / "n" / "y" 904 ;; "n" -> client doesn't support channel binding. 905 ;; "y" -> client does support channel binding 906 ;; but thinks the server does not. 907 ;; "p" -> client requires channel binding. 908 ;; The selected channel binding follows "p=". 909 910 gs2-header = gs2-cbind-flag "," [ authzid ] "," 911 ;; GS2 header for SCRAM 912 ;; (the actual GS2 header includes an optional 913 ;; flag to indicate that the GSS mechanism is not 914 ;; "standard", but since SCRAM is "standard", we 915 ;; don't include that flag). 916 917 username = "n=" saslname 918 ;; Usernames are prepared using SASLprep. 919 920 reserved-mext = "m=" 1*(value-char) 921 ;; Reserved for signaling mandatory extensions. 922 ;; The exact syntax will be defined in 923 ;; the future. 924 925 channel-binding = "c=" base64 926 ;; base64 encoding of cbind-input. 927 928 proof = "p=" base64 929 930 nonce = "r=" c-nonce [s-nonce] 931 ;; Second part provided by server. 932 933 c-nonce = printable 934 935 s-nonce = printable 936 937 salt = "s=" base64 938 939 verifier = "v=" base64 940 ;; base-64 encoded ServerSignature. 941 942 iteration-count = "i=" posit-number 943 ;; A positive number. 944 945 client-first-message-bare = 946 [reserved-mext ","] 947 username "," nonce ["," extensions] 948 949 client-first-message = 950 gs2-header client-first-message-bare 951 952 953 954Newman, et al. Standards Track [Page 17] 955 956RFC 5802 SCRAM July 2010 957 958 959 server-first-message = 960 [reserved-mext ","] nonce "," salt "," 961 iteration-count ["," extensions] 962 963 client-final-message-without-proof = 964 channel-binding "," nonce ["," 965 extensions] 966 967 client-final-message = 968 client-final-message-without-proof "," proof 969 970 server-error = "e=" server-error-value 971 972 server-error-value = "invalid-encoding" / 973 "extensions-not-supported" / ; unrecognized 'm' value 974 "invalid-proof" / 975 "channel-bindings-dont-match" / 976 "server-does-support-channel-binding" / 977 ; server does not support channel binding 978 "channel-binding-not-supported" / 979 "unsupported-channel-binding-type" / 980 "unknown-user" / 981 "invalid-username-encoding" / 982 ; invalid username encoding (invalid UTF-8 or 983 ; SASLprep failed) 984 "no-resources" / 985 "other-error" / 986 server-error-value-ext 987 ; Unrecognized errors should be treated as "other-error". 988 ; In order to prevent information disclosure, the server 989 ; may substitute the real reason with "other-error". 990 991 server-error-value-ext = value 992 ; Additional error reasons added by extensions 993 ; to this document. 994 995 server-final-message = (server-error / verifier) 996 ["," extensions] 997 998 extensions = attr-val *("," attr-val) 999 ;; All extensions are optional, 1000 ;; i.e., unrecognized attributes 1001 ;; not defined in this document 1002 ;; MUST be ignored. 1003 1004 cbind-data = 1*OCTET 1005 1006 1007 1008 1009 1010Newman, et al. Standards Track [Page 18] 1011 1012RFC 5802 SCRAM July 2010 1013 1014 1015 cbind-input = gs2-header [ cbind-data ] 1016 ;; cbind-data MUST be present for 1017 ;; gs2-cbind-flag of "p" and MUST be absent 1018 ;; for "y" or "n". 1019 10208. SCRAM as a GSS-API Mechanism 1021 1022 This section and its sub-sections and all normative references of it 1023 not referenced elsewhere in this document are INFORMATIONAL for SASL 1024 implementors, but they are NORMATIVE for GSS-API implementors. 1025 1026 SCRAM is actually also a GSS-API mechanism. The messages are the 1027 same, but a) the GS2 header on the client's first message and channel 1028 binding data is excluded when SCRAM is used as a GSS-API mechanism, 1029 and b) the RFC2743 section 3.1 initial context token header is 1030 prefixed to the client's first authentication message (context 1031 token). 1032 1033 The GSS-API mechanism OID for SCRAM-SHA-1 is 1.3.6.1.5.5.14 (see 1034 Section 10). 1035 1036 SCRAM security contexts always have the mutual_state flag 1037 (GSS_C_MUTUAL_FLAG) set to TRUE. SCRAM does not support credential 1038 delegation, therefore SCRAM security contexts alway have the 1039 deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE. 1040 10418.1. GSS-API Principal Name Types for SCRAM 1042 1043 SCRAM does not explicitly name acceptor principals. However, the use 1044 of acceptor principal names to find or prompt for passwords is 1045 useful. Therefore, SCRAM supports standard generic name syntaxes for 1046 acceptors such as GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 1047 4.1). Implementations should use the target name passed to 1048 GSS_Init_sec_context(), if any, to help retrieve or prompt for SCRAM 1049 passwords. 1050 1051 SCRAM supports only a single name type for initiators: 1052 GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for 1053 SCRAM. 1054 1055 There is no name canonicalization procedure for SCRAM beyond applying 1056 SASLprep as described in Section 5.1. 1057 1058 The query, display, and exported name syntaxes for SCRAM principal 1059 names are all the same. There are no SCRAM-specific name syntaxes 1060 (SCRAM initiator principal names are free-form); -- applications 1061 should use generic GSS-API name types such as GSS_C_NT_USER_NAME and 1062 1063 1064 1065 1066Newman, et al. Standards Track [Page 19] 1067 1068RFC 5802 SCRAM July 2010 1069 1070 1071 GSS_C_NT_HOSTBASED_SERVICE (see [RFC2743], Section 4). The exported 1072 name token does, of course, conform to [RFC2743], Section 3.2, but 1073 the "NAME" part of the token is just a SCRAM user name. 1074 10758.2. GSS-API Per-Message Tokens for SCRAM 1076 1077 The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the 1078 same as those for the Kerberos V GSS-API mechanism [RFC4121] (see 1079 Section 4.2 and sub-sections), using the Kerberos V "aes128-cts-hmac- 1080 sha1-96" enctype [RFC3962]. 1081 1082 The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state 1083 (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail 1084 (GSS_C_CONF_FLAG) security context flags are always set to TRUE. 1085 1086 The 128-bit session "protocol key" SHALL be derived by using the 1087 least significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API 1088 session key" || ClientKey || AuthMessage). "Specific keys" are then 1089 derived as usual as described in Section 2 of [RFC4121], [RFC3961], 1090 and [RFC3962]. 1091 1092 The terms "protocol key" and "specific key" are Kerberos V5 terms 1093 [RFC3961]. 1094 1095 SCRAM does support PROT_READY, and is PROT_READY on the initiator 1096 side first upon receipt of the server's reply to the initial security 1097 context token. 1098 10998.3. GSS_Pseudo_random() for SCRAM 1100 1101 The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for 1102 the Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor- 1103 asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and 1104 GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random(). 1105 The protocol key to be used for the GSS_Pseudo_random() SHALL be the 1106 same as the key defined in Section 8.2. 1107 11089. Security Considerations 1109 1110 If the authentication exchange is performed without a strong security 1111 layer (such as TLS with data confidentiality), then a passive 1112 eavesdropper can gain sufficient information to mount an offline 1113 dictionary or brute-force attack that can be used to recover the 1114 user's password. The amount of time necessary for this attack 1115 depends on the cryptographic hash function selected, the strength of 1116 the password, and the iteration count supplied by the server. An 1117 external security layer with strong encryption will prevent this 1118 attack. 1119 1120 1121 1122Newman, et al. Standards Track [Page 20] 1123 1124RFC 5802 SCRAM July 2010 1125 1126 1127 If the external security layer used to protect the SCRAM exchange 1128 uses an anonymous key exchange, then the SCRAM channel binding 1129 mechanism can be used to detect a man-in-the-middle attack on the 1130 security layer and cause the authentication to fail as a result. 1131 However, the man-in-the-middle attacker will have gained sufficient 1132 information to mount an offline dictionary or brute-force attack. 1133 For this reason, SCRAM allows to increase the iteration count over 1134 time. (Note that a server that is only in possession of "StoredKey" 1135 and "ServerKey" can't automatically increase the iteration count upon 1136 successful authentication. Such an increase would require resetting 1137 the user's password.) 1138 1139 If the authentication information is stolen from the authentication 1140 database, then an offline dictionary or brute-force attack can be 1141 used to recover the user's password. The use of salt mitigates this 1142 attack somewhat by requiring a separate attack on each password. 1143 Authentication mechanisms that protect against this attack are 1144 available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is 1145 an example of such technology. The WG elected not to use EKE like 1146 mechanisms as a basis for SCRAM. 1147 1148 If an attacker obtains the authentication information from the 1149 authentication repository and either eavesdrops on one authentication 1150 exchange or impersonates a server, the attacker gains the ability to 1151 impersonate that user to all servers providing SCRAM access using the 1152 same hash function, password, iteration count, and salt. For this 1153 reason, it is important to use randomly generated salt values. 1154 1155 SCRAM does not negotiate a hash function to use. Hash function 1156 negotiation is left to the SASL mechanism negotiation. It is 1157 important that clients be able to sort a locally available list of 1158 mechanisms by preference so that the client may pick the appropriate 1159 mechanism to use from a server's advertised mechanism list. This 1160 preference order is not specified here as it is a local matter. The 1161 preference order should include objective and subjective notions of 1162 mechanism cryptographic strength (e.g., SCRAM with a successor to 1163 SHA-1 may be preferred over SCRAM with SHA-1). 1164 1165 Note that to protect the SASL mechanism negotiation applications 1166 normally must list the server mechanisms twice: once before and once 1167 after authentication, the latter using security layers. Since SCRAM 1168 does not provide security layers, the only ways to protect the 1169 mechanism negotiation are a) use channel binding to an external 1170 channel, or b) use an external channel that authenticates a user- 1171 provided server name. 1172 1173 1174 1175 1176 1177 1178Newman, et al. Standards Track [Page 21] 1179 1180RFC 5802 SCRAM July 2010 1181 1182 1183 SCRAM does not protect against downgrade attacks of channel binding 1184 types. The complexities of negotiating a channel binding type, and 1185 handling down-grade attacks in that negotiation, were intentionally 1186 left out of scope for this document. 1187 1188 A hostile server can perform a computational denial-of-service attack 1189 on clients by sending a big iteration count value. 1190 1191 See [RFC4086] for more information about generating randomness. 1192 119310. IANA Considerations 1194 1195 IANA has added the following family of SASL mechanisms to the SASL 1196 Mechanism registry established by [RFC4422]: 1197 1198 To: iana@iana.org 1199 Subject: Registration of a new SASL family SCRAM 1200 1201 SASL mechanism name (or prefix for the family): SCRAM-* 1202 Security considerations: Section 7 of [RFC5802] 1203 Published specification (optional, recommended): [RFC5802] 1204 Person & email address to contact for further information: 1205 IETF SASL WG <sasl@ietf.org> 1206 Intended usage: COMMON 1207 Owner/Change controller: IESG <iesg@ietf.org> 1208 Note: Members of this family MUST be explicitly registered 1209 using the "IETF Review" [RFC5226] registration procedure. 1210 Reviews MUST be requested on the SASL mailing list 1211 <sasl@ietf.org> (or a successor designated by the responsible 1212 Security AD). 1213 1214 Note to future SCRAM-mechanism designers: each new SCRAM-SASL 1215 mechanism MUST be explicitly registered with IANA and MUST comply 1216 with SCRAM-mechanism naming convention defined in Section 4 of this 1217 document. 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234Newman, et al. Standards Track [Page 22] 1235 1236RFC 5802 SCRAM July 2010 1237 1238 1239 IANA has added the following entries to the SASL Mechanism registry 1240 established by [RFC4422]: 1241 1242 To: iana@iana.org 1243 Subject: Registration of a new SASL mechanism SCRAM-SHA-1 1244 1245 SASL mechanism name (or prefix for the family): SCRAM-SHA-1 1246 Security considerations: Section 7 of [RFC5802] 1247 Published specification (optional, recommended): [RFC5802] 1248 Person & email address to contact for further information: 1249 IETF SASL WG <sasl@ietf.org> 1250 Intended usage: COMMON 1251 Owner/Change controller: IESG <iesg@ietf.org> 1252 Note: 1253 1254 To: iana@iana.org 1255 Subject: Registration of a new SASL mechanism SCRAM-SHA-1-PLUS 1256 1257 SASL mechanism name (or prefix for the family): SCRAM-SHA-1-PLUS 1258 Security considerations: Section 7 of [RFC5802] 1259 Published specification (optional, recommended): [RFC5802] 1260 Person & email address to contact for further information: 1261 IETF SASL WG <sasl@ietf.org> 1262 Intended usage: COMMON 1263 Owner/Change controller: IESG <iesg@ietf.org> 1264 Note: 1265 1266 Per this document, IANA has assigned a GSS-API mechanism OID for 1267 SCRAM-SHA-1 from the iso.org.dod.internet.security.mechanisms prefix 1268 (see "SMI Security for Mechanism Codes" registry). 1269 127011. Acknowledgements 1271 1272 This document benefited from discussions on the SASL WG mailing list. 1273 The authors would like to specially thank Dave Cridland, Simon 1274 Josefsson, Jeffrey Hutzelman, Kurt Zeilenga, Pasi Eronen, Ben 1275 Campbell, Peter Saint-Andre, and Tobias Markmann for their 1276 contributions to this document. A special thank you to Simon 1277 Josefsson for shepherding this document and for doing one of the 1278 first implementations of this specification. 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290Newman, et al. Standards Track [Page 23] 1291 1292RFC 5802 SCRAM July 2010 1293 1294 129512. References 1296 129712.1. Normative References 1298 1299 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1300 Hashing for Message Authentication", RFC 2104, 1301 February 1997. 1302 1303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1304 Requirement Levels", BCP 14, RFC 2119, March 1997. 1305 1306 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1307 (SHA1)", RFC 3174, September 2001. 1308 1309 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1310 Internationalized Strings ("stringprep")", RFC 3454, 1311 December 2002. 1312 1313 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1314 10646", STD 63, RFC 3629, November 2003. 1315 1316 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1317 and Passwords", RFC 4013, February 2005. 1318 1319 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1320 Security Layer (SASL)", RFC 4422, June 2006. 1321 1322 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1323 Encodings", RFC 4648, October 2006. 1324 1325 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1326 Channels", RFC 5056, November 2007. 1327 1328 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1329 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1330 1331 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1332 for TLS", RFC 5929, July 2010. 1333 133412.2. Normative References for GSS-API Implementors 1335 1336 [RFC2743] Linn, J., "Generic Security Service Application Program 1337 Interface Version 2, Update 1", RFC 2743, January 2000. 1338 1339 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1340 Kerberos 5", RFC 3961, February 2005. 1341 1342 1343 1344 1345 1346Newman, et al. Standards Track [Page 24] 1347 1348RFC 5802 SCRAM July 2010 1349 1350 1351 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 1352 Encryption for Kerberos 5", RFC 3962, February 2005. 1353 1354 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1355 Version 5 Generic Security Service Application Program 1356 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1357 July 2005. 1358 1359 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API 1360 Extension for the Generic Security Service Application 1361 Program Interface (GSS-API)", RFC 4401, February 2006. 1362 1363 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the 1364 Kerberos V Generic Security Service Application Program 1365 Interface (GSS-API) Mechanism", RFC 4402, February 2006. 1366 1367 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1368 Service Application Program Interface (GSS-API) Mechanisms 1369 in Simple Authentication and Security Layer (SASL): The 1370 GS2 Mechanism Family", RFC 5801, July 2010. 1371 137212.3. Informative References 1373 1374 [CRAMHISTORIC] 1375 Zeilenga, K., "CRAM-MD5 to Historic", Work in Progress, 1376 November 2008. 1377 1378 [DIGESTHISTORIC] 1379 Melnikov, A., "Moving DIGEST-MD5 to Historic", Work 1380 in Progress, July 2008. 1381 1382 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1383 "Remote Authentication Dial In User Service (RADIUS)", 1384 RFC 2865, June 2000. 1385 1386 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 1387 Specification Version 2.0", RFC 2898, September 2000. 1388 1389 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 1390 RFC 2945, September 2000. 1391 1392 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1393 Requirements for Security", BCP 106, RFC 4086, June 2005. 1394 1395 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 1396 (LDAP): Technical Specification Road Map", RFC 4510, 1397 June 2006. 1398 1399 1400 1401 1402Newman, et al. Standards Track [Page 25] 1403 1404RFC 5802 SCRAM July 2010 1405 1406 1407 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 1408 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 1409 1410 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1411 RFC 4949, August 2007. 1412 1413 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1414 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1415 May 2008. 1416 1417 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1418 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1419 1420 [RFC5803] Melnikov, A., "Lightweight Directory Access Protocol 1421 (LDAP) Schema for Storing Salted Challenge Response 1422 Authentication Mechanism (SCRAM) Secrets", RFC 5803, 1423 July 2010. 1424 1425 [tls-server-end-point] 1426 IANA, "Registration of TLS server end-point channel 1427 bindings", available from http://www.iana.org, June 2008. 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458Newman, et al. Standards Track [Page 26] 1459 1460RFC 5802 SCRAM July 2010 1461 1462 1463Appendix A. Other Authentication Mechanisms 1464 1465 The DIGEST-MD5 [DIGESTHISTORIC] mechanism has proved to be too 1466 complex to implement and test, and thus has poor interoperability. 1467 The security layer is often not implemented, and almost never used; 1468 everyone uses TLS instead. For a more complete list of problems with 1469 DIGEST-MD5 that led to the creation of SCRAM, see [DIGESTHISTORIC]. 1470 1471 The CRAM-MD5 SASL mechanism, while widely deployed, also has some 1472 problems. In particular, it is missing some modern SASL features 1473 such as support for internationalized usernames and passwords, 1474 support for passing of authorization identity, and support for 1475 channel bindings. It also doesn't support server authentication. 1476 For a more complete list of problems with CRAM-MD5, see 1477 [CRAMHISTORIC]. 1478 1479 The PLAIN [RFC4616] SASL mechanism allows a malicious server or 1480 eavesdropper to impersonate the authenticating user to any other 1481 server for which the user has the same password. It also sends the 1482 password in the clear over the network, unless TLS is used. Server 1483 authentication is not supported. 1484 1485Appendix B. Design Motivations 1486 1487 The following design goals shaped this document. Note that some of 1488 the goals have changed since the initial version of the document. 1489 1490 o The SASL mechanism has all modern SASL features: support for 1491 internationalized usernames and passwords, support for passing of 1492 authorization identity, and support for channel bindings. 1493 1494 o The protocol supports mutual authentication. 1495 1496 o The authentication information stored in the authentication 1497 database is not sufficient by itself to impersonate the client. 1498 1499 o The server does not gain the ability to impersonate the client to 1500 other servers (with an exception for server-authorized proxies), 1501 unless such other servers allow SCRAM authentication and use the 1502 same salt and iteration count for the user. 1503 1504 o The mechanism is extensible, but (hopefully) not over-engineered 1505 in this respect. 1506 1507 o The mechanism is easier to implement than DIGEST-MD5 in both 1508 clients and servers. 1509 1510 1511 1512 1513 1514Newman, et al. Standards Track [Page 27] 1515 1516RFC 5802 SCRAM July 2010 1517 1518 1519Authors' Addresses 1520 1521 Chris Newman 1522 Oracle 1523 800 Royal Oaks 1524 Monrovia, CA 91016 1525 USA 1526 1527 EMail: chris.newman@oracle.com 1528 1529 1530 Abhijit Menon-Sen 1531 Oryx Mail Systems GmbH 1532 1533 EMail: ams@toroid.org 1534 1535 1536 Alexey Melnikov 1537 Isode, Ltd. 1538 1539 EMail: Alexey.Melnikov@isode.com 1540 1541 1542 Nicolas Williams 1543 Oracle 1544 5300 Riata Trace Ct 1545 Austin, TX 78727 1546 USA 1547 1548 EMail: Nicolas.Williams@oracle.com 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570Newman, et al. Standards Track [Page 28] 1571 1572