idnits 2.17.1 draft-ietf-httpauth-scram-auth-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 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 (July 4, 2014) is 3585 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 851, but no explicit reference was found in the text == Unused Reference: 'RFC4616' is defined on line 876, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC5803' is defined on line 893, 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 July 4, 2014 5 Expires: January 5, 2015 7 Salted Challenge Response (SCRAM) HTTP Authentication Mechanism 8 draft-ietf-httpauth-scram-auth-03.txt 10 Abstract 12 The secure authentication mechanism most widely deployed and used by 13 Internet application protocols is the transmission of clear-text 14 passwords over a channel protected by Transport Layer Security (TLS). 15 There are some significant security concerns with that mechanism, 16 which could be addressed by the use of a challenge response 17 authentication mechanism protected by TLS. Unfortunately, the HTTP 18 Digest challenge response mechanism presently on the standards track 19 failed widespread deployment, and have had success only in limited 20 use. 22 This specification describes a family of HTTP authentication 23 mechanisms called the Salted Challenge Response Authentication 24 Mechanism (SCRAM), which addresses the security concerns and meets 25 the deployability requirements. When used in combination with TLS or 26 an equivalent security layer, a mechanism from this family could 27 improve the status-quo for application protocol authentication. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 5, 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. Example reauthentication . . . . . . . . . . . . . . . . . 9 71 5.2. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 10 72 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 76 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 17 77 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 12. Internet-Draft Change History . . . . . . . . . . . . . . . . 18 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 81 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 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, i.e. an 284 authentication mechanism from the SCRAM family that uses the SHA-1 285 hash function as defined in [RFC3174]. 287 5. SCRAM Authentication Exchange 289 SCRAM is a HTTP Authentication mechanism whose client response 290 () and server challenge () 291 messages are text-based messages containing one or more attribute- 292 value pairs separated by commas. Each attribute has a one-letter 293 name, with the exception of a couple of attributes which are generic 294 to HTTP authentication, such as "realm" (and "sid"). The messages 295 and their attributes are described in Section 5.2, and defined in 296 Section 6. 298 challenge-scram = scram-name [1*SP 1#auth-param] 299 ; Complies with ABNF from RFC 7235. 300 ; Included in the WWW-Authenticate header field. 302 credentials-scram = scram-name [1*SP 1#auth-param] 303 ; Complies with from RFC 7235. 304 ; Included in the Authorization header field. 306 scram-name = "SCRAM-SHA-1" / other-scram-name 307 ; SCRAM-SHA-1 is registered by this RFC 308 other-scram-name = "SCRAM-" hash-name 309 ; hash-name is a capitalized form of names from IANA 310 ; "Hash Function Textual Names" registry. 311 ; Additional SCRAM names must be registered in both 312 ; the IANA "SASL mechanisms" registry 313 ; and the IANA "authentication scheme" registry. 315 This is a simple example of a SCRAM-SHA-1 authentication exchange 316 when the client doesn't support channel bindings (username 'user' and 317 password 'pencil' are used): 319 C: GET /resource HTTP/1.1 320 C: Host: server.example.com 321 C: [...] 323 S: HTTP/1.1 401 Unauthorized 324 S: WWW-Authenticate: Digest realm="realm1@host.com", 325 Digest realm="realm2@host.com", 326 Digest realm="realm3@host.com", 327 SCRAM-SHA-1 realm="realm3@host.com", 328 SCRAM-SHA-1 realm="testrealm@host.com" 329 S: [...] 331 C: GET /resource HTTP/1.1 332 C: Host: server.example.com 333 C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", 334 g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL 335 C: [...] 337 S: HTTP/1.1 401 Unauthorized 338 S: WWW-Authenticate: SCRAM-SHA-1 339 sid=AAAABBBBCCCCDDDD,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 340 s=QSXCR+Q6sek8bf92,i=4096 341 S: [...] 343 C: GET /resource HTTP/1.1 344 C: Host: server.example.com 345 C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, 346 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 347 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 348 C: [...] 350 S: HTTP/1.1 200 Ok 351 S: Authentication-Info: SCRAM-SHA-1 352 sid=AAAABBBBCCCCDDDD, 353 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 354 S: [...Other header fields and resource body...] 356 Note that in the example above the client can also initiate SCRAM 357 authentication without first being prompted by the server. 359 "SCRAM-SHA-1" authentication starts with sending the "Authorization" 360 request header field defined by HTTP/1.1, Part 7 [RFC7235] containing 361 "SCRAM-SHA-1" authentication scheme and the following attributes: 363 o A "realm" attribute MAY be included to indicate the scope of 364 protection in the manner described in HTTP/1.1, Part 7 [RFC7235]. 365 As specified in [RFC7235], the "realm" attribute MUST NOT appear 366 more than once. The realm attribute only appears in the first 367 SCRAM message to the server and in the first SCRAM response from 368 the server. 370 o The client also includes the "client-first-message" containing: 372 * a header ("g" attribute) consisting of a flag indicating 373 whether channel binding is supported-but-not-used, not 374 supported, or used . Note that the "g" attribute always starts 375 with "n", "y" or "p", otherwise the message is invalid and 376 authentication MUST fail. 378 * SCRAM username and a random, unique nonce attributes. 380 In HTTP response, the server sends WWW-Authenticate header field 381 containing: a unique session identifier (the "sid" attribute) plus 382 the "server-first-message" containing the user's iteration count i, 383 the user's salt, and the nonce with a concatenation of the client- 384 specified one with a server nonce. [[CREF1: OPEN ISSUE: 385 Alternatively, the "sid" attribute can be another header field.]] 387 The client then responds with another HTTP request with the 388 Authorization header field, which includes the "sid" attribute 389 received in the previous server response, together with "client- 390 final-message" data. The latter has the same nonce and a ClientProof 391 computed using the selected hash function (SHA-1) as explained 392 earlier. 394 The server verifies the nonce and the proof, and, finally, it 395 responds with a 200 HTTP response with the Authentication-Info header 396 field containing "server-final-message", concluding the 397 authentication exchange. 399 The client then authenticates the server by computing the 400 ServerSignature and comparing it to the value sent by the server. If 401 the two are different, the client MUST consider the authentication 402 exchange to be unsuccessful and it might have to drop the connection. 404 5.1. Example reauthentication 406 If the server supports SCRAM reauthentication, reauthentication can 407 look like this: 409 C: GET /resource HTTP/1.1 410 C: Host: server.example.com 411 C: [...] 413 S: HTTP/1.1 401 Unauthorized 414 S: WWW-Authenticate: Digest realm="realm1@host.com", 415 Digest realm="realm2@host.com", 416 Digest realm="realm3@host.com", 417 SCRAM-SHA-1 realm="realm3@host.com", 418 SCRAM-SHA-1 realm="testrealm@host.com", sr=3rfcNHYJY1ZVvWVs7j 419 S: [...] 421 [Client authenticates as usual.] 423 [Some time later client decides to reauthenticate. 424 It will use the cached "i" and "s" from earlies exchanges. 425 It will use the server advertised "sr" value as the server part of the "r". 426 Should some counter be added to make "sr" unique for each reauth???] 428 C: GET /resource HTTP/1.1 429 C: Host: server.example.com 430 C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", 431 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 432 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 433 C: [...] 435 S: HTTP/1.1 200 Ok 436 S: Authentication-Info: SCRAM-SHA-1 437 sid=AAAABBBBCCCCDDDD, 438 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 439 S: [...Other header fields and resource body...] 441 5.2. SCRAM Attributes 443 This section describes the permissible attributes, their use, and the 444 format of their values. All attribute names are single US-ASCII 445 letters and are case-sensitive. 447 Note that the order of attributes in client or server messages is 448 fixed, with the exception of extension attributes (described by the 449 "extensions" ABNF production), which can appear in any order in the 450 designated positions. See the ABNF section for authoritative 451 reference. 453 o g: This attribute value consist of a flag indicating whether 454 channel binding is supported-but-not-used, not supported, or used 455 . 457 o n: This attribute specifies the name of the user whose password is 458 used for authentication. A client MUST include it in its first 459 message to the server. 461 Before sending the username to the server, the client SHOULD 462 prepare the username using the "SASLPrep" profile [RFC4013] of 463 the "stringprep" algorithm [RFC3454] treating it as a query 464 string (i.e., unassigned Unicode code points are allowed). If 465 the preparation of the username fails or results in an empty 466 string, the client SHOULD abort the authentication exchange 467 (*). 469 (*) An interactive client can request a repeated entry of the 470 username value. 472 Upon receipt of the username by the server, the server MUST 473 either prepare it using the "SASLPrep" profile [RFC4013] of the 474 "stringprep" algorithm [RFC3454] treating it as a query string 475 (i.e., unassigned Unicode codepoints are allowed) or otherwise 476 be prepared to do SASLprep-aware string comparisons and/or 477 index lookups. If the preparation of the username fails or 478 results in an empty string, the server SHOULD abort the 479 authentication exchange. Whether or not the server prepares 480 the username using "SASLPrep", it MUST use it as received in 481 hash calculations. 483 The characters ',' or '=' in usernames are sent as '=2C' and 484 '=3D' respectively. If the server receives a username which 485 contains '=' not followed by either '2C' or '3D', then the 486 server MUST fail the authentication. 488 o m: This attribute is reserved for future extensibility. In this 489 version of SCRAM, its presence in a client or a server message 490 MUST cause authentication failure when the attribute is parsed by 491 the other end. 493 o r: This attribute specifies a sequence of random printable ASCII 494 characters excluding ',' which forms the nonce used as input to 495 the hash function. No quoting is applied to this string. As 496 described earlier, the client supplies an initial value in its 497 first message, and the server augments that value with its own 498 nonce in its first response. It is important that this value be 499 different for each authentication (see [RFC4086] for more details 500 on how to achieve this). The client MUST verify that the initial 501 part of the nonce used in subsequent messages is the same as the 502 nonce it initially specified. The server MUST verify that the 503 nonce sent by the client in the second message is the same as the 504 one sent by the server in its first message. 506 o c: This REQUIRED attribute specifies the base64-encoded GS2 header 507 and channel-binding data. It is sent by the client in its second 508 authentication message. The attribute data consist of: 510 * the GS2 header from the client's first message (recall that the 511 GS2 header contains a channel binding flag ). This header is 512 going to include channel binding type prefix (see [RFC5056]), 513 if and only if the client is using channel binding; 515 * followed by the external channel's channel binding data, if and 516 only if the client is using channel binding. 518 o s: This attribute specifies the base64-encoded salt used by the 519 server for this user. It is sent by the server in its first 520 message to the client. 522 o i: This attribute specifies an iteration count for the selected 523 hash function and user, and MUST be sent by the server along with 524 the user's salt. 526 For SCRAM-SHA-1 authentication mechanism servers SHOULD 527 announce a hash iteration-count of at least 4096. Note that a 528 client implementation MAY cache ClientKey&ServerKey (or just 529 SaltedPassword) for later reauthentication to the same service, 530 as it is likely that the server is going to advertise the same 531 salt value upon reauthentication. This might be useful for 532 mobile clients where CPU usage is a concern. 534 o p: This attribute specifies a base64-encoded ClientProof. The 535 client computes this value as described in the overview and sends 536 it to the server. 538 o v: This attribute specifies a base64-encoded ServerSignature. It 539 is sent by the server in its final message, and is used by the 540 client to verify that the server has access to the user's 541 authentication information. This value is computed as explained 542 in the overview. 544 6. Formal Syntax 546 The following syntax specification uses the Augmented Backus-Naur 547 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 548 and "UTF8-4" non-terminal are defined in [RFC3629]. 550 ALPHA = 551 DIGIT = 552 UTF8-2 = 553 UTF8-3 = 554 UTF8-4 = 556 attr-val = ALPHA "=" value 557 ;; Generic syntax of any attribute sent 558 ;; by server or client 560 value = 1*value-char 562 value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / 563 UTF8-2 / UTF8-3 / UTF8-4 564 ;; UTF8-char except NUL, "=", and ",". 566 value-char = value-safe-char / "=" 568 printable = %x21-2B / %x2D-7E 569 ;; Printable ASCII except ",". 570 ;; Note that any "printable" is also 571 ;; a valid "value". 573 base64-char = ALPHA / DIGIT / "/" / "+" 575 base64-4 = 4base64-char 577 base64-3 = 3base64-char "=" 579 base64-2 = 2base64-char "==" 581 base64 = *base64-4 [base64-3 / base64-2] 583 posit-number = %x31-39 *DIGIT 584 ;; A positive number. 586 cb-name = 1*(ALPHA / DIGIT / "." / "-") 587 ;; See RFC 5056, Section 7. 588 ;; E.g., "tls-server-end-point" or 589 ;; "tls-unique". 591 gs2-cbind-flag = ("p=" cb-name) / "n" / "y" 592 ;; "n" -> client doesn't support channel binding. 593 ;; "y" -> client does support channel binding 594 ;; but thinks the server does not. 595 ;; "p" -> client requires channel binding. 596 ;; The selected channel binding follows "p=". 598 gs2-header = gs2-cbind-flag "," 599 ;; GS2 header for SCRAM. 601 username = "n=" 1*(value-safe-char / "=2C" / "=3D") 602 ;; Conforms to . 603 ;; Usernames are prepared using SASLPrep. 605 reserved-mext = "m=" 1*(value-char) 606 ;; Reserved for signaling mandatory extensions. 607 ;; The exact syntax will be defined in 608 ;; the future. 610 channel-binding = "c=" base64 611 ;; base64 encoding of cbind-input. 613 proof = "p=" base64 615 nonce = "r=" c-nonce [s-nonce] 616 ;; Second part provided by server. 618 c-nonce = printable 620 s-nonce = printable 622 salt = "s=" base64 624 verifier = "v=" base64 625 ;; base-64 encoded ServerSignature. 627 iteration-count = "i=" posit-number 628 ;; A positive number. 630 client-first-message-bare = 631 [reserved-mext ","] 632 username "," nonce ["," extensions] 634 client-first-message = 635 "g=" gs2-header client-first-message-bare 636 ;; Note that this doesn't include "realm" and 637 ;; other generic HTTP directives. 639 server-first-message = 640 [reserved-mext ","] nonce "," salt "," 641 iteration-count ["," extensions] 642 ;; Note that this doesn't include "realm", "sid" and 643 ;; other generic HTTP directives. 645 client-final-message-without-proof = 646 channel-binding "," nonce ["," 647 extensions] 649 client-final-message = 650 client-final-message-without-proof "," proof 651 ;; Note that this doesn't include "sid" and 652 ;; other generic HTTP directives. 654 server-error = "e=" server-error-value 656 server-error-value = "invalid-encoding" / 657 "extensions-not-supported" / ; unrecognized 'm' value 658 "invalid-proof" / 659 "channel-bindings-dont-match" / 660 "server-does-support-channel-binding" / 661 ; server does not support channel binding 662 "channel-binding-not-supported" / 663 "unsupported-channel-binding-type" / 664 "unknown-user" / 665 "invalid-username-encoding" / 666 ; invalid username encoding (invalid UTF-8 or 667 ; SASLprep failed) 668 "no-resources" / 669 "other-error" / 670 server-error-value-ext 671 ; Unrecognized errors should be treated as "other-error". 672 ; In order to prevent information disclosure, the server 673 ; may substitute the real reason with "other-error". 675 server-error-value-ext = value 676 ; Additional error reasons added by extensions 677 ; to this document. 679 server-final-message = (server-error / verifier) 680 ["," extensions] 682 extensions = attr-val *("," attr-val) 683 ;; All extensions are optional, 684 ;; i.e., unrecognized attributes 685 ;; not defined in this document 686 ;; MUST be ignored. 688 cbind-data = 1*OCTET 690 cbind-input = gs2-header [ cbind-data ] 691 ;; cbind-data MUST be present for 692 ;; gs2-cbind-flag of "p" and MUST be absent 693 ;; for "y" or "n". 695 7. Security Considerations 697 If the authentication exchange is performed without a strong security 698 layer (such as TLS with data confidentiality), then a passive 699 eavesdropper can gain sufficient information to mount an offline 700 dictionary or brute-force attack which can be used to recover the 701 user's password. The amount of time necessary for this attack 702 depends on the cryptographic hash function selected, the strength of 703 the password and the iteration count supplied by the server. An 704 external security layer with strong encryption will prevent this 705 attack. 707 If the external security layer used to protect the SCRAM exchange 708 uses an anonymous key exchange, then the SCRAM channel binding 709 mechanism can be used to detect a man-in-the-middle attack on the 710 security layer and cause the authentication to fail as a result. 711 However, the man-in-the-middle attacker will have gained sufficient 712 information to mount an offline dictionary or brute-force attack. 713 For this reason, SCRAM allows to increase the iteration count over 714 time. (Note that a server that is only in posession of "StoredKey" 715 and "ServerKey" can't automatic increase the iteration count upon 716 successful authentication. Such increase would require resetting 717 user's password.) 719 If the authentication information is stolen from the authentication 720 database, then an offline dictionary or brute-force attack can be 721 used to recover the user's password. The use of salt mitigates this 722 attack somewhat by requiring a separate attack on each password. 723 Authentication mechanisms which protect against this attack are 724 available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is 725 an example of such technology. 727 If an attacker obtains the authentication information from the 728 authentication repository and either eavesdrops on one authentication 729 exchange or impersonates a server, the attacker gains the ability to 730 impersonate that user to all servers providing SCRAM access using the 731 same hash function, password, iteration count and salt. For this 732 reason, it is important to use randomly-generated salt values. 734 SCRAM does not negotiate a hash function to use. Hash function 735 negotiation is left to the HTTP authentication mechanism negotiation. 736 It is important that clients be able to sort a locally available list 737 of mechanisms by preference so that the client may pick the most 738 preferred of a server's advertised mechanism list. This preference 739 order is not specified here as it is a local matter. The preference 740 order should include objective and subjective notions of mechanism 741 cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be 742 preferred over SCRAM with SHA-1). 744 SCRAM does not protect against downgrade attacks of channel binding 745 types. The complexities of negotiation a channel binding type, and 746 handling down-grade attacks in that negotiation, was intentionally 747 left out of scope for this document. 749 A hostile server can perform a computational denial-of-service attack 750 on clients by sending a big iteration count value. 752 See [RFC4086] for more information about generating randomness. 754 8. IANA Considerations 756 New mechanisms in the SCRAM- family are registered according to the 757 IANA procedure specified in [RFC5802]. 759 Note to future SCRAM- mechanism designers: each new SCRAM- HTTP 760 authentication mechanism MUST be explicitly registered with IANA and 761 MUST comply with SCRAM- mechanism naming convention defined in 762 Section 4 of this document. 764 IANA is requested to add the following entry to the Authentication 765 Scheme Registry defined in HTTP/1.1, Part 7 [RFC7235]: 767 Authentication Scheme Name: SCRAM-SHA-1 768 Pointer to specification text: [[ this document ]] 769 Notes (optional): (none) 771 9. Acknowledgements 773 This document benefited from discussions on the HTTPAuth, SASL and 774 Kitten WG mailing lists. The authors would like to specially thank 775 co-authors of [RFC5802] from which lots of text was copied. 777 Special thank you to Tony Hansen for doing an early implementation 778 and providing extensive comments on the draft. 780 10. Design Motivations 782 The following design goals shaped this document. Note that some of 783 the goals have changed since the initial version of the document. 785 o The HTTP authentication mechanism has all modern features: support 786 for internationalized usernames and passwords, support for channel 787 bindings. 789 o The protocol supports mutual authentication. 791 o The authentication information stored in the authentication 792 database is not sufficient by itself to impersonate the client. 794 o The server does not gain the ability to impersonate the client to 795 other servers (with an exception for server-authorized proxies), 796 unless such other servers allow SCRAM authentication and use the 797 same salt and iteration count for the user. 799 o The mechanism is extensible, but [hopefully] not overengineered in 800 this respect. 802 o Easier to implement than HTTP Digest in both clients and servers. 804 11. Open Issues 806 It should be possible to construct a quick reauthentication version 807 of the mechanism that uses fewer round-trips (similar to what Digest 808 has). 810 12. Internet-Draft Change History 812 (RFC Editor: Please delete this section and all subsections.) 814 Changes since -00 816 o 818 13. References 820 13.1. Normative References 822 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 823 Hashing for Message Authentication", RFC 2104, February 824 1997. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, March 1997. 829 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 830 (SHA1)", RFC 3174, September 2001. 832 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 833 Internationalized Strings ("stringprep")", RFC 3454, 834 December 2002. 836 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 837 10646", STD 63, RFC 3629, November 2003. 839 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 840 and Passwords", RFC 4013, February 2005. 842 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 843 Encodings", RFC 4648, October 2006. 845 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 846 Channels", RFC 5056, November 2007. 848 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 849 Specifications: ABNF", STD 68, RFC 5234, January 2008. 851 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 852 for TLS", RFC 5929, July 2010. 854 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 855 (HTTP/1.1): Authentication", RFC 7235, June 2014. 857 13.2. Informative References 859 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 860 "Remote Authentication Dial In User Service (RADIUS)", RFC 861 2865, June 2000. 863 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 864 Specification Version 2.0", RFC 2898, September 2000. 866 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 867 RFC 2945, September 2000. 869 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 870 Requirements for Security", BCP 106, RFC 4086, June 2005. 872 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 873 (LDAP): Technical Specification Road Map", RFC 4510, June 874 2006. 876 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 877 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 879 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 880 4949, August 2007. 882 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 883 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 884 May 2008. 886 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 887 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 889 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 890 "Salted Challenge Response Authentication Mechanism 891 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 893 [RFC5803] Melnikov, A., "Lightweight Directory Access Protocol 894 (LDAP) Schema for Storing Salted Challenge Response 895 Authentication Mechanism (SCRAM) Secrets", RFC 5803, July 896 2010. 898 [tls-server-end-point] 899 Zhu, L., , "Registration of TLS server end-point channel 900 bindings", IANA http://www.iana.org/assignments/ 901 channel-binding-types/tls-server-end-point, July 2008. 903 Author's Address 905 Alexey Melnikov 906 Isode Ltd 908 Email: Alexey.Melnikov@isode.com