idnits 2.17.1 draft-ietf-httpauth-scram-auth-01.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 6 instances of too long lines in the document, the longest one being 12 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2013) is 3844 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 792, but no explicit reference was found in the text == Unused Reference: 'RFC4616' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RFC5803' is defined on line 831, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-22 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAUTH A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track October 18, 2013 5 Expires: April 21, 2014 7 Salted Challenge Response (SCRAM) HTTP Authentication Mechanism 8 draft-ietf-httpauth-scram-auth-01.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 April 21, 2014. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Conventions Used in This Document . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5 68 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6 69 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 70 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 9 71 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 75 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 16 76 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 12. Internet-Draft Change History . . . . . . . . . . . . . . . . 16 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 80 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Conventions Used in This Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 Formal syntax is defined by [RFC5234] including the core rules 90 defined in Appendix B of [RFC5234]. 92 Example lines prefaced by "C:" are sent by the client and ones 93 prefaced by "S:" by the server. If a single "C:" or "S:" label 94 applies to multiple lines, then the line breaks between those lines 95 are for editorial clarity only, and are not part of the actual 96 protocol exchange. 98 1.1. Terminology 100 This document uses several terms defined in [RFC4949] ("Internet 101 Security Glossary") including the following: authentication, 102 authentication exchange, authentication information, brute force, 103 challenge-response, cryptographic hash function, dictionary attack, 104 eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, 105 one-way encryption function, password, replay attack and salt. 106 Readers not familiar with these terms should use that glossary as a 107 reference. 109 Some clarifications and additional definitions follow: 111 o Authentication information: Information used to verify an identity 112 claimed by a SCRAM client. The authentication information for a 113 SCRAM identity consists of salt, iteration count, the "StoredKey" 114 and "ServerKey" (as defined in the algorithm overview) for each 115 supported cryptographic hash function. 117 o Authentication database: The database used to look up the 118 authentication information associated with a particular identity. 119 For application protocols, LDAPv3 (see [RFC4510]) is frequently 120 used as the authentication database. For network-level protocols 121 such as PPP or 802.11x, the use of RADIUS [RFC2865] is more 122 common. 124 o Base64: An encoding mechanism defined in [RFC4648] which converts 125 an octet string input to a textual output string which can be 126 easily displayed to a human. The use of base64 in SCRAM is 127 restricted to the canonical form with no whitespace. 129 o Octet: An 8-bit byte. 131 o Octet string: A sequence of 8-bit bytes. 133 o Salt: A random octet string that is combined with a password 134 before applying a one-way encryption function. This value is used 135 to protect passwords that are stored in an authentication 136 database. 138 1.2. Notation 140 The pseudocode description of the algorithm uses the following 141 notations: 143 o ":=": The variable on the left hand side represents the octet 144 string resulting from the expression on the right hand side. 146 o "+": Octet string concatenation. 148 o "[ ]": A portion of an expression enclosed in "[" and "]" may not 149 be included in the result under some circumstances. See the 150 associated text for a description of those circumstances. 152 o Normalize(str): Apply the SASLPrep profile [RFC4013] of the 153 "stringprep" algorithm [RFC3454] as the normalization algorithm to 154 a UTF-8 [RFC3629] encoded "str". The resulting string is also in 155 UTF-8. When applying SASLPrep, "str" is treated as a "stored 156 strings", which means that unassigned Unicode codepoints are 157 prohibited (see Section 7 of [RFC3454]). Note that 158 implementations MUST either implement SASLPrep, or disallow use of 159 non US-ASCII Unicode codepoints in "str". 161 o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in 162 [RFC2104]) using the octet string represented by "key" as the key 163 and the octet string "str" as the input string. The size of the 164 result is the hash result size for the hash function in use. For 165 example, it is 20 octets for SHA-1 (see [RFC3174]). 167 o H(str): Apply the cryptographic hash function to the octet string 168 "str", producing an octet string as a result. The size of the 169 result depends on the hash result size for the hash function in 170 use. 172 o XOR: Apply the exclusive-or operation to combine the octet string 173 on the left of this operator with the octet string on the right of 174 this operator. The length of the output and each of the two 175 inputs will be the same for this use. 177 o Hi(str, salt, i): 179 U1 := HMAC(str, salt + INT(1)) 180 U2 := HMAC(str, U1) 181 ... 182 Ui-1 := HMAC(str, Ui-2) 183 Ui := HMAC(str, Ui-1) 185 Hi := U1 XOR U2 XOR ... XOR Ui 187 where "i" is the iteration count, "+" is the string concatenation 188 operator and INT(g) is a four-octet encoding of the integer g, 189 most significant octet first. 191 Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and 192 with dkLen == output length of HMAC() == output length of H(). 194 2. Introduction 196 This specification describes a family of authentication mechanisms 197 called the Salted Challenge Response Authentication Mechanism (SCRAM) 198 which addresses the requirements necessary to deploy a challenge- 199 response mechanism more widely than past attempts (see [RFC5802]). 200 When used in combination with Transport Layer Security (TLS, see 201 [RFC5246]) or an equivalent security layer, a mechanism from this 202 family could improve the status-quo for application protocol 203 authentication. 205 SCRAM provides the following protocol features: 207 o The authentication information stored in the authentication 208 database is not sufficient by itself (without a dictionary attack) 209 to impersonate the client. The information is salted to prevent a 210 pre-stored dictionary attack if the database is stolen. 212 o The server does not gain the ability to impersonate the client to 213 other servers (with an exception for server-authorized proxies). 215 o The mechanism permits the use of a server-authorized proxy without 216 requiring that proxy to have super-user rights with the back-end 217 server. 219 o Mutual authentication is supported, but only the client is named 220 (i.e., the server has no name). 222 3. SCRAM Algorithm Overview 224 The following is a description of a full HTTP SCRAM authentication 225 exchange. Note that this section omits some details, such as client 226 and server nonces. See Section 5 for more details. 228 To begin with, the SCRAM client is in possession of a username and 229 password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends 230 the username to the server, which retrieves the corresponding 231 authentication information, i.e. a salt, StoredKey, ServerKey and the 232 iteration count i. (Note that a server implementation may choose to 233 use the same iteration count for all accounts.) The server sends the 234 salt and the iteration count to the client, which then computes the 235 following values and sends a ClientProof to the server: 237 (*) - Note that both the username and the password MUST be encoded in 238 UTF-8 [RFC3629]. 240 Informative Note: Implementors are encouraged to create test cases 241 that use both username passwords with non-ASCII codepoints. In 242 particular, it's useful to test codepoints whose "Unicode 243 Normalization Form C" and "Unicode Normalization Form KC" are 244 different. Some examples of such codepoints include Vulgar Fraction 245 One Half (U+00BD) and Acute Accent (U+00B4). 247 SaltedPassword := Hi(Normalize(password), salt, i) 248 ClientKey := HMAC(SaltedPassword, "Client Key") 249 StoredKey := H(ClientKey) 250 AuthMessage := client-first-message-bare + "," + 251 server-first-message + "," + 252 client-final-message-without-proof 253 ClientSignature := HMAC(StoredKey, AuthMessage) 254 ClientProof := ClientKey XOR ClientSignature 255 ServerKey := HMAC(SaltedPassword, "Server Key") 256 ServerSignature := HMAC(ServerKey, AuthMessage) 258 The server authenticates the client by computing the ClientSignature, 259 exclusive-ORing that with the ClientProof to recover the ClientKey 260 and verifying the correctness of the ClientKey by applying the hash 261 function and comparing the result to the StoredKey. If the ClientKey 262 is correct, this proves that the client has access to the user's 263 password. 265 Similarly, the client authenticates the server by computing the 266 ServerSignature and comparing it to the value sent by the server. If 267 the two are equal, it proves that the server had access to the user's 268 ServerKey. 270 The AuthMessage is computed by concatenating messages from the 271 authentication exchange. The format of these messages is defined in 272 Section 6. 274 4. SCRAM Mechanism Names 276 A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" 277 followed by the uppercased name of the underlying hash function taken 278 from the IANA "Hash Function Textual Names" registry (see http:// 279 www.iana.org) . 281 For interoperability, all HTTP clients and servers supporting SCRAM 282 MUST implement the SCRAM-SHA-1 authentication mechanism, i.e. an 283 authentication mechanism from the SCRAM family that uses the SHA-1 284 hash function as defined in [RFC3174]. 286 5. SCRAM Authentication Exchange 288 SCRAM is a HTTP Authentication mechanism whose client response 289 () and server challenge () 290 messages are text-based messages containing one or more attribute- 291 value pairs separated by commas. Each attribute has a one-letter 292 name, with the exception of a couple of attributes which are generic 293 to HTTP authentication, such as "realm" (and "sid"). The messages 294 and their attributes are described in Section 5.1, and defined in 295 Section 6. 297 challenge-scram = "SCRAM-SHA-1" 1*SP 1#auth-param 298 ; Complies with ABNF from I-D.ietf-httpbis-p7-auth. 299 ; Included in the WWW-Authenticate header field. 301 credentials-scram = "SCRAM-SHA-1" 1*SP 1#auth-param 302 ; Complies with from I-D.ietf-httpbis-p7-auth 303 ; Included in the Authorization header field. 305 This is a simple example of a SCRAM-SHA-1 authentication exchange 306 when the client doesn't support channel bindings (username 'user' and 307 password 'pencil' are used): 309 [...The server might have returned 401 Unauthorized first...] 311 C: GET /resource HTTP/1.1 312 C: Host: server.example.com 313 C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", 314 g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL 315 C: [...] 317 S: HTTP/1.1 401 Unauthorized 318 S: WWW-Authenticate: SCRAM-SHA-1 319 realm="testrealm@host.com",sid=AAAABBBBCCCCDDDD, 320 r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92, 321 i=4096 322 S: [...] 324 C: GET /resource HTTP/1.1 325 C: Host: server.example.com 326 C: Authorization: SCRAM-SHA-1 sid=AAAABBBBCCCCDDDD, 327 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 328 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 329 C: [...] 330 S: HTTP/1.1 200 Ok 331 S: Authentication-Info: SCRAM-SHA-1 332 sid=AAAABBBBCCCCDDDD, 333 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 334 S: [...Other header fields and resource body...] 336 "SCRAM-SHA-1" authentication starts with sending the "Authorization" 337 request header field defined by HTTP/1.1, Part 7 338 [I-D.ietf-httpbis-p7-auth] containing "SCRAM-SHA-1" authentication 339 scheme and the following attributes: 341 o A "realm" attribute MAY be included to indicate the scope of 342 protection in the manner described in HTTP/1.1, Part 7 343 [I-D.ietf-httpbis-p7-auth]. As specified in 344 [I-D.ietf-httpbis-p7-auth], the "realm" attribute MUST NOT appear 345 more than once. The realm attribute only appears in the first 346 SCRAM message to the server and in the first SCRAM response from 347 the server. 349 o The client also includes the "client-first-message" containing: 351 * a header ("g" attribute) consisting of a flag indicating 352 whether channel binding is supported-but-not-used, not 353 supported, or used . Note that the "g" attribute always starts 354 with "n", "y" or "p", otherwise the message is invalid and 355 authentication MUST fail. 357 * SCRAM username and a random, unique nonce attributes. 359 In HTTP response, the server sends WWW-Authenticate header field 360 containing: a unique session identifier (the "sid" attribute) plus 361 the "server-first-message" containing the user's iteration count i, 362 the user's salt, and the nonce with a concatenation of the client- 363 specified one with a server nonce. 365 The client then responds with another HTTP request with the 366 Authorization header field, which includes the "sid" attribute 367 received in the previous server response, together with "client- 368 final-message" data. The latter has the same nonce and a ClientProof 369 computed using the selected hash function (SHA-1) as explained 370 earlier. 372 The server verifies the nonce and the proof, and, finally, it 373 responds with a 200 HTTP response with the Authentication-Info header 374 field containing "server-final-message", concluding the 375 authentication exchange. 377 The client then authenticates the server by computing the 378 ServerSignature and comparing it to the value sent by the server. If 379 the two are different, the client MUST consider the authentication 380 exchange to be unsuccessful and it might have to drop the connection. 382 5.1. SCRAM Attributes 384 This section describes the permissible attributes, their use, and the 385 format of their values. All attribute names are single US-ASCII 386 letters and are case-sensitive. 388 Note that the order of attributes in client or server messages is 389 fixed, with the exception of extension attributes (described by the 390 "extensions" ABNF production), which can appear in any order in the 391 designated positions. See the ABNF section for authoritative 392 reference. 394 o g: This attribute value consist of a flag indicating whether 395 channel binding is supported-but-not-used, not supported, or used 396 . 398 o n: This attribute specifies the name of the user whose password is 399 used for authentication. A client MUST include it in its first 400 message to the server. 402 Before sending the username to the server, the client SHOULD 403 prepare the username using the "SASLPrep" profile [RFC4013] of 404 the "stringprep" algorithm [RFC3454] treating it as a query 405 string (i.e., unassigned Unicode code points are allowed). If 406 the preparation of the username fails or results in an empty 407 string, the client SHOULD abort the authentication exchange 408 (*). 410 (*) An interactive client can request a repeated entry of the 411 username value. 413 Upon receipt of the username by the server, the server MUST 414 either prepare it using the "SASLPrep" profile [RFC4013] of the 415 "stringprep" algorithm [RFC3454] treating it as a query string 416 (i.e., unassigned Unicode codepoints are allowed) or otherwise 417 be prepared to do SASLprep-aware string comparisons and/or 418 index lookups. If the preparation of the username fails or 419 results in an empty string, the server SHOULD abort the 420 authentication exchange. Whether or not the server prepares 421 the username using "SASLPrep", it MUST use it as received in 422 hash calculations. 424 The characters ',' or '=' in usernames are sent as '=2C' and 425 '=3D' respectively. If the server receives a username which 426 contains '=' not followed by either '2C' or '3D', then the 427 server MUST fail the authentication. 429 o m: This attribute is reserved for future extensibility. In this 430 version of SCRAM, its presence in a client or a server message 431 MUST cause authentication failure when the attribute is parsed by 432 the other end. 434 o r: This attribute specifies a sequence of random printable ASCII 435 characters excluding ',' which forms the nonce used as input to 436 the hash function. No quoting is applied to this string. As 437 described earlier, the client supplies an initial value in its 438 first message, and the server augments that value with its own 439 nonce in its first response. It is important that this value be 440 different for each authentication (see [RFC4086] for more details 441 on how to achieve this). The client MUST verify that the initial 442 part of the nonce used in subsequent messages is the same as the 443 nonce it initially specified. The server MUST verify that the 444 nonce sent by the client in the second message is the same as the 445 one sent by the server in its first message. 447 o c: This REQUIRED attribute specifies the base64-encoded GS2 header 448 and channel-binding data. It is sent by the client in its second 449 authentication message. The attribute data consist of: 451 * the GS2 header from the client's first message (recall that the 452 GS2 header contains a channel binding flag ). This header is 453 going to include channel binding type prefix (see [RFC5056]), 454 if and only if the client is using channel binding; 456 * followed by the external channel's channel binding data, if and 457 only if the client is using channel binding. 459 o s: This attribute specifies the base64-encoded salt used by the 460 server for this user. It is sent by the server in its first 461 message to the client. 463 o i: This attribute specifies an iteration count for the selected 464 hash function and user, and MUST be sent by the server along with 465 the user's salt. 467 For SCRAM-SHA-1 authentication mechanism servers SHOULD 468 announce a hash iteration-count of at least 4096. Note that a 469 client implementation MAY cache ClientKey&ServerKey (or just 470 SaltedPassword) for later reauthentication to the same service, 471 as it is likely that the server is going to advertise the same 472 salt value upon reauthentication. This might be useful for 473 mobile clients where CPU usage is a concern. 475 o p: This attribute specifies a base64-encoded ClientProof. The 476 client computes this value as described in the overview and sends 477 it to the server. 479 o v: This attribute specifies a base64-encoded ServerSignature. It 480 is sent by the server in its final message, and is used by the 481 client to verify that the server has access to the user's 482 authentication information. This value is computed as explained 483 in the overview. 485 6. Formal Syntax 487 The following syntax specification uses the Augmented Backus-Naur 488 Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3" 489 and "UTF8-4" non-terminal are defined in [RFC3629]. 491 ALPHA = 492 DIGIT = 493 UTF8-2 = 494 UTF8-3 = 495 UTF8-4 = 497 attr-val = ALPHA "=" value 498 ;; Generic syntax of any attribute sent 499 ;; by server or client 501 value = 1*value-char 503 value-safe-char = %x01-2B / %x2D-3C / %x3E-7F / 504 UTF8-2 / UTF8-3 / UTF8-4 505 ;; UTF8-char except NUL, "=", and ",". 507 value-char = value-safe-char / "=" 509 printable = %x21-2B / %x2D-7E 510 ;; Printable ASCII except ",". 511 ;; Note that any "printable" is also 512 ;; a valid "value". 514 base64-char = ALPHA / DIGIT / "/" / "+" 516 base64-4 = 4base64-char 518 base64-3 = 3base64-char "=" 519 base64-2 = 2base64-char "==" 521 base64 = *base64-4 [base64-3 / base64-2] 523 posit-number = %x31-39 *DIGIT 524 ;; A positive number. 526 cb-name = 1*(ALPHA / DIGIT / "." / "-") 527 ;; See RFC 5056, Section 7. 528 ;; E.g., "tls-server-end-point" or 529 ;; "tls-unique". 531 gs2-cbind-flag = ("p=" cb-name) / "n" / "y" 532 ;; "n" -> client doesn't support channel binding. 533 ;; "y" -> client does support channel binding 534 ;; but thinks the server does not. 535 ;; "p" -> client requires channel binding. 536 ;; The selected channel binding follows "p=". 538 gs2-header = gs2-cbind-flag "," 539 ;; GS2 header for SCRAM. 541 username = "n=" 1*(value-safe-char / "=2C" / "=3D") 542 ;; Conforms to . 543 ;; Usernames are prepared using SASLPrep. 545 reserved-mext = "m=" 1*(value-char) 546 ;; Reserved for signaling mandatory extensions. 547 ;; The exact syntax will be defined in 548 ;; the future. 550 channel-binding = "c=" base64 551 ;; base64 encoding of cbind-input. 553 proof = "p=" base64 555 nonce = "r=" c-nonce [s-nonce] 556 ;; Second part provided by server. 558 c-nonce = printable 560 s-nonce = printable 562 salt = "s=" base64 564 verifier = "v=" base64 565 ;; base-64 encoded ServerSignature. 567 iteration-count = "i=" posit-number 568 ;; A positive number. 570 client-first-message-bare = 571 [reserved-mext ","] 572 username "," nonce ["," extensions] 574 client-first-message = 575 "g=" gs2-header client-first-message-bare 576 ;; Note that this doesn't include "realm" and 577 ;; other generic HTTP directives. 579 server-first-message = 580 [reserved-mext ","] nonce "," salt "," 581 iteration-count ["," extensions] 582 ;; Note that this doesn't include "realm", "sid" and 583 ;; other generic HTTP directives. 585 client-final-message-without-proof = 586 channel-binding "," nonce ["," 587 extensions] 589 client-final-message = 590 client-final-message-without-proof "," proof 591 ;; Note that this doesn't include "sid" and 592 ;; other generic HTTP directives. 594 server-error = "e=" server-error-value 596 server-error-value = "invalid-encoding" / 597 "extensions-not-supported" / ; unrecognized 'm' value 598 "invalid-proof" / 599 "channel-bindings-dont-match" / 600 "server-does-support-channel-binding" / 601 ; server does not support channel binding 602 "channel-binding-not-supported" / 603 "unsupported-channel-binding-type" / 604 "unknown-user" / 605 "invalid-username-encoding" / 606 ; invalid username encoding (invalid UTF-8 or 607 ; SASLprep failed) 608 "no-resources" / 609 "other-error" / 610 server-error-value-ext 611 ; Unrecognized errors should be treated as "other-error". 612 ; In order to prevent information disclosure, the server 613 ; may substitute the real reason with "other-error". 615 server-error-value-ext = value 616 ; Additional error reasons added by extensions 617 ; to this document. 619 server-final-message = (server-error / verifier) 620 ["," extensions] 622 extensions = attr-val *("," attr-val) 623 ;; All extensions are optional, 624 ;; i.e., unrecognized attributes 625 ;; not defined in this document 626 ;; MUST be ignored. 628 cbind-data = 1*OCTET 630 cbind-input = gs2-header [ cbind-data ] 631 ;; cbind-data MUST be present for 632 ;; gs2-cbind-flag of "p" and MUST be absent 633 ;; for "y" or "n". 635 7. Security Considerations 637 If the authentication exchange is performed without a strong security 638 layer (such as TLS with data confidentiality), then a passive 639 eavesdropper can gain sufficient information to mount an offline 640 dictionary or brute-force attack which can be used to recover the 641 user's password. The amount of time necessary for this attack 642 depends on the cryptographic hash function selected, the strength of 643 the password and the iteration count supplied by the server. An 644 external security layer with strong encryption will prevent this 645 attack. 647 If the external security layer used to protect the SCRAM exchange 648 uses an anonymous key exchange, then the SCRAM channel binding 649 mechanism can be used to detect a man-in-the-middle attack on the 650 security layer and cause the authentication to fail as a result. 651 However, the man-in-the-middle attacker will have gained sufficient 652 information to mount an offline dictionary or brute-force attack. 653 For this reason, SCRAM allows to increase the iteration count over 654 time. (Note that a server that is only in posession of "StoredKey" 655 and "ServerKey" can't automatic increase the iteration count upon 656 successful authentication. Such increase would require resetting 657 user's password.) 659 If the authentication information is stolen from the authentication 660 database, then an offline dictionary or brute-force attack can be 661 used to recover the user's password. The use of salt mitigates this 662 attack somewhat by requiring a separate attack on each password. 663 Authentication mechanisms which protect against this attack are 664 available (e.g., the EKE class of mechanisms). RFC 2945 [RFC2945] is 665 an example of such technology. 667 If an attacker obtains the authentication information from the 668 authentication repository and either eavesdrops on one authentication 669 exchange or impersonates a server, the attacker gains the ability to 670 impersonate that user to all servers providing SCRAM access using the 671 same hash function, password, iteration count and salt. For this 672 reason, it is important to use randomly-generated salt values. 674 SCRAM does not negotiate a hash function to use. Hash function 675 negotiation is left to the HTTP authentication mechanism negotiation. 676 It is important that clients be able to sort a locally available list 677 of mechanisms by preference so that the client may pick the most 678 preferred of a server's advertised mechanism list. This preference 679 order is not specified here as it is a local matter. The preference 680 order should include objective and subjective notions of mechanism 681 cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be 682 preferred over SCRAM with SHA-1). 684 SCRAM does not protect against downgrade attacks of channel binding 685 types. The complexities of negotiation a channel binding type, and 686 handling down-grade attacks in that negotiation, was intentionally 687 left out of scope for this document. 689 A hostile server can perform a computational denial-of-service attack 690 on clients by sending a big iteration count value. 692 See [RFC4086] for more information about generating randomness. 694 8. IANA Considerations 696 New mechanisms in the SCRAM- family are registered according to the 697 IANA procedure specified in [RFC5802]. 699 Note to future SCRAM- mechanism designers: each new SCRAM- HTTP 700 authentication mechanism MUST be explicitly registered with IANA and 701 MUST comply with SCRAM- mechanism naming convention defined in 702 Section 4 of this document. 704 IANA is requested to add the following entry to the Authentication 705 Scheme Registry defined in HTTP/1.1, Part 7 706 [I-D.ietf-httpbis-p7-auth]: 708 Authentication Scheme Name: SCRAM-SHA-1 709 Pointer to specification text: [[ this document ]] 710 Notes (optional): (none) 712 9. Acknowledgements 714 This document benefited from discussions on the SASL and Kitten WG 715 mailing lists. The authors would like to specially thank co-authors 716 of [RFC5802] from which lots of text was copied. 718 10. Design Motivations 720 The following design goals shaped this document. Note that some of 721 the goals have changed since the initial version of the document. 723 o The HTTP authentication mechanism has all modern features: support 724 for internationalized usernames and passwords, support for channel 725 bindings. 727 o The protocol supports mutual authentication. 729 o The authentication information stored in the authentication 730 database is not sufficient by itself to impersonate the client. 732 o The server does not gain the ability to impersonate the client to 733 other servers (with an exception for server-authorized proxies), 734 unless such other servers allow SCRAM authentication and use the 735 same salt and iteration count for the user. 737 o The mechanism is extensible, but [hopefully] not overengineered in 738 this respect. 740 o Easier to implement than HTTP Digest in both clients and servers. 742 11. Open Issues 744 It should be possible to construct a quick reauthentication version 745 of the mechanism that uses fewer round-trips (similar to what Digest 746 has). 748 12. Internet-Draft Change History 750 (RFC Editor: Please delete this section and all subsections.) 752 Changes since -00 754 13. References 756 13.1. Normative References 758 [I-D.ietf-httpbis-p7-auth] 759 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 760 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-22 761 (work in progress), March 2012. 763 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 764 Hashing for Message Authentication", RFC 2104, February 765 1997. 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, March 1997. 770 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 771 (SHA1)", RFC 3174, September 2001. 773 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 774 Internationalized Strings ("stringprep")", RFC 3454, 775 December 2002. 777 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 778 10646", STD 63, RFC 3629, November 2003. 780 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 781 and Passwords", RFC 4013, February 2005. 783 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 784 Encodings", RFC 4648, October 2006. 786 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 787 Channels", RFC 5056, November 2007. 789 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 790 Specifications: ABNF", STD 68, RFC 5234, January 2008. 792 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 793 for TLS", RFC 5929, July 2010. 795 13.2. Informative References 797 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 798 "Remote Authentication Dial In User Service (RADIUS)", RFC 799 2865, June 2000. 801 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 802 Specification Version 2.0", RFC 2898, September 2000. 804 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 805 RFC 2945, September 2000. 807 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 808 Requirements for Security", BCP 106, RFC 4086, June 2005. 810 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 811 (LDAP): Technical Specification Road Map", RFC 4510, June 812 2006. 814 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 815 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 817 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 818 4949, August 2007. 820 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 821 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 822 May 2008. 824 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 825 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 827 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 828 "Salted Challenge Response Authentication Mechanism 829 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 831 [RFC5803] Melnikov, A., "Lightweight Directory Access Protocol 832 (LDAP) Schema for Storing Salted Challenge Response 833 Authentication Mechanism (SCRAM) Secrets", RFC 5803, July 834 2010. 836 [tls-server-end-point] 837 Zhu, L., ., "Registration of TLS server end-point channel 838 bindings", IANA http://www.iana.org/assignments/channel- 839 binding-types/tls-server-end-point, July 2008. 841 Author's Address 843 Alexey Melnikov 844 Isode Ltd 846 Email: Alexey.Melnikov@isode.com