idnits 2.17.1 draft-ietf-httpauth-scram-auth-04.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 4 instances of too long lines in the document, the longest one being 7 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 (November 10, 2014) is 3456 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 877, but no explicit reference was found in the text == Unused Reference: 'RFC4616' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 908, but no explicit reference was found in the text == Unused Reference: 'RFC5803' is defined on line 919, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- 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: 6 errors (**), 0 flaws (~~), 5 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 November 10, 2014 5 Expires: May 14, 2015 7 Salted Challenge Response (SCRAM) HTTP Authentication Mechanism 8 draft-ietf-httpauth-scram-auth-04.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 May 14, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6 68 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7 69 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 70 5.1. One round trip reauthentication . . . . . . . . . . . . . . 10 71 5.2. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 11 72 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 76 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 19 77 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 12. Internet-Draft Change History . . . . . . . . . . . . . . . . 19 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 81 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 84 1. Conventions Used in This Document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 Formal syntax is defined by [RFC5234] including the core rules 91 defined in Appendix B of [RFC5234]. 93 Example lines prefaced by "C:" are sent by the client and ones 94 prefaced by "S:" by the server. If a single "C:" or "S:" label 95 applies to multiple lines, then the line breaks between those lines 96 are for editorial clarity only, and are not part of the actual 97 protocol exchange. 99 1.1. Terminology 101 This document uses several terms defined in [RFC4949] ("Internet 102 Security Glossary") including the following: authentication, 103 authentication exchange, authentication information, brute force, 104 challenge-response, cryptographic hash function, dictionary attack, 105 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 106 one-way encryption function, password, replay attack and salt. 107 Readers not familiar with these terms should use that glossary as a 108 reference. 110 Some clarifications and additional definitions follow: 112 o Authentication information: Information used to verify an identity 113 claimed by a SCRAM client. The authentication information for a 114 SCRAM identity consists of salt, iteration count, the "StoredKey" 115 and "ServerKey" (as defined in the algorithm overview) for each 116 supported cryptographic hash function. 118 o Authentication database: The database used to look up the 119 authentication information associated with a particular identity. 120 For application protocols, LDAPv3 (see [RFC4510]) is frequently 121 used as the authentication database. For network-level protocols 122 such as PPP or 802.11x, the use of RADIUS [RFC2865] is more 123 common. 125 o Base64: An encoding mechanism defined in [RFC4648] which converts 126 an octet string input to a textual output string which can be 127 easily displayed to a human. The use of base64 in SCRAM is 128 restricted to the canonical form with no whitespace. 130 o Octet: An 8-bit byte. 132 o Octet string: A sequence of 8-bit bytes. 134 o Salt: A random octet string that is combined with a password 135 before applying a one-way encryption function. This value is used 136 to protect passwords that are stored in an authentication 137 database. 139 1.2. Notation 141 The pseudocode description of the algorithm uses the following 142 notations: 144 o ":=": The variable on the left hand side represents the octet 145 string resulting from the expression on the right hand side. 147 o "+": Octet string concatenation. 149 o "[ ]": A portion of an expression enclosed in "[" and "]" may not 150 be included in the result under some circumstances. See the 151 associated text for a description of those circumstances. 153 o Normalize(str): Apply the SASLPrep profile [RFC4013] of the 154 "stringprep" algorithm [RFC3454] as the normalization algorithm to 155 a UTF-8 [RFC3629] encoded "str". The resulting string is also in 156 UTF-8. When applying SASLPrep, "str" is treated as a "stored 157 strings", which means that unassigned Unicode codepoints are 158 prohibited (see Section 7 of [RFC3454]). Note that 159 implementations MUST either implement SASLPrep, or disallow use of 160 non US-ASCII Unicode codepoints in "str". 162 o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 163 [RFC2104]) using the octet string represented by "key" as the key 164 and the octet string "str" as the input string. The size of the 165 result is the hash result size for the hash function in use. For 166 example, it is 20 octets for SHA-1 (see [RFC3174]). 168 o H(str): Apply the cryptographic hash function to the octet string 169 "str", producing an octet string as a result. The size of the 170 result depends on the hash result size for the hash function in 171 use. 173 o XOR: Apply the exclusive-or operation to combine the octet string 174 on the left of this operator with the octet string on the right of 175 this operator. The length of the output and each of the two 176 inputs will be the same for this use. 178 o Hi(str, salt, i): 180 U1 := HMAC(str, salt + INT(1)) 181 U2 := HMAC(str, U1) 182 ... 183 Ui-1 := HMAC(str, Ui-2) 184 Ui := HMAC(str, Ui-1) 186 Hi := U1 XOR U2 XOR ... XOR Ui 188 where "i" is the iteration count, "+" is the string concatenation 189 operator and INT(g) is a four-octet encoding of the integer g, 190 most significant octet first. 192 Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 193 with dkLen == output length of HMAC() == output length of H(). 195 2. Introduction 197 This specification describes a family of authentication mechanisms 198 called the Salted Challenge Response Authentication Mechanism (SCRAM) 199 which addresses the requirements necessary to deploy a challenge- 200 response mechanism more widely than past attempts (see [RFC5802]). 201 When used in combination with Transport Layer Security (TLS, see 202 [RFC5246]) or an equivalent security layer, a mechanism from this 203 family could improve the status-quo for application protocol 204 authentication. 206 SCRAM provides the following protocol features: 208 o The authentication information stored in the authentication 209 database is not sufficient by itself (without a dictionary attack) 210 to impersonate the client. The information is salted to prevent a 211 pre-stored dictionary attack if the database is stolen. 213 o The server does not gain the ability to impersonate the client to 214 other servers (with an exception for server-authorized proxies). 216 o The mechanism permits the use of a server-authorized proxy without 217 requiring that proxy to have super-user rights with the back-end 218 server. 220 o Mutual authentication is supported, but only the client is named 221 (i.e., the server has no name). 223 3. SCRAM Algorithm Overview 225 The following is a description of a full HTTP SCRAM authentication 226 exchange. Note that this section omits some details, such as client 227 and server nonces. See Section 5 for more details. 229 To begin with, the SCRAM client is in possession of a username and 230 password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends 231 the username to the server, which retrieves the corresponding 232 authentication information, i.e. a salt, StoredKey, ServerKey and the 233 iteration count i. (Note that a server implementation may choose to 234 use the same iteration count for all accounts.) The server sends the 235 salt and the iteration count to the client, which then computes the 236 following values and sends a ClientProof to the server: 238 (*) - Note that both the username and the password MUST be encoded in 239 UTF-8 [RFC3629]. 241 Informative Note: Implementors are encouraged to create test cases 242 that use both username passwords with non-ASCII codepoints. In 243 particular, it's useful to test codepoints whose "Unicode 244 Normalization Form C" and "Unicode Normalization Form KC" are 245 different. Some examples of such codepoints include Vulgar Fraction 246 One Half (U+00BD) and Acute Accent (U+00B4). 248 SaltedPassword := Hi(Normalize(password), salt, i) 249 ClientKey := HMAC(SaltedPassword, "Client Key") 250 StoredKey := H(ClientKey) 251 AuthMessage := client-first-message-bare + "," + 252 server-first-message + "," + 253 client-final-message-without-proof 254 ClientSignature := HMAC(StoredKey, AuthMessage) 255 ClientProof := ClientKey XOR ClientSignature 256 ServerKey := HMAC(SaltedPassword, "Server Key") 257 ServerSignature := HMAC(ServerKey, AuthMessage) 259 The server authenticates the client by computing the ClientSignature, 260 exclusive-ORing that with the ClientProof to recover the ClientKey 261 and verifying the correctness of the ClientKey by applying the hash 262 function and comparing the result to the StoredKey. If the ClientKey 263 is correct, this proves that the client has access to the user's 264 password. 266 Similarly, the client authenticates the server by computing the 267 ServerSignature and comparing it to the value sent by the server. If 268 the two are equal, it proves that the server had access to the user's 269 ServerKey. 271 The AuthMessage is computed by concatenating messages from the 272 authentication exchange. The format of these messages is defined in 273 Section 6. 275 4. SCRAM Mechanism Names 277 A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" 278 followed by the uppercased name of the underlying hash function taken 279 from the IANA "Hash Function Textual Names" registry (see 280 http://www.iana.org) . 282 For interoperability, all HTTP clients and servers supporting SCRAM 283 MUST implement the SCRAM-SHA-1 authentication mechanism, [[CREF1: 284 OPEN ISSUE: Possibly switch to SHA-256 as the mandatory-to- 285 implement.]] i.e. an authentication mechanism from the SCRAM family 286 that uses the SHA-1 hash function as defined in [RFC3174]. 288 5. SCRAM Authentication Exchange 290 SCRAM is a HTTP Authentication mechanism whose client response 291 () and server challenge () 292 messages are text-based messages containing one or more attribute- 293 value pairs separated by commas. Each attribute has a one-letter 294 name, with the exception of a couple of attributes which are generic 295 to HTTP authentication, such as "realm" (and "sid"). The messages 296 and their attributes are described in Section 5.2, and defined in 297 Section 6. 299 challenge-scram = scram-name [1*SP 1#auth-param] 300 ; Complies with ABNF from RFC 7235. 301 ; Included in the WWW-Authenticate header field. 303 credentials-scram = scram-name [1*SP 1#auth-param] 304 ; Complies with from RFC 7235. 305 ; Included in the Authorization header field. 307 scram-name = "SCRAM-SHA-1" / other-scram-name 308 ; SCRAM-SHA-1 is registered by this RFC 309 other-scram-name = "SCRAM-" hash-name 310 ; hash-name is a capitalized form of names from IANA 311 ; "Hash Function Textual Names" registry. 312 ; Additional SCRAM names must be registered in both 313 ; the IANA "SASL mechanisms" registry 314 ; and the IANA "authentication scheme" registry. 316 This is a simple example of a SCRAM-SHA-1 authentication exchange 317 when the client doesn't support channel bindings (username 'user' and 318 password 'pencil' are used): 320 C: GET /resource HTTP/1.1 321 C: Host: server.example.com 322 C: [...] 324 S: HTTP/1.1 401 Unauthorized 325 S: WWW-Authenticate: Digest realm="realm1@host.com", 326 Digest realm="realm2@host.com", 327 Digest realm="realm3@host.com", 328 SCRAM-SHA-1 realm="realm3@host.com", 329 SCRAM-SHA-1 realm="testrealm@host.com" 330 S: [...] 332 C: GET /resource HTTP/1.1 333 C: Host: server.example.com 334 C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", 335 g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL 336 C: [...] 338 S: HTTP/1.1 401 Unauthorized 339 S: WWW-Authenticate: SCRAM-SHA-1 340 sid=AAAABBBBCCCCDDDD,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 341 s=QSXCR+Q6sek8bf92,i=4096 342 S: [...] 344 C: GET /resource HTTP/1.1 345 C: Host: server.example.com 346 C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, 347 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 348 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 349 C: [...] 351 S: HTTP/1.1 200 Ok 352 S: Authentication-Info: SCRAM-SHA-1 353 sid=AAAABBBBCCCCDDDD, 354 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 355 S: [...Other header fields and resource body...] 357 Note that in the example above the client can also initiate SCRAM 358 authentication without first being prompted by the server. 360 Initial "SCRAM-SHA-1" authentication starts with sending the 361 "Authorization" request header field defined by HTTP/1.1, Part 7 363 [RFC7235] containing "SCRAM-SHA-1" authentication scheme and the 364 following attributes: 366 o A "realm" attribute MAY be included to indicate the scope of 367 protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. 368 As specified in [RFC7235], the "realm" attribute MUST NOT appear 369 more than once. The realm attribute only appears in the first 370 SCRAM message to the server and in the first SCRAM response from 371 the server. 373 o The client also includes the "client-first-message" containing: 375 * a header ("g" attribute) consisting of a flag indicating 376 whether channel binding is supported-but-not-used, not 377 supported, or used . Note that the "g" attribute always starts 378 with "n", "y" or "p", otherwise the message is invalid and 379 authentication MUST fail. 381 * SCRAM username and a random, unique nonce attributes. 383 In HTTP response, the server sends WWW-Authenticate header field 384 containing: a unique session identifier (the "sid" attribute) plus 385 the "server-first-message" containing the user's iteration count i, 386 the user's salt, and the nonce with a concatenation of the client- 387 specified one with a server nonce. [[CREF2: OPEN ISSUE: 388 Alternatively, the "sid" attribute can be another header field.]] 390 The client then responds with another HTTP request with the 391 Authorization header field, which includes the "sid" attribute 392 received in the previous server response, together with "client- 393 final-message" data. The latter has the same nonce and a ClientProof 394 computed using the selected hash function (SHA-1) as explained 395 earlier. 397 The server verifies the nonce and the proof, and, finally, it 398 responds with a 200 HTTP response with the Authentication-Info header 399 field containing "server-final-message", concluding the 400 authentication exchange. 402 The client then authenticates the server by computing the 403 ServerSignature and comparing it to the value sent by the server. If 404 the two are different, the client MUST consider the authentication 405 exchange to be unsuccessful and it might have to drop the connection. 407 5.1. One round trip reauthentication 409 If the server supports SCRAM reauthentication, the server sends in 410 its initial HTTP response a WWW-Authenticate header field containing: 411 the "realm" attribute (as defined earlier), the "sr" attribute that 412 contains the server part of the "r" attribute (see Section 5.2 and 413 optional "ttl" attribute (which contains the "sr" value validity in 414 seconds). 416 If the client has authenticated to the same realm before (i.e. it 417 remembers "i" and "s" attributes for a user from earlies 418 authentication exchanges with the server), it can respond to that 419 with "client-final-message". 421 If the server considers the server part of the nonce (the "r" 422 attribute) to be still valid, it will provide access to the requested 423 resource (assuming the client hash verifies correctly, of course). 424 However if the server considers that the server part of the nonce is 425 stale (for example if the "sr" value is used after the "ttl" 426 seconds), the server returns "401 Unauthorized" containing the SCRAM 427 mechanism name with a new "sr" and optional "ttl" attributes. 429 Reauthentication can look like this: 431 C: GET /resource HTTP/1.1 432 C: Host: server.example.com 433 C: [...] 435 S: HTTP/1.1 401 Unauthorized 436 S: WWW-Authenticate: Digest realm="realm1@host.com", 437 Digest realm="realm2@host.com", 438 Digest realm="realm3@host.com", 439 SCRAM-SHA-1 realm="realm3@host.com", 440 SCRAM-SHA-1 realm="testrealm@host.com", sr=3rfcNHYJY1ZVvWVs7j 441 SCRAM-SHA-1 realm="testrealm2@host.com", sr=AAABBBCCCDDD, ttl=120 442 S: [...] 444 [Client authenticates as usual to realm "testrealm@host.com"] 446 [Some time later client decides to reauthenticate. 447 It will use the cached "i" and "s" from earlies exchanges. 448 It will use the server advertised "sr" value as the server part of the "r". 449 Should some counter be added to make "sr" unique for each reauth???] 451 C: GET /resource HTTP/1.1 452 C: Host: server.example.com 453 C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", 454 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 455 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 456 C: [...] 458 S: HTTP/1.1 200 Ok 459 S: Authentication-Info: SCRAM-SHA-1 460 sid=AAAABBBBCCCCDDDD, 461 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 462 S: [...Other header fields and resource body...] 464 5.2. SCRAM Attributes 466 This section describes the permissible attributes, their use, and the 467 format of their values. All attribute names are single US-ASCII 468 letters and are case-sensitive. 470 Note that the order of attributes in client or server messages is 471 fixed, with the exception of extension attributes (described by the 472 "extensions" ABNF production), which can appear in any order in the 473 designated positions. See the ABNF section for authoritative 474 reference. 476 o g: This attribute value consist of a flag indicating whether 477 channel binding is supported-but-not-used, not supported, or used 478 . 480 o n: This attribute specifies the name of the user whose password is 481 used for authentication. A client MUST include it in its first 482 message to the server. 484 Before sending the username to the server, the client SHOULD 485 prepare the username using the "SASLPrep" profile [RFC4013] of 486 the "stringprep" algorithm [RFC3454] treating it as a query 487 string (i.e., unassigned Unicode code points are allowed). If 488 the preparation of the username fails or results in an empty 489 string, the client SHOULD abort the authentication exchange 490 (*). 492 (*) An interactive client can request a repeated entry of the 493 username value. 495 Upon receipt of the username by the server, the server MUST 496 either prepare it using the "SASLPrep" profile [RFC4013] of the 497 "stringprep" algorithm [RFC3454] treating it as a query string 498 (i.e., unassigned Unicode codepoints are allowed) or otherwise 499 be prepared to do SASLprep-aware string comparisons and/or 500 index lookups. If the preparation of the username fails or 501 results in an empty string, the server SHOULD abort the 502 authentication exchange. Whether or not the server prepares 503 the username using "SASLPrep", it MUST use it as received in 504 hash calculations. 506 The characters ',' or '=' in usernames are sent as '=2C' and 507 '=3D' respectively. If the server receives a username which 508 contains '=' not followed by either '2C' or '3D', then the 509 server MUST fail the authentication. 511 o m: This attribute is reserved for future extensibility. In this 512 version of SCRAM, its presence in a client or a server message 513 MUST cause authentication failure when the attribute is parsed by 514 the other end. 516 o r: This attribute specifies a sequence of random printable ASCII 517 characters excluding ',' which forms the nonce used as input to 518 the hash function. No quoting is applied to this string. As 519 described earlier, the client supplies an initial value in its 520 first message, and the server augments that value with its own 521 nonce in its first response. It is important that this value be 522 different for each authentication (see [RFC4086] for more details 523 on how to achieve this). The client MUST verify that the initial 524 part of the nonce used in subsequent messages is the same as the 525 nonce it initially specified. The server MUST verify that the 526 nonce sent by the client in the second message is the same as the 527 one sent by the server in its first message. 529 o sr: Server component of the nonce (the "r" attribute) when used 530 for re-authentication. 532 o c: This REQUIRED attribute specifies the base64-encoded GS2 header 533 and channel-binding data. It is sent by the client in its second 534 authentication message. The attribute data consist of: 536 * the GS2 header from the client's first message (recall that the 537 GS2 header contains a channel binding flag ). This header is 538 going to include channel binding type prefix (see [RFC5056]), 539 if and only if the client is using channel binding; 541 * followed by the external channel's channel binding data, if and 542 only if the client is using channel binding. 544 o s: This attribute specifies the base64-encoded salt used by the 545 server for this user. It is sent by the server in its first 546 message to the client. 548 o i: This attribute specifies an iteration count for the selected 549 hash function and user, and MUST be sent by the server along with 550 the user's salt. 552 For SCRAM-SHA-1 authentication mechanism servers SHOULD 553 announce a hash iteration-count of at least 4096. Note that a 554 client implementation MAY cache ClientKey&ServerKey (or just 555 SaltedPassword) for later reauthentication to the same service, 556 as it is likely that the server is going to advertise the same 557 salt value upon reauthentication. This might be useful for 558 mobile clients where CPU usage is a concern. 560 o p: This attribute specifies a base64-encoded ClientProof. The 561 client computes this value as described in the overview and sends 562 it to the server. 564 o v: This attribute specifies a base64-encoded ServerSignature. It 565 is sent by the server in its final message, and is used by the 566 client to verify that the server has access to the user's 567 authentication information. This value is computed as explained 568 in the overview. 570 6. Formal Syntax 572 The following syntax specification uses the Augmented Backus-Naur 573 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 574 and "UTF8-4" non-terminal are defined in [RFC3629]. 576 ALPHA = 577 DIGIT = 578 UTF8-2 = 579 UTF8-3 = 580 UTF8-4 = 582 attr-val = ALPHA "=" value 583 ;; Generic syntax of any attribute sent 584 ;; by server or client 586 value = 1*value-char 588 value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / 589 UTF8-2 / UTF8-3 / UTF8-4 590 ;; UTF8-char except NUL, "=", and ",". 592 value-char = value-safe-char / "=" 594 printable = %x21-2B / %x2D-7E 595 ;; Printable ASCII except ",". 596 ;; Note that any "printable" is also 597 ;; a valid "value". 599 base64-char = ALPHA / DIGIT / "/" / "+" 601 base64-4 = 4base64-char 603 base64-3 = 3base64-char "=" 605 base64-2 = 2base64-char "==" 607 base64 = *base64-4 [base64-3 / base64-2] 609 posit-number = %x31-39 *DIGIT 610 ;; A positive number. 612 cb-name = 1*(ALPHA / DIGIT / "." / "-") 613 ;; See RFC 5056, Section 7. 614 ;; E.g., "tls-server-end-point" or 615 ;; "tls-unique". 617 gs2-cbind-flag = ("p=" cb-name) / "n" / "y" 618 ;; "n" -> client doesn't support channel binding. 619 ;; "y" -> client does support channel binding 620 ;; but thinks the server does not. 621 ;; "p" -> client requires channel binding. 622 ;; The selected channel binding follows "p=". 624 gs2-header = gs2-cbind-flag "," 625 ;; GS2 header for SCRAM. 627 username = "n=" 1*(value-safe-char / "=2C" / "=3D") 628 ;; Conforms to . 629 ;; Usernames are prepared using SASLPrep. 631 reserved-mext = "m=" 1*(value-char) 632 ;; Reserved for signaling mandatory extensions. 633 ;; The exact syntax will be defined in 634 ;; the future. 636 channel-binding = "c=" base64 637 ;; base64 encoding of cbind-input. 639 proof = "p=" base64 641 nonce = "r=" c-nonce [s-nonce] 642 ;; Second part provided by server. 644 c-nonce = printable 646 s-nonce = printable 648 salt = "s=" base64 650 verifier = "v=" base64 651 ;; base-64 encoded ServerSignature. 653 iteration-count = "i=" posit-number 654 ;; A positive number. 656 client-first-message-bare = 657 [reserved-mext ","] 658 username "," nonce ["," extensions] 660 client-first-message = 661 "g=" gs2-header client-first-message-bare 662 ;; Note that this doesn't include "realm" and 663 ;; other generic HTTP directives. 665 server-first-message = 666 [reserved-mext ","] nonce "," salt "," 667 iteration-count ["," extensions] 668 ;; Note that this doesn't include "realm", "sid" and 669 ;; other generic HTTP directives. 671 client-final-message-without-proof = 672 channel-binding "," nonce ["," 673 extensions] 675 client-final-message = 676 client-final-message-without-proof "," proof 677 ;; Note that this doesn't include "sid" and 678 ;; other generic HTTP directives. 680 server-error = "e=" server-error-value 682 server-error-value = "invalid-encoding" / 683 "extensions-not-supported" / ; unrecognized 'm' value 684 "invalid-proof" / 685 "channel-bindings-dont-match" / 686 "server-does-support-channel-binding" / 687 ; server does not support channel binding 688 "channel-binding-not-supported" / 689 "unsupported-channel-binding-type" / 690 "unknown-user" / 691 "invalid-username-encoding" / 692 ; invalid username encoding (invalid UTF-8 or 693 ; SASLprep failed) 694 "no-resources" / 695 "other-error" / 696 server-error-value-ext 697 ; Unrecognized errors should be treated as "other-error". 698 ; In order to prevent information disclosure, the server 699 ; may substitute the real reason with "other-error". 701 server-error-value-ext = value 702 ; Additional error reasons added by extensions 703 ; to this document. 705 server-final-message = (server-error / verifier) 706 ["," extensions] 708 extensions = attr-val *("," attr-val) 709 ;; All extensions are optional, 710 ;; i.e., unrecognized attributes 711 ;; not defined in this document 712 ;; MUST be ignored. 714 cbind-data = 1*OCTET 716 cbind-input = gs2-header [ cbind-data ] 717 ;; cbind-data MUST be present for 718 ;; gs2-cbind-flag of "p" and MUST be absent 719 ;; for "y" or "n". 721 7. Security Considerations 723 If the authentication exchange is performed without a strong security 724 layer (such as TLS with data confidentiality), then a passive 725 eavesdropper can gain sufficient information to mount an offline 726 dictionary or brute-force attack which can be used to recover the 727 user's password. The amount of time necessary for this attack 728 depends on the cryptographic hash function selected, the strength of 729 the password and the iteration count supplied by the server. An 730 external security layer with strong encryption will prevent this 731 attack. 733 If the external security layer used to protect the SCRAM exchange 734 uses an anonymous key exchange, then the SCRAM channel binding 735 mechanism can be used to detect a man-in-the-middle attack on the 736 security layer and cause the authentication to fail as a result. 737 However, the man-in-the-middle attacker will have gained sufficient 738 information to mount an offline dictionary or brute-force attack. 739 For this reason, SCRAM allows to increase the iteration count over 740 time. (Note that a server that is only in posession of "StoredKey" 741 and "ServerKey" can't automatic increase the iteration count upon 742 successful authentication. Such increase would require resetting 743 user's password.) 745 If the authentication information is stolen from the authentication 746 database, then an offline dictionary or brute-force attack can be 747 used to recover the user's password. The use of salt mitigates this 748 attack somewhat by requiring a separate attack on each password. 749 Authentication mechanisms which protect against this attack are 750 available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is 751 an example of such technology. 753 If an attacker obtains the authentication information from the 754 authentication repository and either eavesdrops on one authentication 755 exchange or impersonates a server, the attacker gains the ability to 756 impersonate that user to all servers providing SCRAM access using the 757 same hash function, password, iteration count and salt. For this 758 reason, it is important to use randomly-generated salt values. 760 SCRAM does not negotiate a hash function to use. Hash function 761 negotiation is left to the HTTP authentication mechanism negotiation. 762 It is important that clients be able to sort a locally available list 763 of mechanisms by preference so that the client may pick the most 764 preferred of a server's advertised mechanism list. This preference 765 order is not specified here as it is a local matter. The preference 766 order should include objective and subjective notions of mechanism 767 cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be 768 preferred over SCRAM with SHA-1). 770 SCRAM does not protect against downgrade attacks of channel binding 771 types. The complexities of negotiation a channel binding type, and 772 handling down-grade attacks in that negotiation, was intentionally 773 left out of scope for this document. 775 A hostile server can perform a computational denial-of-service attack 776 on clients by sending a big iteration count value. 778 See [RFC4086] for more information about generating randomness. 780 8. IANA Considerations 782 New mechanisms in the SCRAM- family are registered according to the 783 IANA procedure specified in [RFC5802]. 785 Note to future SCRAM- mechanism designers: each new SCRAM- HTTP 786 authentication mechanism MUST be explicitly registered with IANA and 787 MUST comply with SCRAM- mechanism naming convention defined in 788 Section 4 of this document. 790 IANA is requested to add the following entry to the Authentication 791 Scheme Registry defined in HTTP/1.1, Part 7 [RFC7235]: 793 Authentication Scheme Name: SCRAM-SHA-1 794 Pointer to specification text: [[ this document ]] 795 Notes (optional): (none) 797 9. Acknowledgements 799 This document benefited from discussions on the HTTPAuth, SASL and 800 Kitten WG mailing lists. The authors would like to specially thank 801 co-authors of [RFC5802] from which lots of text was copied. 803 Special thank you to Tony Hansen for doing an early implementation 804 and providing extensive comments on the draft. 806 10. Design Motivations 808 The following design goals shaped this document. Note that some of 809 the goals have changed since the initial version of the document. 811 o The HTTP authentication mechanism has all modern features: support 812 for internationalized usernames and passwords, support for channel 813 bindings. 815 o The protocol supports mutual authentication. 817 o The authentication information stored in the authentication 818 database is not sufficient by itself to impersonate the client. 820 o The server does not gain the ability to impersonate the client to 821 other servers (with an exception for server-authorized proxies), 822 unless such other servers allow SCRAM authentication and use the 823 same salt and iteration count for the user. 825 o The mechanism is extensible, but [hopefully] not overengineered in 826 this respect. 828 o Easier to implement than HTTP Digest in both clients and servers. 830 11. Open Issues 832 It should be possible to construct a quick reauthentication version 833 of the mechanism that uses fewer round-trips (similar to what Digest 834 has). 836 12. Internet-Draft Change History 838 (RFC Editor: Please delete this section and all subsections.) 840 Changes since -00 842 o 844 13. References 846 13.1. Normative References 848 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 849 Hashing for Message Authentication", RFC 2104, February 850 1997. 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, March 1997. 855 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 856 (SHA1)", RFC 3174, September 2001. 858 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 859 Internationalized Strings ("stringprep")", RFC 3454, 860 December 2002. 862 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 863 10646", STD 63, RFC 3629, November 2003. 865 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 866 and Passwords", RFC 4013, February 2005. 868 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 869 Encodings", RFC 4648, October 2006. 871 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 872 Channels", RFC 5056, November 2007. 874 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 875 Specifications: ABNF", STD 68, RFC 5234, January 2008. 877 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 878 for TLS", RFC 5929, July 2010. 880 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 881 (HTTP/1.1): Authentication", RFC 7235, June 2014. 883 13.2. Informative References 885 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 886 "Remote Authentication Dial In User Service (RADIUS)", RFC 887 2865, June 2000. 889 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 890 Specification Version 2.0", RFC 2898, September 2000. 892 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 893 RFC 2945, September 2000. 895 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 896 Requirements for Security", BCP 106, RFC 4086, June 2005. 898 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 899 (LDAP): Technical Specification Road Map", RFC 4510, June 900 2006. 902 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 903 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 905 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 906 4949, August 2007. 908 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 909 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 910 May 2008. 912 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 913 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 915 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 916 "Salted Challenge Response Authentication Mechanism 917 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 919 [RFC5803] Melnikov, A., "Lightweight Directory Access Protocol 920 (LDAP) Schema for Storing Salted Challenge Response 921 Authentication Mechanism (SCRAM) Secrets", RFC 5803, July 922 2010. 924 [tls-server-end-point] 925 Zhu, L., , "Registration of TLS server end-point channel 926 bindings", IANA http://www.iana.org/assignments/ 927 channel-binding-types/tls-server-end-point, July 2008. 929 Author's Address 931 Alexey Melnikov 932 Isode Ltd 934 Email: Alexey.Melnikov@isode.com