idnits 2.17.1 draft-ietf-httpauth-scram-auth-14.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 10 instances of too long lines in the document, the longest one being 13 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 (December 5, 2015) is 3062 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5246' is defined on line 773, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7613 (Obsoleted by RFC 8265) ** Obsolete normative reference: RFC 7615 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: Experimental December 5, 2015 5 Expires: June 7, 2016 7 Salted Challenge Response (SCRAM) HTTP Authentication Mechanism 8 draft-ietf-httpauth-scram-auth-14.txt 10 Abstract 12 This specification describes a family of HTTP authentication 13 mechanisms called the Salted Challenge Response Authentication 14 Mechanism (SCRAM), which provides a more robust authentication 15 mechanism than a plaintext password protected by Transport Layer 16 Security (TLS) and avoids the deployment obstacles presented by 17 earlier TLS-protected challenge response authentication mechanisms. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 7, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5 58 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6 59 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 60 5.1. One round trip reauthentication . . . . . . . . . . . . . . 10 61 6. Use of Authentication-Info header field with SCRAM . . . . . 12 62 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 66 11. Design Motivations . . . . . . . . . . . . . . . . . . . . . 15 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 69 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 72 1. Introduction 74 The authentication mechanism most widely deployed and used by 75 Internet application protocols is the transmission of clear-text 76 passwords over a channel protected by Transport Layer Security (TLS). 77 There are some significant security concerns with that mechanism, 78 which could be addressed by the use of a challenge response 79 authentication mechanism protected by TLS. Unfortunately, the HTTP 80 Digest challenge response mechanism presently on the standards track 81 failed widespread deployment, and have had success only in limited 82 use. 84 This specification describes a family of authentication mechanisms 85 called the Salted Challenge Response Authentication Mechanism (SCRAM) 86 which addresses the requirements necessary to deploy a challenge- 87 response mechanism more widely than past attempts (see [RFC5802]). 88 In particular, it addresses some of the issues identified with HTTP 89 Digest [RFC6331], such as complexity of implementing and protection 90 of the whole authentication exchange in order to protect from certain 91 man-in-the-middle attacks. 93 HTTP SCRAM is adoptation of [RFC5802] for use in HTTP. (SCRAM data 94 exchanged is identical to what is defined in [RFC5802].) It also 95 adds 1 round trip reauthentication mode. 97 HTTP SCRAM provides the following protocol features: 99 o The authentication information stored in the authentication 100 database is not sufficient by itself (without a dictionary attack) 101 to impersonate the client. The information is salted to prevent a 102 pre-stored dictionary attack if the database is stolen. 104 o The server does not gain the ability to impersonate the client to 105 other servers (with an exception for server-authorized proxies). 107 o The mechanism permits the use of a server-authorized proxy without 108 requiring that proxy to have super-user rights with the back-end 109 server. 111 o Mutual authentication is supported, but only the client is named 112 (i.e., the server has no name). 114 2. Conventions Used in This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 Formal syntax is defined by [RFC5234] including the core rules 121 defined in Appendix B of [RFC5234]. 123 Example lines prefaced by "C:" are sent by the client and ones 124 prefaced by "S:" by the server. If a single "C:" or "S:" label 125 applies to multiple lines, then the line breaks between those lines 126 are for editorial clarity only, and are not part of the actual 127 protocol exchange. 129 2.1. Terminology 131 This document uses several terms defined in [RFC4949] ("Internet 132 Security Glossary") including the following: authentication, 133 authentication exchange, authentication information, brute force, 134 challenge-response, cryptographic hash function, dictionary attack, 135 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 136 one-way encryption function, password, replay attack and salt. 137 Readers not familiar with these terms should use that glossary as a 138 reference. 140 Some clarifications and additional definitions follow: 142 o Authentication information: Information used to verify an identity 143 claimed by a SCRAM client. The authentication information for a 144 SCRAM identity consists of salt, iteration count, the "StoredKey" 145 and "ServerKey" (as defined in the algorithm overview) for each 146 supported cryptographic hash function. 148 o Authentication database: The database used to look up the 149 authentication information associated with a particular identity. 150 For application protocols, LDAPv3 (see [RFC4510]) is frequently 151 used as the authentication database. For lower-layer protocols 152 such as PPP or 802.11x, the use of RADIUS [RFC2865] is more 153 common. 155 o Base64: An encoding mechanism defined in Section 4 of [RFC4648] 156 which converts an octet string input to a textual output string 157 which can be easily displayed to a human. The use of base64 in 158 SCRAM is restricted to the canonical form with no whitespace. 160 o Octet: An 8-bit byte. 162 o Octet string: A sequence of 8-bit bytes. 164 o Salt: A random octet string that is combined with a password 165 before applying a one-way encryption function. This value is used 166 to protect passwords that are stored in an authentication 167 database. 169 2.2. Notation 171 The pseudocode description of the algorithm uses the following 172 notations: 174 o ":=": The variable on the left hand side represents the octet 175 string resulting from the expression on the right hand side. 177 o "+": Octet string concatenation. 179 o "[ ]": A portion of an expression enclosed in "[" and "]" may not 180 be included in the result under some circumstances. See the 181 associated text for a description of those circumstances. 183 o Normalize(str): Apply the Preparation and Enforcement steps 184 according to the OpaqueString profile (see [RFC7613]) to a UTF-8 185 [RFC3629] encoded "str". The resulting string is also in UTF-8. 186 Note that implementations MUST either implement OpaqueString 187 profile operations from [RFC7613], or disallow use of non US-ASCII 188 Unicode codepoints in "str". The latter is a particular case of 189 compliance with [RFC7613]. 191 o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 192 [RFC2104]) using the octet string represented by "key" as the key 193 and the octet string "str" as the input string. The size of the 194 result is the hash result size for the hash function in use. For 195 example, it is 32 octets for SHA-256 and 20 octets for SHA-1 (see 196 [RFC6234]). 198 o H(str): Apply the cryptographic hash function to the octet string 199 "str", producing an octet string as a result. The size of the 200 result depends on the hash result size for the hash function in 201 use. 203 o XOR: Apply the exclusive-or operation to combine the octet string 204 on the left of this operator with the octet string on the right of 205 this operator. The length of the output and each of the two 206 inputs will be the same for this use. 208 o Hi(str, salt, i): 210 U1 := HMAC(str, salt + INT(1)) 211 U2 := HMAC(str, U1) 212 ... 213 Ui-1 := HMAC(str, Ui-2) 214 Ui := HMAC(str, Ui-1) 216 Hi := U1 XOR U2 XOR ... XOR Ui 218 where "i" is the iteration count, "+" is the string concatenation 219 operator and INT(g) is a four-octet encoding of the integer g, 220 most significant octet first. 222 Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 223 with dkLen == output length of HMAC() == output length of H(). 225 3. SCRAM Algorithm Overview 227 The following is a description of a full HTTP SCRAM authentication 228 exchange. Note that this section omits some details, such as client 229 and server nonces. See Section 5 for more details. 231 To begin with, the SCRAM client is in possession of a username and 232 password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends 233 the username to the server, which retrieves the corresponding 234 authentication information, i.e. a salt, StoredKey, ServerKey and the 235 iteration count i. (Note that a server implementation may choose to 236 use the same iteration count for all accounts.) The server sends the 237 salt and the iteration count to the client, which then computes the 238 following values and sends a ClientProof to the server: 240 (*) - Note that both the username and the password MUST be encoded in 241 UTF-8 [RFC3629]. 243 Informative Note: Implementors are encouraged to create test cases 244 that use both username passwords with non-ASCII codepoints. In 245 particular, it is useful to test codepoints whose "Unicode 246 Normalization Form C" and "Unicode Normalization Form KC" are 247 different. Some examples of such codepoints include Vulgar Fraction 248 One Half (U+00BD) and Acute Accent (U+00B4). 250 SaltedPassword := Hi(Normalize(password), salt, i) 251 ClientKey := HMAC(SaltedPassword, "Client Key") 252 StoredKey := H(ClientKey) 253 AuthMessage := client-first-message-bare + "," + 254 server-first-message + "," + 255 client-final-message-without-proof 256 ClientSignature := HMAC(StoredKey, AuthMessage) 257 ClientProof := ClientKey XOR ClientSignature 258 ServerKey := HMAC(SaltedPassword, "Server Key") 259 ServerSignature := HMAC(ServerKey, AuthMessage) 261 The server authenticates the client by computing the ClientSignature, 262 exclusive-ORing that with the ClientProof to recover the ClientKey 263 and verifying the correctness of the ClientKey by applying the hash 264 function and comparing the result to the StoredKey. If the ClientKey 265 is correct, this proves that the client has access to the user's 266 password. 268 Similarly, the client authenticates the server by computing the 269 ServerSignature and comparing it to the value sent by the server. If 270 the two are equal, it proves that the server had access to the user's 271 ServerKey. 273 For initial authentication the AuthMessage is computed by 274 concatenating decoded "data" attribute values from the authentication 275 exchange. The format of these messages is defined in [RFC5802]. 277 4. SCRAM Mechanism Names 279 A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" 280 followed by the uppercased name of the underlying hash function taken 281 from the IANA "Hash Function Textual Names" registry (see 282 http://www.iana.org) . 284 For interoperability, all HTTP clients and servers supporting SCRAM 285 MUST implement the SCRAM-SHA-256 authentication mechanism, i.e. an 286 authentication mechanism from the SCRAM family that uses the SHA-256 287 hash function as defined in [RFC7677]. 289 5. SCRAM Authentication Exchange 291 HTTP SCRAM is a HTTP Authentication mechanism whose client response 292 () and server challenge () 293 messages are text-based messages containing one or more attribute- 294 value pairs separated by commas. The messages and their attributes 295 are described below and defined in Section 7. 297 challenge-scram = scram-name [1*SP 1#auth-param] 298 ; Complies with ABNF from RFC 7235. 299 ; Included in the WWW-Authenticate header field. 301 credentials-scram = scram-name [1*SP 1#auth-param] 302 ; Complies with from RFC 7235. 303 ; Included in the Authorization header field. 305 scram-name = "SCRAM-SHA-256" / "SCRAM-SHA-1" / other-scram-name 306 ; SCRAM-SHA-256 and SCRAM-SHA-1 are registered by this RFC. 307 ; 308 ; SCRAM-SHA-1 is registered for database compatibility 309 ; with implementations of RFC 5802 (such as IMAP or XMPP 310 ; servers), but it is not recommended for new deployments. 312 other-scram-name = "SCRAM-" hash-name 313 ; hash-name is a capitalized form of names from IANA 314 ; "Hash Function Textual Names" registry. 315 ; Additional SCRAM names must be registered in both 316 ; the IANA "SASL mechanisms" registry 317 ; and the IANA "authentication scheme" registry. 319 This is a simple example of a SCRAM-SHA-256 authentication exchange 320 (no support for channel bindings, as this feature is not currently 321 supported by HTTP). Username 'user' and password 'pencil' are used. 322 Note that long lines are folded for readability. 324 C: GET /resource HTTP/1.1 325 C: Host: server.example.com 326 C: [...] 328 S: HTTP/1.1 401 Unauthorized 329 S: WWW-Authenticate: Digest realm="realm1@example.com", 330 Digest realm="realm2@example.com", 331 Digest realm="realm3@example.com", 332 SCRAM-SHA-256 realm="realm3@example.com", 333 SCRAM-SHA-256 realm="testrealm@example.com" 334 S: [...] 336 C: GET /resource HTTP/1.1 337 C: Host: server.example.com 338 C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com", 339 data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K 340 C: [...] 342 S: HTTP/1.1 401 Unauthorized 343 S: WWW-Authenticate: SCRAM-SHA-256 344 sid=AAAABBBBCCCCDDDD, 345 data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGo 346 paE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK 347 S: [...] 349 C: GET /resource HTTP/1.1 350 C: Host: server.example.com 351 C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD, 352 data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG 353 SWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3FtbWl6 354 N0FuZFZRPQo= 355 C: [...] 357 S: HTTP/1.1 200 Ok 358 S: Authentication-Info: sid=AAAABBBBCCCCDDDD, 359 data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo= 360 S: [...Other header fields and resource body...] 362 In the above example the first client request contains data attribute 363 which base64 decodes as follows: "n,,n=user,r=rOprNGfwEbeRWgbNEkqO" 364 (with no quotes). Server then responds with data attribute which 365 base64 decodes as follows: "r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxF 366 Ilj)hNlF,s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096". The next client request 367 contains data attribute which base64 decodes as follows: "c=biws,r=rO 368 prNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZapWIk4jUhN+Ute9y 369 tag9zjfMHgsqmmiz7AndVQ=". The final server response contains a data 370 attribute which base64 decodes as follows: 372 "v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=". 374 Note that in the example above the client can also initiate SCRAM 375 authentication without first being prompted by the server. 377 Initial "SCRAM-SHA-256" authentication starts with sending the 378 "Authorization" request header field defined by HTTP/1.1, Part 7 379 [RFC7235] containing "SCRAM-SHA-256" authentication scheme and the 380 following attributes: 382 o A "realm" attribute MAY be included to indicate the scope of 383 protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. 384 As specified in [RFC7235], the "realm" attribute MUST NOT appear 385 more than once. The realm attribute only appears in the first 386 SCRAM message to the server and in the first SCRAM response from 387 the server. 389 o The client also includes the data attribute that contains base64 390 encoded "client-first-message" [RFC5802] containing: 392 * a header consisting of a flag indicating whether channel 393 binding is supported-but-not-used, not supported, or used . 394 Note that this version of SCRAM doesn't support HTTP channel 395 bindings, so this header always starts with "n"; otherwise the 396 message is invalid and authentication MUST fail. 398 * SCRAM username and a random, unique nonce attributes. 400 In HTTP response, the server sends WWW-Authenticate header field 401 containing: a unique session identifier (the "sid" attribute) plus 402 the "data" attribute containing base64-encoded "server-first-message" 403 [RFC5802]. The "server-first-message" contains the user's iteration 404 count i, the user's salt, and the nonce with a concatenation of the 405 client-specified one (taken from the "client-first-message") with a 406 freshly generated server nonce. 408 The client then responds with another HTTP request with the 409 Authorization header field, which includes the "sid" attribute 410 received in the previous server response, together with the "data" 411 attribute containing base64-encoded "client-final-message" data. The 412 latter has the same nonce as in "server-first-message" and a 413 ClientProof computed using the selected hash function (e.g. SHA-256) 414 as explained earlier. 416 The server verifies the nonce and the proof, and, finally, it 417 responds with a 200 HTTP response with the Authentication-Info header 418 field [RFC7615] containing the "sid" attribute (as received from the 419 client) and the "data" attribute containing base64-encoded "server- 420 final-message", concluding the authentication exchange. 422 The client then authenticates the server by computing the 423 ServerSignature and comparing it to the value sent by the server. If 424 the two are different, the client MUST consider the authentication 425 exchange to be unsuccessful and it might have to drop the connection. 427 5.1. One round trip reauthentication 429 If the server supports SCRAM reauthentication, the server sends in 430 its initial HTTP response a WWW-Authenticate header field containing: 431 the "realm" attribute (as defined earlier), the "sr" attribute that 432 contains the server part of the "r" attribute (see s-nonce in 433 [RFC5802]) and optional "ttl" attribute (which contains the "sr" 434 value validity in seconds). 436 If the client has authenticated to the same realm before (i.e. it 437 remembers "i" and "s" attributes for the user from earlier 438 authentication exchanges with the server), it can respond to that 439 with "client-final-message". When constructing the "client-final- 440 message" the client constructs the c-nonce part of the "r" attribute 441 as on initial authentication and the s-nonce part as follows: s-nonce 442 is a concatenation of nonce-count and the "sr" attribute (in that 443 order). The nonce-count is a positive integer that that is equal to 444 the user's "i" attribute on first reauthentication and is incremented 445 by 1 on each successful re-authentication. 447 The purpose of the nonce-count is to allow the server to detect 448 request replays by maintaining its own copy of this count - if the 449 same nonce-count value is seen twice, then the request is a 450 replay. 452 If the server considers the s-nonce part of the nonce attribute (the 453 "r" attribute) to be still valid (i.e. the nonce-count part is as 454 expected (see above) and the "sr" part is still fresh), it will 455 provide access to the requested resource (assuming the client hash 456 verifies correctly, of course). However if the server considers that 457 the server part of the nonce is stale (for example if the "sr" value 458 is used after the "ttl" seconds), the server returns "401 459 Unauthorized" containing the SCRAM mechanism name with the following 460 attributes: a new "sr", "stale=true" and an optional "ttl". The 461 "stale" attribute signals to the client that there is no need to ask 462 user for the password. 464 Formally, the "stale" attribute is defined as follows: A flag, 465 indicating that the previous request from the client was rejected 466 because the nonce value was stale. If stale is TRUE (case- 467 insensitive), the client may wish to simply retry the request with 468 a new encrypted response, without reprompting the user for a new 469 username and password. The server should only set stale to TRUE 470 if it receives a request for which the nonce is invalid but with a 471 valid digest for that nonce (indicating that the client knows the 472 correct username/password). If stale is FALSE, or anything other 473 than TRUE, or the stale directive is not present, the username 474 and/or password are invalid, and new values must be obtained. 476 When constructing AuthMessage Section 3 to be used for calculating 477 client and server proofs, "client-first-message-bare" and "server- 478 first-message" are reconstructed from data known to the client and 479 the server. 481 Reauthentication can look like this: 483 C: GET /resource HTTP/1.1 484 C: Host: server.example.com 485 C: [...] 487 S: HTTP/1.1 401 Unauthorized 488 S: WWW-Authenticate: Digest realm="realm1@example.com", 489 Digest realm="realm2@example.com", 490 Digest realm="realm3@example.com", 491 SCRAM-SHA-256 realm="realm3@example.com", 492 SCRAM-SHA-256 realm="testrealm@example.com", sr=%hvYDpWUa2RaTCAfuxFIlj)hNlF 493 SCRAM-SHA-256 realm="testrealm2@example.com", sr=AAABBBCCCDDD, ttl=120 494 S: [...] 496 [Client authenticates as usual to realm "testrealm@example.com"] 498 [Some time later client decides to reauthenticate. 499 It will use the cached "i" (4096) and "s" (W22ZaJ0SNY7soEsUEjb6gQ==) 500 from earlier exchanges. It will use the nonce-value of 4096 together 501 with the server advertised "sr" value as the server part of the "r".] 503 C: GET /resource HTTP/1.1 504 C: Host: server.example.com 505 C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com", 506 data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhMlJhVENB 507 ZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOXpqZk1IZ3Nx 508 bW1pejdBbmRWUT0K 510 C: [...] 512 S: HTTP/1.1 200 Ok 513 S: Authentication-Info: sid=AAAABBBBCCCCDDDD, 514 data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo= 515 S: [...Other header fields and resource body...] 517 6. Use of Authentication-Info header field with SCRAM 519 When used with SCRAM, the Authentication-Info header field is allowed 520 in the trailer of an HTTP message transferred via chunked transfer- 521 coding. 523 7. Formal Syntax 525 The following syntax specification uses the Augmented Backus-Naur 526 Form (ABNF) notation as specified in [RFC5234]. 528 ALPHA = 529 DIGIT = 531 base64-char = ALPHA / DIGIT / "/" / "+" 533 base64-4 = 4base64-char 535 base64-3 = 3base64-char "=" 537 base64-2 = 2base64-char "==" 539 base64 = *base64-4 [base64-3 / base64-2] 541 sr = "sr=" s-nonce 542 ;; s-nonce is defined in RFC 5802. 544 data = "data=" base64 545 ;; The data attribute value is base64 encoded 546 ;; SCRAM challenge or response defined in 547 ;; RFC 5802. 549 ttl = "ttl" = 1*DIGIT 550 ;; "sr" value validity in seconds. 551 ;; No leading 0s. 553 reauth-s-nonce = nonce-count s-nonce 555 nonce-count = posit-number 556 ;; posit-number is defined in RFC 5802. 557 ;; The initial value is taken from the "i" 558 ;; attribute for the user and is incremented 559 ;; by 1 on each successful re-authentication. 561 sid = "sid=" token 562 ;; See token definition in RFC 7235. 564 stale = "stale=" ( "true" / "false" ) 566 realm = "realm=" 568 8. Security Considerations 570 If the authentication exchange is performed without a strong session 571 encryption (such as TLS with data confidentiality), then a passive 572 eavesdropper can gain sufficient information to mount an offline 573 dictionary or brute-force attack which can be used to recover the 574 user's password. The amount of time necessary for this attack 575 depends on the cryptographic hash function selected, the strength of 576 the password and the iteration count supplied by the server. SCRAM 577 allows the server/server administrator to increase the iteration 578 count over time in order to slow down the above attacks. (Note that 579 a server that is only in posession of "StoredKey" and "ServerKey" 580 can't automatic increase the iteration count upon successful 581 authentication. Such increase would require resetting user's 582 password.) An external security layer with strong encryption will 583 prevent these attack. 585 If the authentication information is stolen from the authentication 586 database, then an offline dictionary or brute-force attack can be 587 used to recover the user's password. The use of salt mitigates this 588 attack somewhat by requiring a separate attack on each password. 589 Authentication mechanisms which protect against this attack are 590 available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is 591 an example of such technology. 593 If an attacker obtains the authentication information from the 594 authentication repository and either eavesdrops on one authentication 595 exchange or impersonates a server, the attacker gains the ability to 596 impersonate that user to all servers providing SCRAM access using the 597 same hash function, password, iteration count and salt. For this 598 reason, it is important to use randomly-generated salt values. 600 SCRAM does not negotiate a hash function to use. Hash function 601 negotiation is left to the HTTP authentication mechanism negotiation. 602 It is important that clients be able to sort a locally available list 603 of mechanisms by preference so that the client may pick the most 604 preferred of a server's advertised mechanism list. This preference 605 order is not specified here as it is a local matter. The preference 606 order should include objective and subjective notions of mechanism 607 cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be 608 preferred over SCRAM with SHA-1). 610 A hostile server can perform a computational denial-of-service attack 611 on clients by sending a big iteration count value. In order to 612 defend against that, a client implementation can pick a maximum 613 iteration count that it is willing to use, and that it rejects any 614 values that exceed that threshold (in such cases the client, of 615 course, has to fail the authentication). 617 See [RFC4086] for more information about generating randomness. 619 This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1 620 is registered for database compatibility with implementations of RFC 621 5802 (such as IMAP or XMPP servers) which want to also expose HTTP 622 access to a related service, but it is not recommended for new 623 deployments. 625 9. IANA Considerations 627 New mechanisms in the SCRAM- family are registered according to the 628 IANA procedure specified in [RFC5802]. 630 Note to future SCRAM- mechanism designers: each new SCRAM- HTTP 631 authentication mechanism MUST be explicitly registered with IANA and 632 MUST comply with SCRAM- mechanism naming convention defined in 633 Section 4 of this document. 635 IANA is requested to add the following entry to the Authentication 636 Scheme Registry defined in HTTP/1.1, Part 7 [RFC7235]: 638 Authentication Scheme Name: SCRAM-SHA-256 639 Pointer to specification text: [[ this document ]] 640 Notes (optional): (none) 642 Authentication Scheme Name: SCRAM-SHA-1 643 Pointer to specification text: [[ this document ]] 644 Notes (optional): (none) 646 10. Acknowledgements 648 This document benefited from discussions on the HTTPAuth, SASL and 649 Kitten WG mailing lists. The authors would like to specially thank 650 co-authors of [RFC5802] from which lots of text was copied. 652 Thank you to Martin Thomson for the idea of adding "ttl" attribute. 654 Thank you to Julian F. Reschke for corrections regarding use of 655 Authentication-Info header field. 657 Special thank you to Tony Hansen for doing an early implementation 658 and providing extensive comments on the draft. 660 11. Design Motivations 662 The following design goals shaped this document. Note that some of 663 the goals have changed since the initial version of the document. 665 o The HTTP authentication mechanism has all modern features: support 666 for internationalized usernames and passwords, support for channel 667 bindings. 669 o The protocol supports mutual authentication. 671 o The authentication information stored in the authentication 672 database is not sufficient by itself to impersonate the client. 674 o The server does not gain the ability to impersonate the client to 675 other servers (with an exception for server-authorized proxies), 676 unless such other servers allow SCRAM authentication and use the 677 same salt and iteration count for the user. 679 o The mechanism is extensible, but [hopefully] not overengineered in 680 this respect. 682 o Easier to implement than HTTP Digest in both clients and servers. 684 12. References 686 12.1. Normative References 688 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 689 Hashing for Message Authentication", RFC 2104, 690 DOI 10.17487/RFC2104, February 1997, 691 . 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, 695 DOI 10.17487/RFC2119, March 1997, 696 . 698 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 699 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 700 2003, . 702 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 703 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 704 . 706 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 707 Specifications: ABNF", STD 68, RFC 5234, 708 DOI 10.17487/RFC5234, January 2008, 709 . 711 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 712 "Salted Challenge Response Authentication Mechanism 713 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 714 DOI 10.17487/RFC5802, July 2010, 715 . 717 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 718 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 719 DOI 10.17487/RFC6234, May 2011, 720 . 722 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 723 Protocol (HTTP/1.1): Authentication", RFC 7235, 724 DOI 10.17487/RFC7235, June 2014, 725 . 727 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 728 Enforcement, and Comparison of Internationalized Strings 729 Representing Usernames and Passwords", RFC 7613, 730 DOI 10.17487/RFC7613, August 2015, 731 . 733 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 734 Authentication-Info Response Header Fields", RFC 7615, 735 DOI 10.17487/RFC7615, September 2015, 736 . 738 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 739 Authentication and Security Layer (SASL) Mechanisms", 740 RFC 7677, DOI 10.17487/RFC7677, November 2015, 741 . 743 12.2. Informative References 745 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 746 "Remote Authentication Dial In User Service (RADIUS)", 747 RFC 2865, DOI 10.17487/RFC2865, June 2000, 748 . 750 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 751 Specification Version 2.0", RFC 2898, 752 DOI 10.17487/RFC2898, September 2000, 753 . 755 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 756 RFC 2945, DOI 10.17487/RFC2945, September 2000, 757 . 759 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 760 "Randomness Requirements for Security", BCP 106, RFC 4086, 761 DOI 10.17487/RFC4086, June 2005, 762 . 764 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 765 (LDAP): Technical Specification Road Map", RFC 4510, 766 DOI 10.17487/RFC4510, June 2006, 767 . 769 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 770 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 771 . 773 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 774 (TLS) Protocol Version 1.2", RFC 5246, 775 DOI 10.17487/RFC5246, August 2008, 776 . 778 [RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331, 779 DOI 10.17487/RFC6331, July 2011, 780 . 782 Author's Address 784 Alexey Melnikov 785 Isode Ltd 787 Email: Alexey.Melnikov@isode.com