idnits 2.17.1 draft-ietf-httpauth-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 5 instances of too long lines in the document, the longest one being 12 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 01, 2013) is 3950 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: 'RFC5226' is defined on line 813, 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-22 ** 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 (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAUTH A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track July 01, 2013 5 Expires: January 02, 2014 7 Salted Challenge Response (SCRAM) HTTP Authentication Mechanism 8 draft-ietf-httpauth-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 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 January 02, 2014. 46 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5 68 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6 69 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 70 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 9 71 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 75 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 16 76 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 12. Internet-Draft Change History . . . . . . . . . . . . . . . . 16 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Conventions Used in This Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 Formal syntax is defined by [RFC5234] including the core rules 90 defined in Appendix B of [RFC5234]. 92 Example lines prefaced by "C:" are sent by the client and ones 93 prefaced by "S:" by the server. If a single "C:" or "S:" label 94 applies to multiple lines, then the line breaks between those lines 95 are for editorial clarity only, and are not part of the actual 96 protocol exchange. 98 1.1. Terminology 100 This document uses several terms defined in [RFC4949] ("Internet 101 Security Glossary") including the following: authentication, 102 authentication exchange, authentication information, brute force, 103 challenge-response, cryptographic hash function, dictionary attack, 104 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 105 one-way encryption function, password, replay attack and salt. 106 Readers not familiar with these terms should use that glossary as a 107 reference. 109 Some clarifications and additional definitions follow: 111 o Authentication information: Information used to verify an identity 112 claimed by a SCRAM client. The authentication information for a 113 SCRAM identity consists of salt, iteration count, the "StoredKey" 114 and "ServerKey" (as defined in the algorithm overview) for each 115 supported cryptographic hash function. 117 o Authentication database: The database used to look up the 118 authentication information associated with a particular identity. 119 For application protocols, LDAPv3 (see [RFC4510]) is frequently 120 used as the authentication database. For network-level protocols 121 such as PPP or 802.11x, the use of RADIUS [RFC2865] is more 122 common. 124 o Base64: An encoding mechanism defined in [RFC4648] which converts 125 an octet string input to a textual output string which can be 126 easily displayed to a human. The use of base64 in SCRAM is 127 restricted to the canonical form with no whitespace. 129 o Octet: An 8-bit byte. 131 o Octet string: A sequence of 8-bit bytes. 133 o Salt: A random octet string that is combined with a password 134 before applying a one-way encryption function. This value is used 135 to protect passwords that are stored in an authentication 136 database. 138 1.2. Notation 140 The pseudocode description of the algorithm uses the following 141 notations: 143 o ":=": The variable on the left hand side represents the octet 144 string resulting from the expression on the right hand side. 146 o "+": Octet string concatenation. 148 o "[ ]": A portion of an expression enclosed in "[" and "]" may not 149 be included in the result under some circumstances. See the 150 associated text for a description of those circumstances. 152 o Normalize(str): Apply the SASLPrep profile [RFC4013] of the 153 "stringprep" algorithm [RFC3454] as the normalization algorithm to 154 a UTF-8 [RFC3629] encoded "str". The resulting string is also in 155 UTF-8. When applying SASLPrep, "str" is treated as a "stored 156 strings", which means that unassigned Unicode codepoints are 157 prohibited (see Section 7 of [RFC3454]). Note that 158 implementations MUST either implement SASLPrep, or disallow use of 159 non US-ASCII Unicode codepoints in "str". 161 o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 162 [RFC2104]) using the octet string represented by "key" as the key 163 and the octet string "str" as the input string. The size of the 164 result is the hash result size for the hash function in use. For 165 example, it is 20 octets for SHA-1 (see [RFC3174]). 167 o H(str): Apply the cryptographic hash function to the octet string 168 "str", producing an octet string as a result. The size of the 169 result depends on the hash result size for the hash function in 170 use. 172 o XOR: Apply the exclusive-or operation to combine the octet string 173 on the left of this operator with the octet string on the right of 174 this operator. The length of the output and each of the two 175 inputs will be the same for this use. 177 o Hi(str, salt, i): 179 U1 := HMAC(str, salt + INT(1)) 180 U2 := HMAC(str, U1) 181 ... 182 Ui-1 := HMAC(str, Ui-2) 183 Ui := HMAC(str, Ui-1) 185 Hi := U1 XOR U2 XOR ... XOR Ui 187 where "i" is the iteration count, "+" is the string concatenation 188 operator and INT(g) is a four-octet encoding of the integer g, 189 most significant octet first. 191 Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 192 with dkLen == output length of HMAC() == output length of H(). 194 2. Introduction 196 This specification describes a family of authentication mechanisms 197 called the Salted Challenge Response Authentication Mechanism (SCRAM) 198 which addresses the requirements necessary to deploy a challenge- 199 response mechanism more widely than past attempts (see [RFC5802]). 200 When used in combination with Transport Layer Security (TLS, see 201 [RFC5246]) or an equivalent security layer, a mechanism from this 202 family could improve the status-quo for application protocol 203 authentication. 205 SCRAM provides the following protocol features: 207 o The authentication information stored in the authentication 208 database is not sufficient by itself (without a dictionary attack) 209 to impersonate the client. The information is salted to prevent a 210 pre-stored dictionary attack if the database is stolen. 212 o The server does not gain the ability to impersonate the client to 213 other servers (with an exception for server-authorized proxies). 215 o The mechanism permits the use of a server-authorized proxy without 216 requiring that proxy to have super-user rights with the back-end 217 server. 219 o Mutual authentication is supported, but only the client is named 220 (i.e., the server has no name). 222 3. SCRAM Algorithm Overview 224 The following is a description of a full HTTP SCRAM authentication 225 exchange. Note that this section omits some details, such as client 226 and server nonces. See Section 5 for more details. 228 To begin with, the SCRAM client is in possession of a username and 229 password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends 230 the username to the server, which retrieves the corresponding 231 authentication information, i.e. a salt, StoredKey, ServerKey and the 232 iteration count i. (Note that a server implementation may choose to 233 use the same iteration count for all accounts.) The server sends the 234 salt and the iteration count to the client, which then computes the 235 following values and sends a ClientProof to the server: 237 (*) - Note that both the username and the password MUST be encoded in 238 UTF-8 [RFC3629]. 240 Informative Note: Implementors are encouraged to create test cases 241 that use both username passwords with non-ASCII codepoints. In 242 particular, it's useful to test codepoints whose "Unicode 243 Normalization Form C" and "Unicode Normalization Form KC" are 244 different. Some examples of such codepoints include Vulgar Fraction 245 One Half (U+00BD) and Acute Accent (U+00B4). 247 SaltedPassword := Hi(Normalize(password), salt, i) 248 ClientKey := HMAC(SaltedPassword, "Client Key") 249 StoredKey := H(ClientKey) 250 AuthMessage := client-first-message-bare + "," + 251 server-first-message + "," + 252 client-final-message-without-proof 253 ClientSignature := HMAC(StoredKey, AuthMessage) 254 ClientProof := ClientKey XOR ClientSignature 255 ServerKey := HMAC(SaltedPassword, "Server Key") 256 ServerSignature := HMAC(ServerKey, AuthMessage) 258 The server authenticates the client by computing the ClientSignature, 259 exclusive-ORing that with the ClientProof to recover the ClientKey 260 and verifying the correctness of the ClientKey by applying the hash 261 function and comparing the result to the StoredKey. If the ClientKey 262 is correct, this proves that the client has access to the user's 263 password. 265 Similarly, the client authenticates the server by computing the 266 ServerSignature and comparing it to the value sent by the server. If 267 the two are equal, it proves that the server had access to the user's 268 ServerKey. 270 The AuthMessage is computed by concatenating messages from the 271 authentication exchange. The format of these messages is defined in 272 Section 6. 274 4. SCRAM Mechanism Names 276 A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" 277 followed by the uppercased name of the underlying hash function taken 278 from the IANA "Hash Function Textual Names" registry (see http:// 279 www.iana.org) . 281 For interoperability, all HTTP clients and servers supporting SCRAM 282 MUST implement the SCRAM-SHA-1 authentication mechanism, i.e. an 283 authentication mechanism from the SCRAM family that uses the SHA-1 284 hash function as defined in [RFC3174]. 286 5. SCRAM Authentication Exchange 288 SCRAM is a HTTP Authentication mechanism whose client response 289 () and server challenge () 290 messages are text-based messages containing one or more attribute- 291 value pairs separated by commas. Each attribute has a one-letter 292 name, with the exception of a couple of attributes which are generic 293 to HTTP authentication, such as "realm" (and "sid"). The messages 294 and their attributes are described in Section 5.1, and defined in 295 Section 6. 297 challenge-scram = "SCRAM-SHA-1" 1*SP 1#auth-param 298 ; Complies with ABNF from I-D.ietf-httpbis-p7-auth. 299 ; Included in the WWW-Authenticate header field. 301 credentials-scram = "SCRAM-SHA-1" 1*SP 1#auth-param 302 ; Complies with from I-D.ietf-httpbis-p7-auth 303 ; Included in the Authorization header field. 305 This is a simple example of a SCRAM-SHA-1 authentication exchange 306 when the client doesn't support channel bindings (username 'user' and 307 password 'pencil' are used): 309 [...The server might have returned 401 Unauthorized first...] 311 C: GET /resource HTTP/1.1 312 C: Host: server.example.com 313 C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", 314 g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL 315 C: [...] 317 S: HTTP/1.1 401 Unauthorized 318 S: WWW-Authenticate: SCRAM-SHA-1 319 realm="testrealm@host.com",sid=AAAABBBBCCCCDDDD, 320 r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92, 321 i=4096 322 S: [...] 324 C: GET /resource HTTP/1.1 325 C: Host: server.example.com 326 C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, 327 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 328 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 329 C: [...] 330 S: HTTP/1.1 200 Ok 331 S: Authentication-Info: SCRAM-SHA-1 332 sid=AAAABBBBCCCCDDDD, 333 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 334 S: [...Other header fields and resource body...] 336 "SCRAM-SHA-1" authentication starts with sending the "Authorization" 337 request header field defined by HTTP/1.1, Part 7 338 [I-D.ietf-httpbis-p7-auth] containing "SCRAM-SHA-1" authentication 339 scheme and the following attributes: 341 o A "realm" attribute MAY be included to indicate the scope of 342 protection in the manner described in HTTP/1.1, Part 7 343 [I-D.ietf-httpbis-p7-auth]. As specified in 344 [I-D.ietf-httpbis-p7-auth], the "realm" attribute MUST NOT appear 345 more than once. 347 o The client also includes the "client-first-message" containing: 349 * a header ("g" attribute) consisting of a flag indicating 350 whether channel binding is supported-but-not-used, not 351 supported, or used ; 353 * SCRAM username and a random, unique nonce attributes. 355 Note that the client's first message will always start with "n", 356 "y" or "p", otherwise the message is invalid and authentication 357 MUST fail. 359 In HTTP response, the server sends WWW-Authenticate header field 360 containing: a unique session identifier (the "sid" attribute) plus 361 the "server-first-message" containing the user's iteration count i, 362 the user's salt, and the nonce with a concatenation of the client- 363 specified one with a server nonce. 365 The client then responds with another HTTP request with the 366 Authorization header field, which includes the "sid" attribute 367 received in the previous server response, together with "client- 368 final-message" data. The latter has the same nonce and a ClientProof 369 computed using the selected hash function (SHA-1) as explained 370 earlier. 372 The server verifies the nonce and the proof, and, finally, it 373 responds with a 200 HTTP response with the Authentication-Info header 374 field containing "server-final-message", concluding the 375 authentication exchange. 377 The client then authenticates the server by computing the 378 ServerSignature and comparing it to the value sent by the server. If 379 the two are different, the client MUST consider the authentication 380 exchange to be unsuccessful and it might have to drop the connection. 382 5.1. SCRAM Attributes 384 This section describes the permissible attributes, their use, and the 385 format of their values. All attribute names are single US-ASCII 386 letters and are case-sensitive. 388 Note that the order of attributes in client or server messages is 389 fixed, with the exception of extension attributes (described by the 390 "extensions" ABNF production), which can appear in any order in the 391 designated positions. See the ABNF section for authoritative 392 reference. 394 o g: This attribute value consist of a flag indicating whether 395 channel binding is supported-but-not-used, not supported, or used 396 . 398 o n: This attribute specifies the name of the user whose password is 399 used for authentication. A client MUST include it in its first 400 message to the server. 402 Before sending the username to the server, the client SHOULD 403 prepare the username using the "SASLPrep" profile [RFC4013] of 404 the "stringprep" algorithm [RFC3454] treating it as a query 405 string (i.e., unassigned Unicode code points are allowed). If 406 the preparation of the username fails or results in an empty 407 string, the client SHOULD abort the authentication exchange 408 (*). 410 (*) An interactive client can request a repeated entry of the 411 username value. 413 Upon receipt of the username by the server, the server MUST 414 either prepare it using the "SASLPrep" profile [RFC4013] of the 415 "stringprep" algorithm [RFC3454] treating it as a query string 416 (i.e., unassigned Unicode codepoints are allowed) or otherwise 417 be prepared to do SASLprep-aware string comparisons and/or 418 index lookups. If the preparation of the username fails or 419 results in an empty string, the server SHOULD abort the 420 authentication exchange. Whether or not the server prepares 421 the username using "SASLPrep", it MUST use it as received in 422 hash calculations. 424 The characters ',' or '=' in usernames are sent as '=2C' and 425 '=3D' respectively. If the server receives a username which 426 contains '=' not followed by either '2C' or '3D', then the 427 server MUST fail the authentication. 429 o m: This attribute is reserved for future extensibility. In this 430 version of SCRAM, its presence in a client or a server message 431 MUST cause authentication failure when the attribute is parsed by 432 the other end. 434 o r: This attribute specifies a sequence of random printable ASCII 435 characters excluding ',' which forms the nonce used as input to 436 the hash function. No quoting is applied to this string. As 437 described earlier, the client supplies an initial value in its 438 first message, and the server augments that value with its own 439 nonce in its first response. It is important that this value be 440 different for each authentication (see [RFC4086] for more details 441 on how to achieve this). The client MUST verify that the initial 442 part of the nonce used in subsequent messages is the same as the 443 nonce it initially specified. The server MUST verify that the 444 nonce sent by the client in the second message is the same as the 445 one sent by the server in its first message. 447 o c: This REQUIRED attribute specifies the base64-encoded GS2 header 448 and channel-binding data. It is sent by the client in its second 449 authentication message. The attribute data consist of: 451 * the GS2 header from the client's first message (recall that the 452 GS2 header contains a channel binding flag ). This header is 453 going to include channel binding type prefix (see [RFC5056]), 454 if and only if the client is using channel binding; 456 * followed by the external channel's channel binding data, if and 457 only if the client is using channel binding. 459 o s: This attribute specifies the base64-encoded salt used by the 460 server for this user. It is sent by the server in its first 461 message to the client. 463 o i: This attribute specifies an iteration count for the selected 464 hash function and user, and MUST be sent by the server along with 465 the user's salt. 467 For SCRAM-SHA-1 authentication mechanism servers SHOULD 468 announce a hash iteration-count of at least 4096. Note that a 469 client implementation MAY cache ClientKey&ServerKey (or just 470 SaltedPassword) for later reauthentication to the same service, 471 as it is likely that the server is going to advertise the same 472 salt value upon reauthentication. This might be useful for 473 mobile clients where CPU usage is a concern. 475 o p: This attribute specifies a base64-encoded ClientProof. The 476 client computes this value as described in the overview and sends 477 it to the server. 479 o v: This attribute specifies a base64-encoded ServerSignature. It 480 is sent by the server in its final message, and is used by the 481 client to verify that the server has access to the user's 482 authentication information. This value is computed as explained 483 in the overview. 485 6. Formal Syntax 487 The following syntax specification uses the Augmented Backus-Naur 488 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 489 and "UTF8-4" non-terminal are defined in [RFC3629]. 491 ALPHA = 492 DIGIT = 493 UTF8-2 = 494 UTF8-3 = 495 UTF8-4 = 497 attr-val = ALPHA "=" value 498 ;; Generic syntax of any attribute sent 499 ;; by server or client 501 value = 1*value-char 503 value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / 504 UTF8-2 / UTF8-3 / UTF8-4 505 ;; UTF8-char except NUL, "=", and ",". 507 value-char = value-safe-char / "=" 509 printable = %x21-2B / %x2D-7E 510 ;; Printable ASCII except ",". 511 ;; Note that any "printable" is also 512 ;; a valid "value". 514 base64-char = ALPHA / DIGIT / "/" / "+" 516 base64-4 = 4base64-char 518 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 New mechanisms in the SCRAM- family are registered according to the 691 IANA procedure specified in [RFC5802]. 693 Note to future SCRAM- mechanism designers: each new SCRAM- HTTP 694 authentication mechanism MUST be explicitly registered with IANA and 695 MUST comply with SCRAM- mechanism naming convention defined in 696 Section 4 of this document. 698 IANA is requested to add the following entry to the Authentication 699 Scheme Registry defined in HTTP/1.1, Part 7 700 [I-D.ietf-httpbis-p7-auth]: 702 Authentication Scheme Name: SCRAM-SHA-1 703 Pointer to specification text: [[ this document ]] 704 Notes (optional): (none) 706 9. Acknowledgements 707 This document benefited from discussions on the SASL and Kitten WG 708 mailing lists. The authors would like to specially thank co-authors 709 of [RFC5802] from which lots of text was copied. 711 10. Design Motivations 713 The following design goals shaped this document. Note that some of 714 the goals have changed since the initial version of the document. 716 o The HTTP authentication mechanism has all modern features: support 717 for internationalized usernames and passwords, support for channel 718 bindings. 720 o The protocol supports mutual authentication. 722 o The authentication information stored in the authentication 723 database is not sufficient by itself to impersonate the client. 725 o The server does not gain the ability to impersonate the client to 726 other servers (with an exception for server-authorized proxies), 727 unless such other servers allow SCRAM authentication and use the 728 same salt and iteration count for the user. 730 o The mechanism is extensible, but [hopefully] not overengineered in 731 this respect. 733 o Easier to implement than HTTP Digest in both clients and servers. 735 11. Open Issues 737 It should be possible to construct a quick reauthentication version 738 of the mechanism that uses fewer round-trips (similar to what Digest 739 has). 741 12. Internet-Draft Change History 743 (RFC Editor: Please delete this section and all subsections.) 745 Changes since -00 747 13. References 749 13.1. Normative References 751 [I-D.ietf-httpbis-p7-auth] 752 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 753 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22 754 (work in progress), March 2012. 756 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 757 Hashing for Message Authentication", RFC 2104, February 758 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 13.2. Informative References 790 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 791 "Remote Authentication Dial In User Service (RADIUS)", RFC 792 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, June 805 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", RFC 811 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, July 827 2010. 829 [tls-server-end-point] 830 Zhu, L., ., "Registration of TLS server end-point channel 831 bindings", IANA http://www.iana.org/assignments/channel- 832 binding-types/tls-server-end-point, July 2008. 834 Author's Address 836 Alexey Melnikov 837 Isode Ltd 839 Email: Alexey.Melnikov@isode.com