idnits 2.17.1 draft-melnikov-httpbis-scram-auth-00.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 9 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 date (June 11, 2012) is 4336 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5929' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'RFC4616' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'RFC5803' is defined on line 824, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-19 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPBis A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track June 11, 2012 5 Expires: December 13, 2012 7 Salted Challenge Response (SCRAM) HTTP Authentication Mechanism 8 draft-melnikov-httpbis-scram-auth-00.txt 10 Abstract 12 The secure authentication mechanism most widely deployed and used by 13 Internet application protocols is the transmission of clear-text 14 passwords over a channel protected by Transport Layer Security (TLS). 15 There are some significant security concerns with that mechanism, 16 which could be addressed by the use of a challenge response 17 authentication mechanism protected by TLS. Unfortunately, the HTTP 18 Digest challenge response mechanism presently on the standards track 19 failed widespread deployment, and have had success only in limited 20 use. 22 This specification describes a family of HTTP authentication 23 mechanisms called the Salted Challenge Response Authentication 24 Mechanism (SCRAM), which addresses the security concerns and meets 25 the deployability requirements. When used in combination with TLS or 26 an equivalent security layer, a mechanism from this family could 27 improve the status-quo for application protocol authentication. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 13, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Conventions Used in This Document . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 7 68 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . 9 69 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . 10 70 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 15 72 7. Security Considerations . . . . . . . . . . . . . . . . . . 19 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 75 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 23 76 11. Internet-Draft Change History . . . . . . . . . . . . . . . 24 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 12.1. Normative References . . . . . . . . . . . . . . . . . . . . 25 79 12.2. Informative References . . . . . . . . . . . . . . . . . . . 25 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 82 1. Conventions Used in This Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 Formal syntax is defined by [RFC5234] including the core rules 89 defined in Appendix B of [RFC5234]. 91 Example lines prefaced by "C:" are sent by the client and ones 92 prefaced by "S:" by the server. If a single "C:" or "S:" label 93 applies to multiple lines, then the line breaks between those lines 94 are for editorial clarity only, and are not part of the actual 95 protocol exchange. 97 1.1. Terminology 99 This document uses several terms defined in [RFC4949] ("Internet 100 Security Glossary") including the following: authentication, 101 authentication exchange, authentication information, brute force, 102 challenge-response, cryptographic hash function, dictionary attack, 103 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 104 one-way encryption function, password, replay attack and salt. 105 Readers not familiar with these terms should use that glossary as a 106 reference. 108 Some clarifications and additional definitions follow: 110 o Authentication information: Information used to verify an identity 111 claimed by a SCRAM client. The authentication information for a 112 SCRAM identity consists of salt, iteration count, the "StoredKey" 113 and "ServerKey" (as defined in the algorithm overview) for each 114 supported cryptographic hash function. 116 o Authentication database: The database used to look up the 117 authentication information associated with a particular identity. 118 For application protocols, LDAPv3 (see [RFC4510]) is frequently 119 used as the authentication database. For network-level protocols 120 such as PPP or 802.11x, the use of RADIUS [RFC2865] is more 121 common. 123 o Base64: An encoding mechanism defined in [RFC4648] which converts 124 an octet string input to a textual output string which can be 125 easily displayed to a human. The use of base64 in SCRAM is 126 restricted to the canonical form with no whitespace. 128 o Octet: An 8-bit byte. 130 o Octet string: A sequence of 8-bit bytes. 132 o Salt: A random octet string that is combined with a password 133 before applying a one-way encryption function. This value is used 134 to protect passwords that are stored in an authentication 135 database. 137 1.2. Notation 139 The pseudocode description of the algorithm uses the following 140 notations: 142 o ":=": The variable on the left hand side represents the octet 143 string resulting from the expression on the right hand side. 145 o "+": Octet string concatenation. 147 o "[ ]": A portion of an expression enclosed in "[" and "]" may not 148 be included in the result under some circumstances. See the 149 associated text for a description of those circumstances. 151 o Normalize(str): Apply the SASLPrep profile [RFC4013] of the 152 "stringprep" algorithm [RFC3454] as the normalization algorithm to 153 a UTF-8 [RFC3629] encoded "str". The resulting string is also in 154 UTF-8. When applying SASLPrep, "str" is treated as a "stored 155 strings", which means that unassigned Unicode codepoints are 156 prohibited (see Section 7 of [RFC3454]). Note that 157 implementations MUST either implement SASLPrep, or disallow use of 158 non US-ASCII Unicode codepoints in "str". 160 o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 161 [RFC2104]) using the octet string represented by "key" as the key 162 and the octet string "str" as the input string. The size of the 163 result is the hash result size for the hash function in use. For 164 example, it is 20 octets for SHA-1 (see [RFC3174]). 166 o H(str): Apply the cryptographic hash function to the octet string 167 "str", producing an octet string as a result. The size of the 168 result depends on the hash result size for the hash function in 169 use. 171 o XOR: Apply the exclusive-or operation to combine the octet string 172 on the left of this operator with the octet string on the right of 173 this operator. The length of the output and each of the two 174 inputs will be the same for this use. 176 o Hi(str, salt, i): 178 U1 := HMAC(str, salt + INT(1)) 179 U2 := HMAC(str, U1) 180 ... 181 Ui-1 := HMAC(str, Ui-2) 182 Ui := HMAC(str, Ui-1) 184 Hi := U1 XOR U2 XOR ... XOR Ui 186 where "i" is the iteration count, "+" is the string concatenation 187 operator and INT(g) is a four-octet encoding of the integer g, 188 most significant octet first. 190 Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 191 with dkLen == output length of HMAC() == output length of H(). 193 2. Introduction 195 This specification describes a family of authentication mechanisms 196 called the Salted Challenge Response Authentication Mechanism (SCRAM) 197 which addresses the requirements necessary to deploy a challenge- 198 response mechanism more widely than past attempts (see [RFC5802]). 199 When used in combination with Transport Layer Security (TLS, see 200 [RFC5246]) or an equivalent security layer, a mechanism from this 201 family could improve the status-quo for application protocol 202 authentication. 204 SCRAM provides the following protocol features: 206 o The authentication information stored in the authentication 207 database is not sufficient by itself to impersonate the client. 208 The information is salted to prevent a pre-stored dictionary 209 attack if the database is stolen. 211 o The server does not gain the ability to impersonate the client to 212 other servers (with an exception for server-authorized proxies). 214 o The mechanism permits the use of a server-authorized proxy without 215 requiring that proxy to have super-user rights with the back-end 216 server. 218 o Mutual authentication is supported, but only the client is named 219 (i.e., the server has no name). 221 3. SCRAM Algorithm Overview 223 The following is a description of a full HTTP SCRAM authentication 224 exchange. Note that this section omits some details, such as client 225 and server nonces. See Section 5 for more details. 227 To begin with, the SCRAM client is in possession of a username and 228 password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends 229 the username to the server, which retrieves the corresponding 230 authentication information, i.e. a salt, StoredKey, ServerKey and the 231 iteration count i. (Note that a server implementation may choose to 232 use the same iteration count for all accounts.) The server sends the 233 salt and the iteration count to the client, which then computes the 234 following values and sends a ClientProof to the server: 236 (*) - Note that both the username and the password MUST be encoded in 237 UTF-8 [RFC3629]. 239 Informative Note: Implementors are encouraged to create test cases 240 that use both username passwords with non-ASCII codepoints. In 241 particular, it's useful to test codepoints whose "Unicode 242 Normalization Form C" and "Unicode Normalization Form KC" are 243 different. Some examples of such codepoints include Vulgar Fraction 244 One Half (U+00BD) and Acute Accent (U+00B4). 246 SaltedPassword := Hi(Normalize(password), salt, i) 247 ClientKey := HMAC(SaltedPassword, "Client Key") 248 StoredKey := H(ClientKey) 249 AuthMessage := client-first-message-bare + "," + 250 server-first-message + "," + 251 client-final-message-without-proof 252 ClientSignature := HMAC(StoredKey, AuthMessage) 253 ClientProof := ClientKey XOR ClientSignature 254 ServerKey := HMAC(SaltedPassword, "Server Key") 255 ServerSignature := HMAC(ServerKey, AuthMessage) 257 The server authenticates the client by computing the ClientSignature, 258 exclusive-ORing that with the ClientProof to recover the ClientKey 259 and verifying the correctness of the ClientKey by applying the hash 260 function and comparing the result to the StoredKey. If the ClientKey 261 is correct, this proves that the client has access to the user's 262 password. 264 Similarly, the client authenticates the server by computing the 265 ServerSignature and comparing it to the value sent by the server. If 266 the two are equal, it proves that the server had access to the user's 267 ServerKey. 269 The AuthMessage is computed by concatenating messages from the 270 authentication exchange. The format of these messages is defined in 271 Section 6. 273 4. SCRAM Mechanism Names 275 A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" 276 followed by the uppercased name of the underlying hash function taken 277 from the IANA "Hash Function Textual Names" registry (see 278 http://www.iana.org) . 280 For interoperability, all HTTP clients and servers supporting SCRAM 281 MUST implement the SCRAM-SHA-1 authentication mechanism, i.e. an 282 authentication mechanism from the SCRAM family that uses the SHA-1 283 hash function as defined in [RFC3174]. 285 5. SCRAM Authentication Exchange 287 SCRAM is a HTTP Authentication mechanism whose client response 288 () and server challenge () 289 messages are text-based messages containing one or more attribute- 290 value pairs separated by commas. Each attribute has a one-letter 291 name, with the exception of a couple of attributes which are generic 292 to HTTP authentication, such as "realm" (and "sid"). The messages 293 and their attributes are described in Section 5.1, and defined in 294 Section 6. 296 challenge-scram = "SCRAM-SHA-1" 1*SP 1#auth-param 297 ; Complies with ABNF from I-D.ietf-httpbis-p7-auth. 298 ; Included in the WWW-Authenticate header field. 300 credentials-scram = "SCRAM-SHA-1" 1*SP 1#auth-param 301 ; Complies with from I-D.ietf-httpbis-p7-auth 302 ; Included in the Authorization header field. 304 This is a simple example of a SCRAM-SHA-1 authentication exchange 305 when the client doesn't support channel bindings (username 'user' and 306 password 'pencil' are used): 308 [...The server might have returned 401 Unauthorized first...] 310 C: GET /resource HTTP/1.1 311 C: Host: server.example.com 312 C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", 313 g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL 314 C: [...] 316 S: HTTP/1.1 401 Unauthorized 317 S: WWW-Authenticate: SCRAM-SHA-1 318 realm="testrealm@host.com",sid=AAAABBBBCCCCDDDD, 319 r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92, 320 i=4096 321 S: [...] 323 C: GET /resource HTTP/1.1 324 C: Host: server.example.com 325 C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, 326 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 327 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 328 C: [...] 329 S: HTTP/1.1 200 Ok 330 S: Authentication-Info: SCRAM-SHA-1 331 sid=AAAABBBBCCCCDDDD, 332 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 333 S: [...Other header fields and resource body...] 335 "SCRAM-SHA-1" authentication starts with sending the "Authorization" 336 request header field defined by HTTP/1.1, Part 7 337 [I-D.ietf-httpbis-p7-auth] containing "SCRAM-SHA-1" authentication 338 scheme and the following attributes: 340 o A "realm" attribute MAY be included to indicate the scope of 341 protection in the manner described in HTTP/1.1, Part 7 342 [I-D.ietf-httpbis-p7-auth]. As specified in 343 [I-D.ietf-httpbis-p7-auth], the "realm" attribute MUST NOT appear 344 more than once. 346 o The client also includes the "client-first-message" containing: 348 * a header ("g" attribute) consisting of a flag indicating 349 whether channel binding is supported-but-not-used, not 350 supported, or used ; 352 * SCRAM username and a random, unique nonce attributes. 354 Note that the client's first message will always start with "n", 355 "y" or "p", otherwise the message is invalid and authentication 356 MUST fail. 358 In response, the server sends WWW-Authenticate header field 359 containing: a unique session identifier (the "sid" attribute) plus 360 the "server-first-message" containing the user's iteration count i, 361 the user's salt, and the nonce with a concatenation of the client- 362 specified one with a server nonce. 364 The client then responds with another HTTP request with the 365 Authorization header field, which includes the "sid" attribute 366 received in the previous server response, together with "client- 367 final-message" data. The latter has the same nonce and a ClientProof 368 computed using the selected hash function (SHA-1) as explained 369 earlier. 371 The server verifies the nonce and the proof, and, finally, it 372 responds with a 200 HTTP response with the Authentication-Info header 373 field containing "server-final-message", concluding the 374 authentication exchange. 376 The client then authenticates the server by computing the 377 ServerSignature and comparing it to the value sent by the server. If 378 the two are different, the client MUST consider the authentication 379 exchange to be unsuccessful and it might have to drop the connection. 381 5.1. SCRAM Attributes 383 This section describes the permissible attributes, their use, and the 384 format of their values. All attribute names are single US-ASCII 385 letters and are case-sensitive. 387 Note that the order of attributes in client or server messages is 388 fixed, with the exception of extension attributes (described by the 389 "extensions" ABNF production), which can appear in any order in the 390 designated positions. See the ABNF section for authoritative 391 reference. 393 o g: This attribute value consist of a flag indicating whether 394 channel binding is supported-but-not-used, not supported, or used 395 . 397 o n: This attribute specifies the name of the user whose password is 398 used for authentication. A client MUST include it in its first 399 message to the server. 401 Before sending the username to the server, the client SHOULD 402 prepare the username using the "SASLPrep" profile [RFC4013] of 403 the "stringprep" algorithm [RFC3454] treating it as a query 404 string (i.e., unassigned Unicode code points are allowed). If 405 the preparation of the username fails or results in an empty 406 string, the client SHOULD abort the authentication exchange 407 (*). 409 (*) An interactive client can request a repeated entry of the 410 username value. 412 Upon receipt of the username by the server, the server MUST 413 either prepare it using the "SASLPrep" profile [RFC4013] of the 414 "stringprep" algorithm [RFC3454] treating it as a query string 415 (i.e., unassigned Unicode codepoints are allowed) or otherwise 416 be prepared to do SASLprep-aware string comparisons and/or 417 index lookups. If the preparation of the username fails or 418 results in an empty string, the server SHOULD abort the 419 authentication exchange. Whether or not the server prepares 420 the username using "SASLPrep", it MUST use it as received in 421 hash calculations. 423 The characters ',' or '=' in usernames are sent as '=2C' and 424 '=3D' respectively. If the server receives a username which 425 contains '=' not followed by either '2C' or '3D', then the 426 server MUST fail the authentication. 428 o m: This attribute is reserved for future extensibility. In this 429 version of SCRAM, its presence in a client or a server message 430 MUST cause authentication failure when the attribute is parsed by 431 the other end. 433 o r: This attribute specifies a sequence of random printable ASCII 434 characters excluding ',' which forms the nonce used as input to 435 the hash function. No quoting is applied to this string. As 436 described earlier, the client supplies an initial value in its 437 first message, and the server augments that value with its own 438 nonce in its first response. It is important that this value be 439 different for each authentication (see [RFC4086] for more details 440 on how to achieve this). The client MUST verify that the initial 441 part of the nonce used in subsequent messages is the same as the 442 nonce it initially specified. The server MUST verify that the 443 nonce sent by the client in the second message is the same as the 444 one sent by the server in its first message. 446 o c: This REQUIRED attribute specifies the base64-encoded GS2 header 447 and channel-binding data. It is sent by the client in its second 448 authentication message. The attribute data consist of: 450 * the GS2 header from the client's first message (recall that the 451 GS2 header contains a channel binding flag ). This header is 452 going to include channel binding type prefix (see [RFC5056]), 453 if and only if the client is using channel binding; 455 * followed by the external channel's channel binding data, if and 456 only if the client is using channel binding. 458 o s: This attribute specifies the base64-encoded salt used by the 459 server for this user. It is sent by the server in its first 460 message to the client. 462 o i: This attribute specifies an iteration count for the selected 463 hash function and user, and MUST be sent by the server along with 464 the user's salt. 466 For SCRAM-SHA-1 authentication mechanism servers SHOULD 467 announce a hash iteration-count of at least 4096. Note that a 468 client implementation MAY cache ClientKey&ServerKey (or just 469 SaltedPassword) for later reauthentication to the same service, 470 as it is likely that the server is going to advertise the same 471 salt value upon reauthentication. This might be useful for 472 mobile clients where CPU usage is a concern. 474 o p: This attribute specifies a base64-encoded ClientProof. The 475 client computes this value as described in the overview and sends 476 it to the server. 478 o v: This attribute specifies a base64-encoded ServerSignature. It 479 is sent by the server in its final message, and is used by the 480 client to verify that the server has access to the user's 481 authentication information. This value is computed as explained 482 in the overview. 484 6. Formal Syntax 486 The following syntax specification uses the Augmented Backus-Naur 487 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 488 and "UTF8-4" non-terminal are defined in [RFC3629]. 490 ALPHA = 491 DIGIT = 492 UTF8-2 = 493 UTF8-3 = 494 UTF8-4 = 496 attr-val = ALPHA "=" value 497 ;; Generic syntax of any attribute sent 498 ;; by server or client 500 value = 1*value-char 502 value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / 503 UTF8-2 / UTF8-3 / UTF8-4 504 ;; UTF8-char except NUL, "=", and ",". 506 value-char = value-safe-char / "=" 508 printable = %x21-2B / %x2D-7E 509 ;; Printable ASCII except ",". 510 ;; Note that any "printable" is also 511 ;; a valid "value". 513 base64-char = ALPHA / DIGIT / "/" / "+" 515 base64-4 = 4base64-char 517 base64-3 = 3base64-char "=" 519 base64-2 = 2base64-char "==" 521 base64 = *base64-4 [base64-3 / base64-2] 523 posit-number = %x31-39 *DIGIT 524 ;; A positive number. 526 cb-name = 1*(ALPHA / DIGIT / "." / "-") 527 ;; See RFC 5056, Section 7. 528 ;; E.g., "tls-server-end-point" or 529 ;; "tls-unique". 531 gs2-cbind-flag = ("p=" cb-name) / "n" / "y" 532 ;; "n" -> client doesn't support channel binding. 533 ;; "y" -> client does support channel binding 534 ;; but thinks the server does not. 535 ;; "p" -> client requires channel binding. 536 ;; The selected channel binding follows "p=". 538 gs2-header = gs2-cbind-flag "," 539 ;; GS2 header for SCRAM. 541 username = "n=" 1*(value-safe-char / "=2C" / "=3D") 542 ;; Conforms to . 543 ;; Usernames are prepared using SASLPrep. 545 reserved-mext = "m=" 1*(value-char) 546 ;; Reserved for signaling mandatory extensions. 547 ;; The exact syntax will be defined in 548 ;; the future. 550 channel-binding = "c=" base64 551 ;; base64 encoding of cbind-input. 553 proof = "p=" base64 555 nonce = "r=" c-nonce [s-nonce] 556 ;; Second part provided by server. 558 c-nonce = printable 560 s-nonce = printable 562 salt = "s=" base64 564 verifier = "v=" base64 565 ;; base-64 encoded ServerSignature. 567 iteration-count = "i=" posit-number 568 ;; A positive number. 570 client-first-message-bare = 571 [reserved-mext ","] 572 username "," nonce ["," extensions] 574 client-first-message = 575 "g=" gs2-header client-first-message-bare 577 server-first-message = 578 [reserved-mext ","] nonce "," salt "," 579 iteration-count ["," extensions] 581 client-final-message-without-proof = 582 channel-binding "," nonce ["," 583 extensions] 585 client-final-message = 586 client-final-message-without-proof "," proof 588 server-error = "e=" server-error-value 590 server-error-value = "invalid-encoding" / 591 "extensions-not-supported" / ; unrecognized 'm' value 592 "invalid-proof" / 593 "channel-bindings-dont-match" / 594 "server-does-support-channel-binding" / 595 ; server does not support channel binding 596 "channel-binding-not-supported" / 597 "unsupported-channel-binding-type" / 598 "unknown-user" / 599 "invalid-username-encoding" / 600 ; invalid username encoding (invalid UTF-8 or 601 ; SASLprep failed) 602 "no-resources" / 603 "other-error" / 604 server-error-value-ext 605 ; Unrecognized errors should be treated as "other-error". 606 ; In order to prevent information disclosure, the server 607 ; may substitute the real reason with "other-error". 609 server-error-value-ext = value 610 ; Additional error reasons added by extensions 611 ; to this document. 613 server-final-message = (server-error / verifier) 614 ["," extensions] 616 extensions = attr-val *("," attr-val) 617 ;; All extensions are optional, 618 ;; i.e., unrecognized attributes 619 ;; not defined in this document 620 ;; MUST be ignored. 622 cbind-data = 1*OCTET 624 cbind-input = gs2-header [ cbind-data ] 625 ;; cbind-data MUST be present for 626 ;; gs2-cbind-flag of "p" and MUST be absent 627 ;; for "y" or "n". 629 7. Security Considerations 631 If the authentication exchange is performed without a strong security 632 layer (such as TLS with data confidentiality), then a passive 633 eavesdropper can gain sufficient information to mount an offline 634 dictionary or brute-force attack which can be used to recover the 635 user's password. The amount of time necessary for this attack 636 depends on the cryptographic hash function selected, the strength of 637 the password and the iteration count supplied by the server. An 638 external security layer with strong encryption will prevent this 639 attack. 641 If the external security layer used to protect the SCRAM exchange 642 uses an anonymous key exchange, then the SCRAM channel binding 643 mechanism can be used to detect a man-in-the-middle attack on the 644 security layer and cause the authentication to fail as a result. 645 However, the man-in-the-middle attacker will have gained sufficient 646 information to mount an offline dictionary or brute-force attack. 647 For this reason, SCRAM allows to increase the iteration count over 648 time. (Note that a server that is only in posession of "StoredKey" 649 and "ServerKey" can't automatic increase the iteration count upon 650 successful authentication. Such increase would require resetting 651 user's password.) 653 If the authentication information is stolen from the authentication 654 database, then an offline dictionary or brute-force attack can be 655 used to recover the user's password. The use of salt mitigates this 656 attack somewhat by requiring a separate attack on each password. 657 Authentication mechanisms which protect against this attack are 658 available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is 659 an example of such technology. 661 If an attacker obtains the authentication information from the 662 authentication repository and either eavesdrops on one authentication 663 exchange or impersonates a server, the attacker gains the ability to 664 impersonate that user to all servers providing SCRAM access using the 665 same hash function, password, iteration count and salt. For this 666 reason, it is important to use randomly-generated salt values. 668 SCRAM does not negotiate a hash function to use. Hash function 669 negotiation is left to the HTTP authentication mechanism negotiation. 670 It is important that clients be able to sort a locally available list 671 of mechanisms by preference so that the client may pick the most 672 preferred of a server's advertised mechanism list. This preference 673 order is not specified here as it is a local matter. The preference 674 order should include objective and subjective notions of mechanism 675 cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be 676 preferred over SCRAM with SHA-1). 678 SCRAM does not protect against downgrade attacks of channel binding 679 types. The complexities of negotiation a channel binding type, and 680 handling down-grade attacks in that negotiation, was intentionally 681 left out of scope for this document. 683 A hostile server can perform a computational denial-of-service attack 684 on clients by sending a big iteration count value. 686 See [RFC4086] for more information about generating randomness. 688 8. IANA Considerations 690 "IETF Review" [RFC5226] registration procedure MUST be used for 691 registering new mechanisms in the SCRAM- family. The Kitten WG 692 mailing list (or a successor designated by the 693 responsible Security AD) MUST be used for soliciting reviews on such 694 registrations. 696 Note to future SCRAM- mechanism designers: each new SCRAM- HTTP 697 authentication mechanism MUST be explicitly registered with IANA and 698 MUST comply with SCRAM- mechanism naming convention defined in 699 Section 4 of this document. 701 IANA is requested to add the following entry to the Authentication 702 Scheme Registry defined in HTTP/1.1, Part 7 703 [I-D.ietf-httpbis-p7-auth]: 705 Authentication Scheme Name: SCRAM-SHA-1 706 Pointer to specification text: [[ this document ]] 707 Notes (optional): (none) 709 9. Acknowledgements 711 This document benefited from discussions on the SASL and Kitten WG 712 mailing lists. The authors would like to specially thank co-authors 713 of [RFC5802] from which lots of text was copied. 715 10. Design Motivations 717 The following design goals shaped this document. Note that some of 718 the goals have changed since the initial version of the document. 720 o The HTTP authentication mechanism has all modern features: support 721 for internationalized usernames and passwords, support for channel 722 bindings. 724 o The protocol supports mutual authentication. 726 o The authentication information stored in the authentication 727 database is not sufficient by itself to impersonate the client. 729 o The server does not gain the ability to impersonate the client to 730 other servers (with an exception for server-authorized proxies), 731 unless such other servers allow SCRAM authentication and use the 732 same salt and iteration count for the user. 734 o The mechanism is extensible, but [hopefully] not overengineered in 735 this respect. 737 o Easier to implement than HTTP Digest in both clients and servers. 739 11. Internet-Draft Change History 741 (RFC Editor: Please delete this section and all subsections.) 743 Changes since -00 745 o 747 12. References 749 12.1. Normative References 751 [I-D.ietf-httpbis-p7-auth] 752 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 753 7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in 754 progress), March 2012. 756 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 757 Hashing for Message Authentication", RFC 2104, 758 February 1997. 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 764 (SHA1)", RFC 3174, September 2001. 766 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 767 Internationalized Strings ("stringprep")", RFC 3454, 768 December 2002. 770 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 771 10646", STD 63, RFC 3629, November 2003. 773 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 774 and Passwords", RFC 4013, February 2005. 776 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 777 Encodings", RFC 4648, October 2006. 779 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 780 Channels", RFC 5056, November 2007. 782 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 783 Specifications: ABNF", STD 68, RFC 5234, January 2008. 785 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 786 for TLS", RFC 5929, July 2010. 788 12.2. Informative References 790 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 791 "Remote Authentication Dial In User Service (RADIUS)", 792 RFC 2865, June 2000. 794 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 795 Specification Version 2.0", RFC 2898, September 2000. 797 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 798 RFC 2945, September 2000. 800 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 801 Requirements for Security", BCP 106, RFC 4086, June 2005. 803 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 804 (LDAP): Technical Specification Road Map", RFC 4510, 805 June 2006. 807 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 808 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 810 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 811 RFC 4949, August 2007. 813 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 814 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 815 May 2008. 817 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 818 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 820 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 821 "Salted Challenge Response Authentication Mechanism 822 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 824 [RFC5803] Melnikov, A., "Lightweight Directory Access Protocol 825 (LDAP) Schema for Storing Salted Challenge Response 826 Authentication Mechanism (SCRAM) Secrets", RFC 5803, 827 July 2010. 829 [tls-server-end-point] 830 Zhu, L., "Registration of TLS server end-point channel 831 bindings", IANA http://www.iana.org/assignments/ 832 channel-binding-types/tls-server-end-point, July 2008. 834 Author's Address 836 Alexey Melnikov 837 Isode Ltd 839 Email: Alexey.Melnikov@isode.com