idnits 2.17.1 draft-ietf-httpauth-scram-auth-15.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 16, 2015) is 3054 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** 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) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 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 16, 2015 5 Expires: June 18, 2016 7 Salted Challenge Response (SCRAM) HTTP Authentication Mechanism 8 draft-ietf-httpauth-scram-auth-15.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 18, 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 . . . . . . . . . . . . . . . . . . . . . 16 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 has 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, as described in [RFC6331], such as complexity of implementing 90 and protection of the whole authentication exchange in order to 91 protect from certain man-in-the-middle attacks. 93 HTTP SCRAM is an adoptation of [RFC5802] for use in HTTP. The SCRAM 94 data exchanged is identical to what is defined in [RFC5802]. This 95 document also adds a 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 make it 102 harder to do a pre-stored dictionary attack if the database is 103 stolen. 105 o The server does not gain the ability to impersonate the client to 106 other servers (with an exception for server-authorized proxies), 107 unless it performs a dictionary attack. 109 o The mechanism permits the use of a server-authorized proxy without 110 requiring that proxy to have super-user rights with the back-end 111 server. 113 o Mutual authentication is supported, but only the client is named 114 (i.e., the server has no name). 116 2. Conventions Used in This Document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 Formal syntax is defined by [RFC5234] including the core rules 123 defined in Appendix B of [RFC5234]. 125 Example lines prefaced by "C:" are sent by the client and ones 126 prefaced by "S:" by the server. If a single "C:" or "S:" label 127 applies to multiple lines, then the line breaks between those lines 128 are for editorial clarity only, and are not part of the actual 129 protocol exchange. 131 2.1. Terminology 133 This document uses several terms defined in [RFC4949] ("Internet 134 Security Glossary") including the following: authentication, 135 authentication exchange, authentication information, brute force, 136 challenge-response, cryptographic hash function, dictionary attack, 137 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 138 one-way encryption function, password, replay attack and salt. 139 Readers not familiar with these terms should use that glossary as a 140 reference. 142 Some clarifications and additional definitions follow: 144 o Authentication information: Information used to verify an identity 145 claimed by a SCRAM client. The authentication information for a 146 SCRAM identity consists of salt, iteration count, the "StoredKey" 147 and "ServerKey" (as defined in the algorithm overview) for each 148 supported cryptographic hash function. 150 o Authentication database: The database used to look up the 151 authentication information associated with a particular identity. 152 For application protocols, LDAPv3 (see [RFC4510]) is frequently 153 used as the authentication database. For lower-layer protocols 154 such as PPP or 802.11x, the use of RADIUS [RFC2865] is more 155 common. 157 o Base64: An encoding mechanism defined in Section 4 of [RFC4648] 158 which converts an octet string input to a textual output string 159 which can be easily displayed to a human. The use of base64 in 160 SCRAM is restricted to the canonical form with no whitespace. 162 o Octet: An 8-bit byte. 164 o Octet string: A sequence of 8-bit bytes. 166 o Salt: A random octet string that is combined with a password 167 before applying a one-way encryption function. This value is used 168 to protect passwords that are stored in an authentication 169 database. 171 2.2. Notation 173 The pseudocode description of the algorithm uses the following 174 notations: 176 o ":=": The variable on the left hand side represents the octet 177 string resulting from the expression on the right hand side. 179 o "+": Octet string concatenation. 181 o "[ ]": A portion of an expression enclosed in "[" and "]" is 182 optional in the result under some circumstances. See the 183 associated text for a description of those circumstances. 185 o Normalize(str): Apply the Preparation and Enforcement steps 186 according to the OpaqueString profile (see [RFC7613]) to a UTF-8 187 [RFC3629] encoded "str". The resulting string is also in UTF-8. 188 Note that implementations MUST either implement OpaqueString 189 profile operations from [RFC7613], or disallow use of non US-ASCII 190 Unicode codepoints in "str". The latter is a particular case of 191 compliance with [RFC7613]. 193 o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 194 [RFC2104]) using the octet string represented by "key" as the key 195 and the octet string "str" as the input string. The size of the 196 result is the hash result size for the hash function in use. For 197 example, it is 32 octets for SHA-256 and 20 octets for SHA-1 (see 198 [RFC6234]). 200 o H(str): Apply the cryptographic hash function to the octet string 201 "str", producing an octet string as a result. The size of the 202 result depends on the hash result size for the hash function in 203 use. 205 o XOR: Apply the exclusive-or operation to combine the octet string 206 on the left of this operator with the octet string on the right of 207 this operator. The length of the output and each of the two 208 inputs will be the same for this use. 210 o Hi(str, salt, i): 212 U1 := HMAC(str, salt + INT(1)) 213 U2 := HMAC(str, U1) 214 ... 215 Ui-1 := HMAC(str, Ui-2) 216 Ui := HMAC(str, Ui-1) 218 Hi := U1 XOR U2 XOR ... XOR Ui 220 where "i" is the iteration count, "+" is the string concatenation 221 operator and INT(g) is a four-octet encoding of the integer g, 222 most significant octet first. 224 Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 225 with dkLen == output length of HMAC() == output length of H(). 227 3. SCRAM Algorithm Overview 229 The following is a description of a full HTTP SCRAM authentication 230 exchange. Note that this section omits some details, such as client 231 and server nonces. See Section 5 for more details. 233 To begin with, the SCRAM client is in possession of a username and 234 password, both encoded in UTF-8 [RFC3629] (or a ClientKey/ServerKey, 235 or SaltedPassword). It sends the username to the server, which 236 retrieves the corresponding authentication information: a salt, a 237 StoredKey, a ServerKey and an iteration count ("i"). (Note that a 238 server implementation may choose to use the same iteration count for 239 all accounts.) The server sends the salt and the iteration count to 240 the client, which then computes the following values and sends a 241 ClientProof to the server: 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 Canonical Composition (NFC)" and "Unicode Normalization 247 Form Compatibility Composition (NFKC)" are different. Some examples 248 of such codepoints include Vulgar Fraction One Half (U+00BD) and 249 Acute Accent (U+00B4). 251 SaltedPassword := Hi(Normalize(password), salt, i) 252 ClientKey := HMAC(SaltedPassword, "Client Key") 253 StoredKey := H(ClientKey) 254 AuthMessage := client-first-message-bare + "," + 255 server-first-message + "," + 256 client-final-message-without-proof 257 ClientSignature := HMAC(StoredKey, AuthMessage) 258 ClientProof := ClientKey XOR ClientSignature 259 ServerKey := HMAC(SaltedPassword, "Server Key") 260 ServerSignature := HMAC(ServerKey, AuthMessage) 262 The server authenticates the client by computing the ClientSignature, 263 exclusive-ORing that with the ClientProof to recover the ClientKey 264 and verifying the correctness of the ClientKey by applying the hash 265 function and comparing the result to the StoredKey. If the ClientKey 266 is correct, this proves that the client has access to the user's 267 password. 269 Similarly, the client authenticates the server by computing the 270 ServerSignature and comparing it to the value sent by the server. If 271 the two are equal, it proves that the server had access to the user's 272 ServerKey. 274 For initial authentication the AuthMessage is computed by 275 concatenating decoded "data" attribute values from the authentication 276 exchange. The format of each of these 3 decoded "data" attributes is 277 defined in [RFC5802]. 279 4. SCRAM Mechanism Names 281 A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" 282 followed by the uppercased name of the underlying hash function taken 283 from the IANA "Hash Function Textual Names" registry (see 284 http://www.iana.org/assignments/hash-function-text-names/) . 286 For interoperability, all HTTP clients and servers supporting SCRAM 287 MUST implement the SCRAM-SHA-256 authentication mechanism, i.e. an 288 authentication mechanism from the SCRAM family that uses the SHA-256 289 hash function as defined in [RFC7677]. 291 5. SCRAM Authentication Exchange 293 HTTP SCRAM is a HTTP Authentication mechanism whose client response 294 () and server challenge () 295 messages are text-based messages containing one or more attribute- 296 value pairs separated by commas. The messages and their attributes 297 are described below and defined in Section 7. 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-256" / "SCRAM-SHA-1" / other-scram-name 308 ; SCRAM-SHA-256 and SCRAM-SHA-1 are registered by this RFC. 309 ; 310 ; SCRAM-SHA-1 is registered for database compatibility 311 ; with implementations of RFC 5802 (such as IMAP or XMPP 312 ; servers), but it is not recommended for new deployments. 314 other-scram-name = "SCRAM-" hash-name 315 ; hash-name is a capitalized form of names from IANA 316 ; "Hash Function Textual Names" registry. 317 ; Additional SCRAM names must be registered in both 318 ; the IANA "SASL mechanisms" registry 319 ; and the IANA "authentication scheme" registry. 321 This is a simple example of a SCRAM-SHA-256 authentication exchange 322 (no support for channel bindings, as this feature is not currently 323 supported by HTTP). Username 'user' and password 'pencil' are used. 324 Note that long lines are folded for readability. 326 C: GET /resource HTTP/1.1 327 C: Host: server.example.com 328 C: [...] 330 S: HTTP/1.1 401 Unauthorized 331 S: WWW-Authenticate: Digest realm="realm1@example.com", 332 Digest realm="realm2@example.com", 333 Digest realm="realm3@example.com", 334 SCRAM-SHA-256 realm="realm3@example.com", 335 SCRAM-SHA-256 realm="testrealm@example.com" 336 S: [...] 338 C: GET /resource HTTP/1.1 339 C: Host: server.example.com 340 C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com", 341 data=biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8K 342 C: [...] 344 S: HTTP/1.1 401 Unauthorized 345 S: WWW-Authenticate: SCRAM-SHA-256 346 sid=AAAABBBBCCCCDDDD, 347 data=cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGo 348 paE5sRixzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYK 349 S: [...] 351 C: GET /resource HTTP/1.1 352 C: Host: server.example.com 353 C: Authorization: SCRAM-SHA-256 sid=AAAABBBBCCCCDDDD, 354 data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG 355 SWxqKWhObEYscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3FtbWl6 356 N0FuZFZRPQo= 357 C: [...] 359 S: HTTP/1.1 200 Ok 360 S: Authentication-Info: sid=AAAABBBBCCCCDDDD, 361 data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo= 362 S: [...Other header fields and resource body...] 364 In the above example the first client request contains data attribute 365 which base64 decodes as follows: "n,,n=user,r=rOprNGfwEbeRWgbNEkqO" 366 (with no quotes). Server then responds with data attribute which 367 base64 decodes as follows: "r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxF 368 Ilj)hNlF,s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096". The next client request 369 contains data attribute which base64 decodes as follows: "c=biws,r=rO 370 prNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF,p=dHzbZapWIk4jUhN+Ute9y 371 tag9zjfMHgsqmmiz7AndVQ=". The final server response contains a data 372 attribute which base64 decodes as follows: 374 "v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=". 376 Note that in the example above the client can also initiate SCRAM 377 authentication without first being prompted by the server. 379 Initial "SCRAM-SHA-256" authentication starts with sending the 380 "Authorization" request header field defined by HTTP/1.1, Part 7 381 [RFC7235] containing "SCRAM-SHA-256" authentication scheme and the 382 following attributes: 384 o A "realm" attribute MAY be included to indicate the scope of 385 protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. 386 As specified in [RFC7235], the "realm" attribute MUST NOT appear 387 more than once. The realm attribute only appears in the first 388 SCRAM message to the server and in the first SCRAM response from 389 the server. 391 o The client also includes the data attribute that contains base64 392 encoded "client-first-message" [RFC5802] containing: 394 * a header consisting of a flag indicating whether channel 395 binding is supported-but-not-used, not supported, or used . 396 Note that this version of SCRAM doesn't support HTTP channel 397 bindings, so this header always starts with "n"; otherwise the 398 message is invalid and authentication MUST fail. 400 * SCRAM username and a random, unique nonce attributes. 402 In HTTP response, the server sends WWW-Authenticate header field 403 containing: a unique session identifier (the "sid" attribute) plus 404 the "data" attribute containing base64-encoded "server-first-message" 405 [RFC5802]. The "server-first-message" contains the user's iteration 406 count i, the user's salt, and the nonce with a concatenation of the 407 client-specified one (taken from the "client-first-message") with a 408 freshly generated server nonce. 410 The client then responds with another HTTP request with the 411 Authorization header field, which includes the "sid" attribute 412 received in the previous server response, together with the "data" 413 attribute containing base64-encoded "client-final-message" data. The 414 latter has the same nonce as in "server-first-message" and a 415 ClientProof computed using the selected hash function (e.g. SHA-256) 416 as explained earlier. 418 The server verifies the nonce and the proof, and, finally, it 419 responds with a 200 HTTP response with the Authentication-Info header 420 field [RFC7615] containing the "sid" attribute (as received from the 421 client) and the "data" attribute containing base64-encoded "server- 422 final-message", concluding the authentication exchange. 424 The client then authenticates the server by computing the 425 ServerSignature and comparing it to the value sent by the server. If 426 the two are different, the client MUST consider the authentication 427 exchange to be unsuccessful and it might have to drop the connection. 429 5.1. One round trip reauthentication 431 If the server supports SCRAM reauthentication, the server sends in 432 its initial HTTP response a WWW-Authenticate header field containing: 433 the "realm" attribute (as defined earlier), the "sr" attribute that 434 contains the server part of the "r" attribute (see s-nonce in 435 [RFC5802]) and optional "ttl" attribute (which contains the "sr" 436 value validity in seconds). 438 If the client has authenticated to the same realm before (i.e. it 439 remembers "i" and "s" attributes for the user from earlier 440 authentication exchanges with the server), it can respond to that 441 with "client-final-message". When constructing the "client-final- 442 message" the client constructs the c-nonce part of the "r" attribute 443 as on initial authentication and the s-nonce part as follows: s-nonce 444 is a concatenation of nonce-count and the "sr" attribute (in that 445 order). The nonce-count is a positive integer that that is equal to 446 the user's "i" attribute on first reauthentication and is incremented 447 by 1 on each successful re-authentication. 449 The purpose of the nonce-count is to allow the server to detect 450 request replays by maintaining its own copy of this count - if the 451 same nonce-count value is seen twice, then the request is a 452 replay. 454 If the server considers the s-nonce part of the nonce attribute (the 455 "r" attribute) to be still valid (i.e. the nonce-count part is as 456 expected (see above) and the "sr" part is still fresh), it will 457 provide access to the requested resource (assuming the client hash 458 verifies correctly, of course). However if the server considers that 459 the server part of the nonce is stale (for example if the "sr" value 460 is used after the "ttl" seconds), the server returns "401 461 Unauthorized" containing the SCRAM mechanism name with the following 462 attributes: a new "sr", "stale=true" and an optional "ttl". The 463 "stale" attribute signals to the client that there is no need to ask 464 user for the password. 466 Formally, the "stale" attribute is defined as follows: A flag, 467 indicating that the previous request from the client was rejected 468 because the nonce value was stale. If stale is TRUE (case- 469 insensitive), the client may wish to simply retry the request with 470 a new encrypted response, without reprompting the user for a new 471 username and password. The server should only set stale to TRUE 472 if it receives a request for which the nonce is invalid but with a 473 valid digest for that nonce (indicating that the client knows the 474 correct username/password). If stale is FALSE, or anything other 475 than TRUE, or the stale directive is not present, the username 476 and/or password are invalid, and new values must be obtained. 478 When constructing AuthMessage Section 3 to be used for calculating 479 client and server proofs, "client-first-message-bare" and "server- 480 first-message" are reconstructed from data known to the client and 481 the server. 483 Reauthentication can look like this: 485 C: GET /resource HTTP/1.1 486 C: Host: server.example.com 487 C: [...] 489 S: HTTP/1.1 401 Unauthorized 490 S: WWW-Authenticate: Digest realm="realm1@example.com", 491 Digest realm="realm2@example.com", 492 Digest realm="realm3@example.com", 493 SCRAM-SHA-256 realm="realm3@example.com", 494 SCRAM-SHA-256 realm="testrealm@example.com", sr=%hvYDpWUa2RaTCAfuxFIlj)hNlF 495 SCRAM-SHA-256 realm="testrealm2@example.com", sr=AAABBBCCCDDD, ttl=120 496 S: [...] 498 [Client authenticates as usual to realm "testrealm@example.com"] 500 [Some time later client decides to reauthenticate. 501 It will use the cached "i" (4096) and "s" (W22ZaJ0SNY7soEsUEjb6gQ==) 502 from earlier exchanges. It will use the nonce-value of 4096 together 503 with the server advertised "sr" value as the server part of the "r".] 505 C: GET /resource HTTP/1.1 506 C: Host: server.example.com 507 C: Authorization: SCRAM-SHA-256 realm="testrealm@example.com", 508 data=Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU80MDk2JWh2WURwV1VhMlJhVENB 509 ZnV4RklsailoTmxGLHA9ZEh6YlphcFdJazRqVWhOK1V0ZTl5dGFnOXpqZk1IZ3Nx 510 bW1pejdBbmRWUT0K 512 C: [...] 514 S: HTTP/1.1 200 Ok 515 S: Authentication-Info: sid=AAAABBBBCCCCDDDD, 516 data=dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQo= 517 S: [...Other header fields and resource body...] 519 6. Use of Authentication-Info header field with SCRAM 521 When used with SCRAM, the Authentication-Info header field is allowed 522 in the trailer of an HTTP message transferred via chunked transfer- 523 coding. 525 7. Formal Syntax 527 The following syntax specification uses the Augmented Backus-Naur 528 Form (ABNF) notation as specified in [RFC5234]. 530 ALPHA = 531 DIGIT = 533 base64-char = ALPHA / DIGIT / "/" / "+" 535 base64-4 = 4base64-char 537 base64-3 = 3base64-char "=" 539 base64-2 = 2base64-char "==" 541 base64 = *base64-4 [base64-3 / base64-2] 543 sr = "sr=" s-nonce 544 ;; s-nonce is defined in RFC 5802. 546 data = "data=" base64 547 ;; The data attribute value is base64 encoded 548 ;; SCRAM challenge or response defined in 549 ;; RFC 5802. 551 ttl = "ttl" = 1*DIGIT 552 ;; "sr" value validity in seconds. 553 ;; No leading 0s. 555 reauth-s-nonce = nonce-count s-nonce 557 nonce-count = posit-number 558 ;; posit-number is defined in RFC 5802. 559 ;; The initial value is taken from the "i" 560 ;; attribute for the user and is incremented 561 ;; by 1 on each successful re-authentication. 563 sid = "sid=" token 564 ;; See token definition in RFC 7235. 566 stale = "stale=" ( "true" / "false" ) 568 realm = "realm=" 570 8. Security Considerations 572 If the authentication exchange is performed without a strong session 573 encryption (such as TLS with data confidentiality), then a passive 574 eavesdropper can gain sufficient information to mount an offline 575 dictionary or brute-force attack which can be used to recover the 576 user's password. The amount of time necessary for this attack 577 depends on the cryptographic hash function selected, the strength of 578 the password and the iteration count supplied by the server. SCRAM 579 allows the server/server administrator to increase the iteration 580 count over time in order to slow down the above attacks. (Note that 581 a server that is only in posession of "StoredKey" and "ServerKey" 582 can't automatic increase the iteration count upon successful 583 authentication. Such increase would require resetting user's 584 password.) An external security layer with strong encryption will 585 prevent these attack. 587 If the authentication information is stolen from the authentication 588 database, then an offline dictionary or brute-force attack can be 589 used to recover the user's password. The use of salt mitigates this 590 attack somewhat by requiring a separate attack on each password. 591 Authentication mechanisms which protect against this attack are 592 available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is 593 an example of such technology. 595 If an attacker obtains the authentication information from the 596 authentication repository and either eavesdrops on one authentication 597 exchange or impersonates a server, the attacker gains the ability to 598 impersonate that user to all servers providing SCRAM access using the 599 same hash function, password, iteration count and salt. For this 600 reason, it is important to use randomly-generated salt values. 602 SCRAM does not negotiate a hash function to use. Hash function 603 negotiation is left to the HTTP authentication mechanism negotiation. 604 It is important that clients be able to sort a locally available list 605 of mechanisms by preference so that the client may pick the most 606 preferred of a server's advertised mechanism list. This preference 607 order is not specified here as it is a local matter. The preference 608 order should include objective and subjective notions of mechanism 609 cryptographic strength (e.g., SCRAM with SHA-256 should be preferred 610 over SCRAM with SHA-1). 612 This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1 613 is registered for database compatibility with implementations of RFC 614 5802 (such as IMAP or XMPP servers) which want to also expose HTTP 615 access to a related service, but it is not recommended for new 616 deployments. 618 A hostile server can perform a computational denial-of-service attack 619 on clients by sending a big iteration count value. In order to 620 defend against that, a client implementation can pick a maximum 621 iteration count that it is willing to use, and that it rejects any 622 values that exceed that threshold (in such cases the client, of 623 course, has to fail the authentication). 625 See [RFC4086] for more information about generating randomness. 627 9. IANA Considerations 629 New mechanisms in the SCRAM- family are registered according to the 630 IANA procedure specified in [RFC5802]. 632 Note to future SCRAM- mechanism designers: each new SCRAM- HTTP 633 authentication mechanism MUST be explicitly registered with IANA and 634 MUST comply with SCRAM- mechanism naming convention defined in 635 Section 4 of this document. 637 IANA is requested to add the following entry to the Authentication 638 Scheme Registry defined in HTTP/1.1, Part 7 [RFC7235]: 640 Authentication Scheme Name: SCRAM-SHA-256 641 Pointer to specification text: [[ this document ]] 642 Notes (optional): (none) 644 Authentication Scheme Name: SCRAM-SHA-1 645 Pointer to specification text: [[ this document ]] 646 Notes (optional): (none) 648 10. Acknowledgements 650 This document benefited from discussions on the HTTPAuth, SASL and 651 Kitten WG mailing lists. The authors would like to specially thank 652 co-authors of [RFC5802] from which lots of text was copied. 654 Thank you to Martin Thomson for the idea of adding "ttl" attribute. 656 Thank you to Julian F. Reschke for corrections regarding use of 657 Authentication-Info header field. 659 Special thank you to Tony Hansen for doing an early implementation 660 and providing extensive comments on the draft. 662 Thank you to Russ Housley, Stephen Farrell, Barry Leiba and Tim Chown 663 for doing detailed reviews of the document. 665 11. Design Motivations 667 The following design goals shaped this document. Note that some of 668 the goals have changed since the initial version of the document. 670 o The HTTP authentication mechanism has all modern features: support 671 for internationalized usernames and passwords. 673 o The protocol supports mutual authentication. 675 o The authentication information stored in the authentication 676 database is not sufficient by itself to impersonate the client. 678 o The server does not gain the ability to impersonate the client to 679 other servers (with an exception for server-authorized proxies), 680 unless such other servers allow SCRAM authentication and use the 681 same salt and iteration count for the user. 683 o The mechanism is extensible, but [hopefully] not overengineered in 684 this respect. 686 o Easier to implement than HTTP Digest in both clients and servers. 688 o The protocol supports 1 round trip reauthentication. 690 12. References 692 12.1. Normative References 694 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 695 Hashing for Message Authentication", RFC 2104, 696 DOI 10.17487/RFC2104, February 1997, 697 . 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, 701 DOI 10.17487/RFC2119, March 1997, 702 . 704 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 705 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 706 2003, . 708 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 709 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 710 . 712 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 713 Specifications: ABNF", STD 68, RFC 5234, 714 DOI 10.17487/RFC5234, January 2008, 715 . 717 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 718 "Salted Challenge Response Authentication Mechanism 719 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 720 DOI 10.17487/RFC5802, July 2010, 721 . 723 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 724 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 725 DOI 10.17487/RFC6234, May 2011, 726 . 728 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 729 Protocol (HTTP/1.1): Authentication", RFC 7235, 730 DOI 10.17487/RFC7235, June 2014, 731 . 733 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 734 Enforcement, and Comparison of Internationalized Strings 735 Representing Usernames and Passwords", RFC 7613, 736 DOI 10.17487/RFC7613, August 2015, 737 . 739 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 740 Authentication-Info Response Header Fields", RFC 7615, 741 DOI 10.17487/RFC7615, September 2015, 742 . 744 [RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple 745 Authentication and Security Layer (SASL) Mechanisms", 746 RFC 7677, DOI 10.17487/RFC7677, November 2015, 747 . 749 12.2. Informative References 751 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 752 "Remote Authentication Dial In User Service (RADIUS)", 753 RFC 2865, DOI 10.17487/RFC2865, June 2000, 754 . 756 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 757 Specification Version 2.0", RFC 2898, 758 DOI 10.17487/RFC2898, September 2000, 759 . 761 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 762 RFC 2945, DOI 10.17487/RFC2945, September 2000, 763 . 765 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 766 "Randomness Requirements for Security", BCP 106, RFC 4086, 767 DOI 10.17487/RFC4086, June 2005, 768 . 770 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 771 (LDAP): Technical Specification Road Map", RFC 4510, 772 DOI 10.17487/RFC4510, June 2006, 773 . 775 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 776 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 777 . 779 [RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331, 780 DOI 10.17487/RFC6331, July 2011, 781 . 783 Author's Address 785 Alexey Melnikov 786 Isode Ltd 788 Email: Alexey.Melnikov@isode.com