idnits 2.17.1 draft-ietf-httpauth-digest-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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2617, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 310 has weird spacing: '...quality of th...' == Line 342 has weird spacing: '...eturned by th...' == Line 647 has weird spacing: '...ptional clien...' == Line 694 has weird spacing: '...hanging nonce...' == Line 969 has weird spacing: '...ve) are prote...' -- The document date (January 1, 2014) is 3765 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) == Missing Reference: 'RFC2616' is mentioned on line 834, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC2119' is mentioned on line 206, but not defined -- Looks like a reference, but probably isn't: '7' on line 287 == Missing Reference: 'RFC2069' is mentioned on line 472, but not defined ** Obsolete undefined reference: RFC 2069 (Obsoleted by RFC 2617) == Missing Reference: 'SHA3' is mentioned on line 820, but not defined == Missing Reference: 'RFC3629' is mentioned on line 919, but not defined -- Looks like a reference, but probably isn't: '10' on line 956 -- Looks like a reference, but probably isn't: '9' on line 958 -- Looks like a reference, but probably isn't: '8' on line 1115 == Unused Reference: 'KEYWORDS' is defined on line 1255, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 1258, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 1266, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 1269, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 1272, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1776 ** Downref: Normative reference to an Informational RFC: RFC 1925 (ref. 'TRUTHS') Summary: 4 errors (**), 0 flaws (~~), 18 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAuth Working Group R. Shekh-Yusef, Ed. 3 Internet-Draft D. Ahrens 4 Obsoletes: 2617 (if approved) Avaya 5 Intended Status: Standards Track S. Bremer 6 Expires: July 5, 2014 Netzkonform 7 January 1, 2014 9 HTTP Digest Access Authentication 10 draft-ietf-httpauth-digest-01.txt 12 Abstract 14 HTTP provides a simple challenge-response authentication mechanism 15 that may be used by a server to challenge a client request and by a 16 client to provide authentication information. This document defines 17 the HTTP Digest Authentication scheme that may be used with the 18 authentication mechanism. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 6 61 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 6 62 3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 6 63 3.2 Representation of Digest Values . . . . . . . . . . . . . . 6 64 3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 7 65 3.4 The Authorization Request Header . . . . . . . . . . . . . . 10 66 3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 12 67 3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 3.4.4 Username Hashing . . . . . . . . . . . . . . . . . . . . 14 70 3.4.5 Directive Values and Quoted-String . . . . . . . . . . . 14 71 3.4.6 Various Considerations . . . . . . . . . . . . . . . . . 15 72 3.5 The Authentication-Info Header . . . . . . . . . . . . . . . 16 73 3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 17 74 3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 19 75 3.8 Proxy-Authentication and Proxy-Authorization . . . . . . . . 19 76 3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 22 78 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 22 79 5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 22 80 5.2 Authentication of Clients using Digest Authentication . . . 22 81 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 23 82 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 83 5.5 Weakness Created by Multiple Authentication Schemes . . . . 24 84 5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 25 85 5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 25 86 5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 26 87 5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 26 88 5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 27 89 5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 27 90 5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 27 91 5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28 94 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 29 95 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 29 97 8.2 Informative References . . . . . . . . . . . . . . . . . . . 29 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 100 1 Introduction 102 HTTP provides a simple challenge-response authentication mechanism 103 that MAY be used by a server to challenge a client request and by a 104 client to provide authentication information. It uses an extensible, 105 case-insensitive token to identify the authentication scheme, 106 followed by a comma-separated list of attribute-value pairs which 107 carry the parameters necessary for achieving authentication via that 108 scheme. 110 auth-scheme = token 111 auth-param = token "=" ( token | quoted-string ) 113 The 401 (Unauthorized) response message is used by an origin server 114 to challenge the authorization of a user agent. This response MUST 115 include a WWW-Authenticate header field containing at least one 116 challenge applicable to the requested resource. The 407 (Proxy 117 Authentication Required) response message is used by a proxy to 118 challenge the authorization of a client and MUST include a Proxy- 119 Authenticate header field containing at least one challenge 120 applicable to the proxy for the requested resource. 122 challenge = auth-scheme 1*SP 1#auth-param 124 Note: User agents will need to take special care in parsing the WWW- 125 Authenticate or Proxy-Authenticate header field value if it contains 126 more than one challenge, or if more than one WWW-Authenticate header 127 field is provided, since the contents of a challenge may itself 128 contain a comma-separated list of authentication parameters. 130 The authentication parameter realm is defined for all authentication 131 schemes: 133 realm = "realm" "=" realm-value 134 realm-value = quoted-string 136 The realm directive (case-insensitive) is required for all 137 authentication schemes that issue a challenge. The realm value (case- 138 sensitive), in combination with the canonical root URL (the 139 absoluteURI for the server whose abs_path is empty; see section 5.1.2 140 of [RFC2616]) of the server being accessed, defines the protection 141 space. These realms allow the protected resources on a server to be 142 partitioned into a set of protection spaces, each with its own 143 authentication scheme and/or authorization database. The realm value 144 is a string, generally assigned by the origin server, which may have 145 additional semantics specific to the authentication scheme. Note that 146 there may be multiple challenges with the same auth-scheme but 147 different realms. 149 A user agent that wishes to authenticate itself with an origin 150 server--usually, but not necessarily, after receiving a 401 151 (Unauthorized)--MAY do so by including an Authorization header field 152 with the request. A client that wishes to authenticate itself with a 153 proxy--usually, but not necessarily, after receiving a 407 (Proxy 154 Authentication Required)--MAY do so by including a Proxy- 155 Authorization header field with the request. Both the Authorization 156 field value and the Proxy-Authorization field value consist of 157 credentials containing the authentication information of the client 158 for the realm of the resource being requested. The user agent MUST 159 choose to use one of the challenges with the strongest auth-scheme it 160 understands and request credentials from the user based upon that 161 challenge. 163 credentials = auth-scheme #auth-param 165 Note that many browsers will only recognize Basic and will require 166 that it be the first auth-scheme presented. Servers should only 167 include Basic if it is minimally acceptable. 169 The protection space determines the domain over which credentials can 170 be automatically applied. If a prior request has been authorized, the 171 same credentials MAY be reused for all other requests within that 172 protection space for a period of time determined by the 173 authentication scheme, parameters, and/or user preference. Unless 174 otherwise defined by the authentication scheme, a single protection 175 space cannot extend outside the scope of its server. 177 If the origin server does not wish to accept the credentials sent 178 with a request, it SHOULD return a 401 (Unauthorized) response. The 179 response MUST include a WWW-Authenticate header field containing at 180 least one (possibly new) challenge applicable to the requested 181 resource. If a proxy does not accept the credentials sent with a 182 request, it SHOULD return a 407 (Proxy Authentication Required). The 183 response MUST include a Proxy-Authenticate header field containing a 184 (possibly new) challenge applicable to the proxy for the requested 185 resource. 187 The HTTP protocol does not restrict applications to this simple 188 challenge-response mechanism for access authentication. Additional 189 mechanisms MAY be used, such as encryption at the transport level or 190 via message encapsulation, and with additional header fields 191 specifying authentication information. However, these additional 192 mechanisms are not defined by this specification. 194 Proxies MUST be completely transparent regarding user agent 195 authentication by origin servers. That is, they must forward the WWW- 196 Authenticate and Authorization headers untouched, and follow the 197 rules found in section 14.8 of [RFC2616]. Both the Proxy-Authenticate 198 and the Proxy-Authorization header fields are hop-by-hop headers (see 199 section 13.5.1 of [RFC2616]). 201 1.1 Terminology 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in RFC 2119 [RFC2119]. 207 2 Syntax Convention 209 In the interest of clarity and readability, the extended parameters 210 or the headers and parameters in the examples in this document might 211 be broken into multiple lines. Any line that is indented in this 212 document is a continuation of the preceding line. 214 3 Digest Access Authentication Scheme 216 3.1 Overall Operation 218 The Digest scheme is based on a simple challenge-response paradigm. 219 The Digest scheme challenges using a nonce value. A valid response 220 contains a checksum of the username, the password, the given nonce 221 value, the HTTP method, and the requested URI. In this way, the 222 password is never sent in the clear. The username and password must 223 be prearranged in some fashion not addressed by this document. 225 3.2 Representation of Digest Values 227 An optional header allows the server to specify the algorithm used to 228 create the checksum or digest. By default the SHA2-256 algorithm is 229 used, with SHA2-512/256 being used as a backup algorithm. To 230 maintain backwards compatibility, the MD5 algorithm is still 231 supported but not recommended. 233 The size of the digest depends on the algorithm used. The bits in 234 the digest are converted from the most significant to the least 235 significant bit, four bits at a time to the ASCII representation as 236 follows. Each four bits is represented by its familiar hexadecimal 237 notation from the characters 0123456789abcdef, that is binary 0000 is 238 represented by the character '0', 0001 by '1' and so on up to the 239 representation of 1111 as 'f'. If the MD5 algorithm is used to 240 calculate the digest, then the digest will be represented as 32 241 hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal 242 characters. 244 3.3 The WWW-Authenticate Response Header 246 If a server receives a request for an access-protected object, and an 247 acceptable Authorization header is not sent, the server responds with 248 a "401 Unauthorized" status code, and a WWW-Authenticate header as 249 per the framework defined above, which for the digest scheme is 250 utilized as follows: 252 challenge = "Digest" digest-challenge 254 digest-challenge = 1#( realm | [ domain ] | nonce | 255 [ opaque ] |[ stale ] | [ algorithm ] | 256 [ qop-options ] | [charset] | [userhash] | 257 [auth-param]) 259 domain = "domain" "=" <"> URI ( 1*SP URI ) <"> 260 URI = absoluteURI | abs_path 261 nonce = "nonce" "=" nonce-value 262 nonce-value = quoted-string 263 opaque = "opaque" "=" quoted-string 264 stale = "stale" "=" ( "true" | "false" ) 265 algorithm = "algorithm" "=" ( 266 "MD5" | "MD5-sess" | 267 "SHA2-256" | "SHA2-256-sess" | 268 "SHA2-512-256" | "SHA2-512-256-sess" | 269 token) 270 qop-options = "qop" "=" <"> 1#qop-value <"> 271 qop-value = "auth" | "auth-int" | token 272 charset = "charset" "=" ("UTF-8" | token) 273 userhash = "userhash" "=" ( "true" | "false" ) 275 The meanings of the values of the directives used above are as 276 follows: 278 realm 279 A string to be displayed to users so they know which username and 280 password to use. This string should contain at least the name of 281 the host performing the authentication and might additionally 282 indicate the collection of users who might have access. An example 283 might be "registered_users@gotham.news.com". 285 domain 286 A quoted, space-separated list of URIs, as specified in RFC XURI 287 [7], that define the protection space. If a URI is an abs_path, 288 it is relative to the canonical root URL of the server being 289 accessed. An absoluteURI in this list may refer to a different 290 server than the one being accessed. The client can use this list 291 to determine the set of URIs for which the same authentication 292 information may be sent: any URI that has a URI in this list as a 293 prefix (after both have been made absolute) may be assumed to be 294 in the same protection space. If this directive is omitted or its 295 value is empty, the client should assume that the protection space 296 consists of all URIs on the responding server. 298 This directive is not meaningful in Proxy-Authenticate headers, 299 for which the protection space is always the entire proxy; if 300 present it should be ignored. 302 nonce 303 A server-specified data string which should be uniquely generated 304 each time a 401 response is made. It is recommended that this 305 string be base64 or hexadecimal data. Specifically, since the 306 string is passed in the header lines as a quoted string, the 307 double-quote character is not allowed. 309 The contents of the nonce are implementation dependent. The 310 quality of the implementation depends on a good choice. A nonce 311 might, for example, be constructed as the base 64 encoding of 313 time-stamp H(time-stamp ":" ETag ":" private-key) 315 where time-stamp is a server-generated time or other non-repeating 316 value, ETag is the value of the HTTP ETag header associated with 317 the requested entity, and private-key is data known only to the 318 server. With a nonce of this form a server would recalculate the 319 hash portion after receiving the client authentication header and 320 reject the request if it did not match the nonce from that header 321 or if the time-stamp value is not recent enough. In this way the 322 server can limit the time of the nonce's validity. The inclusion 323 of the ETag prevents a replay request for an updated version of 324 the resource. (Note: including the IP address of the client in the 325 nonce would appear to offer the server the ability to limit the 326 reuse of the nonce to the same client that originally got it. 327 However, that would break proxy farms, where requests from a 328 single user often go through different proxies in the farm. Also, 329 IP address spoofing is not that hard.) 331 An implementation might choose not to accept a previously used 332 nonce or a previously used digest, in order to protect against a 333 replay attack. Or, an implementation might choose to use one-time 334 nonces or digests for POST or PUT requests and a time-stamp for 335 GET requests. For more details on the issues involved see section 336 5 of this document. 338 The nonce is opaque to the client. 340 opaque 341 A string of data, specified by the server, which should be 342 returned by the client unchanged in the Authorization header of 343 subsequent requests with URIs in the same protection space. It is 344 recommended that this string be base64 or hexadecimal data. 346 stale 347 A case-insensitive flag, indicating that the previous request from 348 the client was rejected because the nonce value was stale. If 349 stale is TRUE, the client may wish to simply retry the request 350 with a new encrypted response, without reprompting the user for a 351 new username and password. The server should only set stale to 352 TRUE if it receives a request for which the nonce is invalid but 353 with a valid digest for that nonce (indicating that the client 354 knows the correct username/password). If stale is FALSE, or 355 anything other than TRUE, or the stale directive is not present, 356 the username and/or password are invalid, and new values must be 357 obtained. 359 algorithm 360 A string indicating a pair of algorithms used to produce the 361 digest and a checksum. If this is not present it is assumed to be 362 "MD5". If the algorithm is not understood, the challenge should be 363 ignored (and a different one used, if there is more than one). 365 In this document the string obtained by applying the digest 366 algorithm to the data "data" with secret "secret" will be denoted 367 by KD(secret, data), and the string obtained by applying the 368 checksum algorithm to the data "data" will be denoted H(data). The 369 notation unq(X) means the value of the quoted-string X without the 370 surrounding quotes. 372 For the "MD5" and "MD5-sess" algorithms 374 H(data) = MD5(data) 376 For the "SHA2-256" and "SHA2-256-sess" algorithms 378 H(data) = SHA2-256(data) 380 For the "SHA2-512-256" and "SHA2-512-256-sess" algorithms 382 H(data) = SHA2-512-256(data) 384 and 386 KD(secret, data) = H(concat(secret, ":", data)) 388 i.e., the digest is the MD5 of the secret concatenated with a 389 colon concatenated with the data. The "MD5-sess" algorithm is 390 intended to allow efficient 3rd party authentication servers; 391 for the difference in usage, see the description in section 392 3.4.2. 394 qop-options 395 This directive is optional, but is made so only for backward 396 compatibility with RFC 2069 [RFC2069]; it SHOULD be used by all 397 implementations compliant with this version of the Digest scheme. 398 If present, it is a quoted string of one or more tokens indicating 399 the "quality of protection" values supported by the server. The 400 value "auth" indicates authentication; the value "auth-int" 401 indicates authentication with integrity protection; see the 402 descriptions below for calculating the response directive value 403 for the application of this choice. Unrecognized options MUST be 404 ignored. 406 charset 407 This is an optional parameter that could be used by the server to 408 indicate the encoding scheme it supports. 410 userhash 411 This is an optional parameter that could be used by the server to 412 indicate that it supports username hashing. 414 auth-param 415 This directive allows for future extensions. Any unrecognized 416 directive MUST be ignored. 418 3.4 The Authorization Request Header 420 The client is expected to retry the request, passing an Authorization 421 header line, which is defined according to the framework above, 422 utilized as follows. 424 credentials = "Digest" digest-response 425 digest-response = 1#( username | realm | nonce | digest-uri | 426 response | [ algorithm ] | [cnonce] | 427 [opaque] | [message-qop] | 428 [nonce-count] | [charset] | [userhash] | 429 [auth-param] ) 430 username = "username" "=" username-value 431 username-value = quoted-string 432 digest-uri = "uri" "=" digest-uri-value 433 digest-uri-value = request-uri ; As specified by HTTP/1.1 434 message-qop = "qop" "=" qop-value 435 cnonce = "cnonce" "=" cnonce-value 436 cnonce-value = nonce-value 437 nonce-count = "nc" "=" nc-value 438 nc-value = 8LHEX 439 response = "response" "=" request-digest 440 request-digest = <"> digest-size LHEX <"> 441 digest-size = "32" | "64" 442 LHEX = "0" | "1" | "2" | "3" | 443 "4" | "5" | "6" | "7" | 444 "8" | "9" | "a" | "b" | 445 "c" | "d" | "e" | "f" 446 charset = "charset" "=" ("UTF-8" | token) 447 userhash = "userhash" "=" ( "true" | "false" ) 449 The values of the opaque and algorithm fields must be those supplied 450 in the WWW-Authenticate response header for the entity being 451 requested. 453 response 454 A string of digest-size hex digits computed as defined below, 455 which proves that the user knows a password 457 username 458 The user's name in the specified realm. 460 digest-uri 461 The URI from Request-URI of the Request-Line; duplicated here 462 because proxies are allowed to change the Request-Line in transit. 464 qop 465 Indicates what "quality of protection" the client has applied to 466 the message. If present, its value MUST be one of the alternatives 467 the server indicated it supports in the WWW-Authenticate header. 468 These values affect the computation of the request-digest. Note 469 that this is a single token, not a quoted list of alternatives as 470 in WWW- Authenticate. This directive is optional in order to 471 preserve backward compatibility with a minimal implementation of 472 RFC 2069 [RFC2069], but SHOULD be used if the server indicated 473 that qop is supported by providing a qop directive in the WWW- 474 Authenticate header field. 476 cnonce 477 This MUST be specified if a qop directive is sent (see above), and 478 MUST NOT be specified if the server did not send a qop directive 479 in the WWW-Authenticate header field. The cnonce-value is an 480 opaque quoted string value provided by the client and used by both 481 client and server to avoid chosen plaintext attacks, to provide 482 mutual authentication, and to provide some message integrity 483 protection. See the descriptions below of the calculation of the 484 response- digest and request-digest values. 486 nonce-count 487 This MUST be specified if a qop directive is sent (see above), and 488 MUST NOT be specified if the server did not send a qop directive 489 in the WWW-Authenticate header field. The nc-value is the 490 hexadecimal count of the number of requests (including the current 491 request) that the client has sent with the nonce value in this 492 request. For example, in the first request sent in response to a 493 given nonce value, the client sends "nc=00000001". The purpose of 494 this directive is to allow the server to detect request replays by 495 maintaining its own copy of this count - if the same nc-value is 496 seen twice, then the request is a replay. See the description 497 below of the construction of the request-digest value. 499 charset 500 This is an optional parameter that could be used by the client to 501 indicate the encoding scheme it supports. 503 userhash 504 This is an optional parameter that could be used by the client to 505 indicate that it supports username hashing. 507 auth-param 508 This directive allows for future extensions. Any unrecognized 509 directive MUST be ignored. 511 If a directive or its value is improper, or required directives are 512 missing, the proper response is 400 Bad Request. If the request- 513 digest is invalid, then a login failure should be logged, since 514 repeated login failures from a single client may indicate an attacker 515 attempting to guess passwords. 517 The definition of request-digest above indicates the encoding for its 518 value. The following definitions show how the value is computed. 520 3.4.1 Request-Digest 522 If the "qop" value is "auth" or "auth-int": 524 request-digest = <"> < KD ( H(A1), unq(nonce-value) 525 ":" nc-value 526 ":" unq(cnonce-value) 527 ":" unq(qop-value) 528 ":" H(A2) 529 ) <"> 531 If the "qop" directive is not present (this construction is for 532 compatibility with RFC 2069): 534 request-digest = 535 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> 537 See below for the definitions for A1 and A2. 539 3.4.2 A1 541 If the "algorithm" directive's value is "MD5", "SHA2-256", or "SHA2- 542 512-256", then A1 is: 544 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 546 where 548 passwd = < user's password > 550 If the "algorithm" directive's value is "MD5-sess", "SHA2-256-sess", 551 or "SHA2-512-256-sess", then A1 is calculated only once - on the 552 first request by the client following receipt of a WWW-Authenticate 553 challenge from the server. It uses the server nonce from that 554 challenge, and the first client nonce value to construct A1 as 555 follows: 557 A1 = H( unq(username-value) ":" unq(realm-value) 558 ":" passwd ) 559 ":" unq(nonce-value) ":" unq(cnonce-value) 561 This creates a 'session key' for the authentication of subsequent 562 requests and responses which is different for each "authentication 563 session", thus limiting the amount of material hashed with any one 564 key. (Note: see further discussion of the authentication session in 565 section 3.6.) Because the server need only use the hash of the user 566 credentials in order to create the A1 value, this construction could 567 be used in conjunction with a third party authentication service so 568 that the web server would not need the actual password value. The 569 specification of such a protocol is beyond the scope of this 570 specification. 572 3.4.3 A2 574 If the "qop" directive's value is "auth" or is unspecified, then A2 575 is: 577 A2 = Method ":" digest-uri-value 579 If the "qop" value is "auth-int", then A2 is: 581 A2 = Method ":" digest-uri-value ":" H(entity-body) 583 3.4.4 Username Hashing 585 To protect the transport of the username from the client to the 586 server, the server SHOULD set the "userhash" parameter with the value 587 of "true" in the WWW-Authentication header. 589 If the client supports the "userhash" parameter, and the "userhash" 590 parameter value in the WWW-Authentication header is set to "true", 591 then the client SHOULD calculate a hash of the username after any 592 other hash calculation and include the "userhash" parameter with the 593 value of "true" in the Authorization Request Header. If the client 594 does not provide the "username" as a hash value or the "userhash" 595 parameter with the value of "true", the server MAY reject the 596 request. 598 The server may change the nonce value, so the client should be ready 599 to recalculate the hashed username. 601 The following is the operation that the client will take to hash the 602 username: 604 username = H( H( username ":" realm ) ":" nonce) 606 3.4.5 Directive Values and Quoted-String 608 Note that the value of many of the directives, such as "username- 609 value", are defined as a "quoted-string". However, the "unq" notation 610 indicates that surrounding quotation marks are removed in forming the 611 string A1. Thus if the Authorization header includes the fields 613 username="Mufasa", realm=myhost@testrealm.com 615 and the user Mufasa has password "Circle Of Life" then H(A1) would be 616 H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks 617 in the digested string. 619 No white space is allowed in any of the strings to which the digest 620 function H() is applied unless that white space exists in the quoted 621 strings or entity body whose contents make up the string to be 622 digested. For example, the string A1 illustrated above must be 624 Mufasa:myhost@testrealm.com:Circle Of Life 626 with no white space on either side of the colons, but with the white 627 space between the words used in the password value. Likewise, the 628 other strings digested by H() must not have white space on either 629 side of the colons which delimit their fields unless that white space 630 was in the quoted strings or entity body being digested. 632 Also note that if integrity protection is applied (qop=auth-int), the 633 H(entity-body) is the hash of the entity body, not the message body - 634 it is computed before any transfer encoding is applied by the sender 635 and after it has been removed by the recipient. Note that this 636 includes multipart boundaries and embedded headers in each part of 637 any multipart content-type. 639 3.4.6 Various Considerations 641 The "Method" value is the HTTP request method as specified in section 642 5.1.1 of [RFC2616]. The "request-uri" value is the Request-URI from 643 the request line as specified in section 5.1.2 of [RFC2616]. This may 644 be "*", an "absoluteURL" or an "abs_path" as specified in section 645 5.1.2 of [RFC2616], but it MUST agree with the Request-URI. In 646 particular, it MUST be an "absoluteURL" if the Request-URI is an 647 "absoluteURL". The "cnonce-value" is an optional client-chosen value 648 whose purpose is to foil chosen plaintext attacks. 650 The authenticating server must assure that the resource designated by 651 the "uri" directive is the same as the resource specified in the 652 Request-Line; if they are not, the server SHOULD return a 400 Bad 653 Request error. (Since this may be a symptom of an attack, server 654 implementers may want to consider logging such errors.) The purpose 655 of duplicating information from the request URL in this field is to 656 deal with the possibility that an intermediate proxy may alter the 657 client's Request-Line. This altered (but presumably semantically 658 equivalent) request would not result in the same digest as that 659 calculated by the client. 661 Implementers should be aware of how authenticated transactions 662 interact with shared caches. The HTTP/1.1 protocol specifies that 663 when a shared cache (see section 13.7 of [RFC2616]) has received a 664 request containing an Authorization header and a response from 665 relaying that request, it MUST NOT return that response as a reply to 666 any other request, unless one of two Cache-Control (see section 14.9 667 of [RFC2616]) directives was present in the response. If the original 668 response included the "must-revalidate" Cache-Control directive, the 669 cache MAY use the entity of that response in replying to a subsequent 670 request, but MUST first revalidate it with the origin server, using 671 the request headers from the new request to allow the origin server 672 to authenticate the new request. Alternatively, if the original 673 response included the "public" Cache-Control directive, the response 674 entity MAY be returned in reply to any subsequent request. 676 3.5 The Authentication-Info Header 678 The Authentication-Info header is used by the server to communicate 679 some information regarding the successful authentication in the 680 response. 682 AuthenticationInfo = "Authentication-Info" ":" auth-info 683 auth-info = 1#(nextnonce | [ message-qop ] 684 | [ response-auth ] | [ cnonce ] 685 | [nonce-count] ) 686 nextnonce = "nextnonce" "=" nonce-value 687 response-auth = "rspauth" "=" response-digest 688 response-digest = <"> digest-size LHEX <"> 689 digest-size = "32" | "64" 691 The value of the nextnonce directive is the nonce the server wishes 692 the client to use for a future authentication response. The server 693 may send the Authentication-Info header with a nextnonce field as a 694 means of implementing one-time or otherwise changing nonces. If the 695 nextnonce field is present the client SHOULD use it when constructing 696 the Authorization header for its next request. Failure of the client 697 to do so may result in a request to re-authenticate from the server 698 with the "stale=TRUE". 700 Server implementations should carefully consider the performance 701 implications of the use of this mechanism; pipelined requests will 702 not be possible if every response includes a nextnonce directive 703 that must be used on the next request received by the server. 704 Consideration should be given to the performance vs. security 705 tradeoffs of allowing an old nonce value to be used for a limited 706 time to permit request pipelining. Use of the nonce-count can 707 retain most of the security advantages of a new server nonce 708 without the deleterious affects on pipelining. 710 message-qop 711 Indicates the "quality of protection" options applied to the 712 response by the server. The value "auth" indicates 713 authentication; the value "auth-int" indicates authentication with 714 integrity protection. The server SHOULD use the same value for the 715 message- qop directive in the response as was sent by the client 716 in the corresponding request. 718 The optional response digest in the "response-auth" directive 719 supports mutual authentication -- the server proves that it knows the 720 user's secret, and with qop=auth-int also provides limited integrity 721 protection of the response. The "response-digest" value is calculated 722 as for the "request-digest" in the Authorization header, except that 723 if "qop=auth" or is not specified in the Authorization header for the 724 request, A2 is 726 A2 = ":" digest-uri-value 728 and if "qop=auth-int", then A2 is 730 A2 = ":" digest-uri-value ":" H(entity-body) 732 where "digest-uri-value" is the value of the "uri" directive on the 733 Authorization header in the request. The "cnonce-value" and "nc- 734 value" MUST be the ones for the client request to which this message 735 is the response. The "response-auth", "cnonce", and "nonce-count" 736 directives MUST BE present if "qop=auth" or "qop=auth-int" is 737 specified. 739 The Authentication-Info header is allowed in the trailer of an HTTP 740 message transferred via chunked transfer-coding. 742 3.6 Digest Operation 744 Upon receiving the Authorization header, the server may check its 745 validity by looking up the password that corresponds to the submitted 746 username. Then, the server must perform the same digest operation 747 (e.g., MD5) performed by the client, and compare the result to the 748 given request-digest value. 750 Note that the HTTP server does not actually need to know the user's 751 cleartext password. As long as H(A1) is available to the server, the 752 validity of an Authorization header may be verified. 754 The client response to a WWW-Authenticate challenge for a protection 755 space starts an authentication session with that protection space. 756 The authentication session lasts until the client receives another 757 WWW-Authenticate challenge from any server in the protection space. A 758 client should remember the username, password, nonce, nonce count and 759 opaque values associated with an authentication session to use to 760 construct the Authorization header in future requests within that 761 protection space. The Authorization header may be included 762 preemptively; doing so improves server efficiency and avoids extra 763 round trips for authentication challenges. The server may choose to 764 accept the old Authorization header information, even though the 765 nonce value included might not be fresh. Alternatively, the server 766 may return a 401 response with a new nonce value, causing the client 767 to retry the request; by specifying stale=TRUE with this response, 768 the server tells the client to retry with the new nonce, but without 769 prompting for a new username and password. 771 Because the client is required to return the value of the opaque 772 directive given to it by the server for the duration of a session, 773 the opaque data may be used to transport authentication session state 774 information. (Note that any such use can also be accomplished more 775 easily and safely by including the state in the nonce.) For example, 776 a server could be responsible for authenticating content that 777 actually sits on another server. It would achieve this by having the 778 first 401 response include a domain directive whose value includes a 779 URI on the second server, and an opaque directive whose value 780 contains the state information. The client will retry the request, at 781 which time the server might respond with a 301/302 redirection, 782 pointing to the URI on the second server. The client will follow the 783 redirection, and pass an Authorization header , including the 784 data. 786 As with the basic scheme, proxies must be completely transparent in 787 the Digest access authentication scheme. That is, they must forward 788 the WWW-Authenticate, Authentication-Info and Authorization headers 789 untouched. If a proxy wants to authenticate a client before a request 790 is forwarded to the server, it can be done using the Proxy- 791 Authenticate and Proxy-Authorization headers described in section 3.6 792 below. 794 3.7 Security Protocol Negotiation 796 It is useful for a server to be able to know which security schemes a 797 client is capable of handling. 799 It is possible that a server may want to require Digest as its 800 authentication method, even if the server does not know that the 801 client supports it. A client is encouraged to fail gracefully if the 802 server specifies only authentication schemes it cannot handle. 804 When a server receives a request to access a resource, the server 805 might challenge the client by responding with "401 Unauthorized" 806 status code, and include one or more WWW-Authenticate headers. If the 807 server challenges with multiple Digest headers, then each one of 808 these headers MUST use a different digest algorithm. The server MUST 809 add these Digest headers to the response in order of preference, 810 starting with the most preferred header, followed by the less 811 preferred headers. 813 This specification defines the following preference list, starting 814 with the most preferred algorithm: 816 * SHA2-256 as the default algorithm. 817 * SHA2-512/256 as a backup algorithm. 818 * MD5 for backward compatibility. 820 A future version of this document might add SHA3 [SHA3] as a backup 821 algorithm, once its definition has been finalized and published. 823 When the client receives the response it SHOULD use the topmost 824 header that it supports, unless a local policy dictates otherwise. 825 The client should ignore any challenge it does not understand. 827 3.8 Proxy-Authentication and Proxy-Authorization 829 The digest authentication scheme may also be used for authenticating 830 users to proxies, proxies to proxies, or proxies to origin servers by 831 use of the Proxy-Authenticate and Proxy-Authorization headers. These 832 headers are instances of the Proxy-Authenticate and Proxy- 833 Authorization headers specified in sections 10.33 and 10.34 of the 834 HTTP/1.1 specification [RFC2616] and their behavior is subject to 835 restrictions described there. The transactions for proxy 836 authentication are very similar to those already described. Upon 837 receiving a request which requires authentication, the proxy/server 838 must issue the "407 Proxy Authentication Required" response with a 839 "Proxy-Authenticate" header. The digest-challenge used in the Proxy- 840 Authenticate header is the same as that for the WWW- Authenticate 841 header as defined above in section 3.2.1. 843 The client/proxy must then re-issue the request with a Proxy- 844 Authorization header, with directives as specified for the 845 Authorization header in section 3.4 above. 847 On subsequent responses, the server sends Proxy-Authentication-Info 848 with directives the same as those for the Authentication-Info header 849 field. 851 Note that in principle a client could be asked to authenticate itself 852 to both a proxy and an end-server, but never in the same response. 854 3.9 Example 856 The following example assumes that an access protected document is 857 being requested from the server via a GET request. The URI of the 858 document is http://www.nowhere.org/dir/index.html". Both client and 859 server know that the username for this document is "Mufasa" and the 860 password is "Circle of Life" ( with one space between each of the 861 three words). 863 The first time the client requests the document, no Authorization 864 header is sent, so the server responds with: 866 HTTP/1.1 401 Unauthorized 867 WWW-Authenticate: Digest 868 realm = "testrealm@host.com", 869 qop="auth, auth-int", 870 algorithm="SHA2-256", 871 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 872 opaque="5ccc069c403ebaf9f0171e9517f40e41" 873 WWW-Authenticate: Digest 874 realm="testrealm@host.com", 875 qop="auth, auth-int", 876 algorithm="MD5", 877 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 878 opaque="5ccc069c403ebaf9f0171e9517f40ef41" 880 The client may prompt the user for their username and password, after 881 which it will respond with a new request, including the following 882 Authorization header if the client chooses MD5 digest: 884 Authorization:Digest username="Mufasa", 885 realm="testrealm@host.com", 886 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 887 uri="/dir/index.html", 888 qop="auth", 889 algorithm="MD5", 890 nc=00000001, 891 cnonce="0a4f113b", 892 response="6629fae49393a05397450978507c4ef1", 893 opaque="5ccc069c403ebaf9f0171e9517f40e41" 895 If the client chooses to use the SHA2-256 algorithm for calculating 896 the response, the client responds with a new request including the 897 following Authorization header: 899 Authorization:Digest username="Mufasa", 900 realm="testrealm@host.com", 901 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 902 uri="/dir/index.html", 903 qop="auth", 904 algorithm="SHA2-256", 905 nc=00000001, 906 cnonce="0a4f113b", 907 response="5abdd07184ba512a22c53f41470e5eea7dcaa3a93 908 a59b630c13dfe0a5dc6e38b", 909 opaque="5ccc069c403ebaf9f0171e9517f40e41" 911 4 Internationalization 913 In challenges, servers SHOULD use the "charset" authentication 914 parameter (case-insensitive) to express the character encoding they 915 expect the user agent to use. 917 The only allowed value is "UTF-8", to be matched case-insensitively, 918 indicating that the server expects the UTF-8 character encoding to be 919 used ([RFC3629]). 921 If the user agent supports the encoding indicated by the server, it 922 MAY add the "charset" parameter, with the value it received from the 923 server, to the Proxy-Authenticate or WWW-Authenticate header fields 924 it sends back to the server. 926 If the user agent does not support the encoding indicated by the 927 server, it MAY add the "charset" parameter to the Proxy-Authenticate 928 or WWW-Authenticate header fields it sends back to the server, but 929 the value in the parameter should be preceded by an exclamation point 930 (!). 932 5 Security Considerations 934 5.1 Limitations 936 HTTP Digest authentication, when used with human-memorable passwords, 937 is vulnerable to dictionary attacks. Such attacks are much easier 938 than cryptographic attacks on any widely used algorithm, including 939 those that are no longer considered secure. In other words, algorithm 940 agility does not make this usage any more secure. 942 As a result, Digest authentication SHOULD be used only with passwords 943 that have a reasonable amount of entropy, e.g. 128-bit or more. Such 944 passwords typically cannot be memorized by humans but can be used for 945 automated web services. 947 It is recommended that Digest authentication be used over a secure 948 channel like HTTPS. 950 5.2 Authentication of Clients using Digest Authentication 952 Digest Authentication does not provide a strong authentication 953 mechanism, when compared to public key based mechanisms, for example. 955 However, it is significantly stronger than (e.g.) CRAM-MD5, which has 956 been proposed for use with LDAP [10], POP and IMAP (see RFC 2195 958 [9]). It is intended to replace the much weaker and even more 959 dangerous Basic mechanism. 961 Digest Authentication offers no confidentiality protection beyond 962 protecting the actual password. All of the rest of the request and 963 response are available to an eavesdropper. 965 Digest Authentication offers only limited integrity protection for 966 the messages in either direction. If qop=auth-int mechanism is used, 967 those parts of the message used in the calculation of the WWW- 968 Authenticate and Authorization header field response directive values 969 (see section 3.2 above) are protected. Most header fields and their 970 values could be modified as a part of a man-in-the-middle attack. 972 Many needs for secure HTTP transactions cannot be met by Digest 973 Authentication. For those needs TLS or SHTTP are more appropriate 974 protocols. In particular Digest authentication cannot be used for any 975 transaction requiring confidentiality protection. Nevertheless many 976 functions remain for which Digest authentication is both useful and 977 appropriate. Any service in present use that uses Basic should be 978 switched to Digest as soon as practical. 980 5.3 Limited Use Nonce Values 982 The Digest scheme uses a server-specified nonce to seed the 983 generation of the request-digest value (as specified in section 984 3.2.2.1 above). As shown in the example nonce in section 3.2.1, the 985 server is free to construct the nonce such that it may only be used 986 from a particular client, for a particular resource, for a limited 987 period of time or number of uses, or any other restrictions. Doing 988 so strengthens the protection provided against, for example, replay 989 attacks (see 4.5). However, it should be noted that the method 990 chosen for generating and checking the nonce also has performance and 991 resource implications. For example, a server may choose to allow 992 each nonce value to be used only once by maintaining a record of 993 whether or not each recently issued nonce has been returned and 994 sending a next-nonce directive in the Authentication-Info header 995 field of every response. This protects against even an immediate 996 replay attack, but has a high cost checking nonce values, and perhaps 997 more important will cause authentication failures for any pipelined 998 requests (presumably returning a stale nonce indication). Similarly, 999 incorporating a request-specific element such as the Etag value for a 1000 resource limits the use of the nonce to that version of the resource 1001 and also defeats pipelining. Thus it may be useful to do so for 1002 methods with side effects but have unacceptable performance for those 1003 that do not. 1005 5.4 Replay Attacks 1007 A replay attack against Digest authentication would usually be 1008 pointless for a simple GET request since an eavesdropper would 1009 already have seen the only document he could obtain with a replay. 1010 This is because the URI of the requested document is digested in the 1011 client request and the server will only deliver that document. By 1012 contrast under Basic Authentication once the eavesdropper has the 1013 user's password, any document protected by that password is open to 1014 him. 1016 Thus, for some purposes, it is necessary to protect against replay 1017 attacks. A good Digest implementation can do this in various ways. 1018 The server created "nonce" value is implementation dependent, but if 1019 it contains a digest of the client IP, a time-stamp, the resource 1020 ETag, and a private server key (as recommended above) then a replay 1021 attack is not simple. An attacker must convince the server that the 1022 request is coming from a false IP address and must cause the server 1023 to deliver the document to an IP address different from the address 1024 to which it believes it is sending the document. An attack can only 1025 succeed in the period before the time-stamp expires. Digesting the 1026 client IP and time-stamp in the nonce permits an implementation which 1027 does not maintain state between transactions. 1029 For applications where no possibility of replay attack can be 1030 tolerated the server can use one-time nonce values which will not be 1031 honored for a second use. This requires the overhead of the server 1033 remembering which nonce values have been used until the nonce time- 1034 stamp (and hence the digest built with it) has expired, but it 1035 effectively protects against replay attacks. 1037 An implementation must give special attention to the possibility of 1038 replay attacks with POST and PUT requests. Unless the server employs 1039 one-time or otherwise limited-use nonces and/or insists on the use of 1040 the integrity protection of qop=auth-int, an attacker could replay 1041 valid credentials from a successful request with counterfeit form 1042 data or other message body. Even with the use of integrity protection 1043 most metadata in header fields is not protected. Proper nonce 1044 generation and checking provides some protection against replay of 1045 previously used valid credentials, but see 4.8. 1047 5.5 Weakness Created by Multiple Authentication Schemes 1049 An HTTP/1.1 server may return multiple challenges with a 401 1050 (Authenticate) response, and each challenge may use a different auth- 1051 scheme. A user agent MUST choose to use the strongest auth- scheme it 1052 understands and request credentials from the user based upon that 1053 challenge. 1055 Note that many browsers will only recognize Basic and will require 1056 that it be the first auth-scheme presented. Servers should only 1057 include Basic if it is minimally acceptable. 1059 When the server offers choices of authentication schemes using the 1060 WWW-Authenticate header, the strength of the resulting authentication 1061 is only as good as that of the of the weakest of the authentication 1062 schemes. See section 5.7 below for discussion of particular attack 1063 scenarios that exploit multiple authentication schemes. 1065 5.6 Online dictionary attacks 1067 If the attacker can eavesdrop, then it can test any overheard 1068 nonce/response pairs against a list of common words. Such a list is 1069 usually much smaller than the total number of possible passwords. The 1070 cost of computing the response for each password on the list is paid 1071 once for each challenge. 1073 The server can mitigate this attack by not allowing users to select 1074 passwords that are in a dictionary. 1076 5.7 Man in the Middle 1078 Both Basic and Digest authentication are vulnerable to "man in the 1079 middle" (MITM) attacks, for example, from a hostile or compromised 1080 proxy. Clearly, this would present all the problems of eavesdropping. 1081 But it also offers some additional opportunities to the attacker. 1083 A possible man-in-the-middle attack would be to add a weak 1084 authentication scheme to the set of choices, hoping that the client 1085 will use one that exposes the user's credentials (e.g. password). For 1086 this reason, the client should always use the strongest scheme that 1087 it understands from the choices offered. 1089 An even better MITM attack would be to remove all offered choices, 1090 replacing them with a challenge that requests only Basic 1091 authentication, then uses the cleartext credentials from the Basic 1092 authentication to authenticate to the origin server using the 1093 stronger scheme it requested. A particularly insidious way to mount 1094 such a MITM attack would be to offer a "free" proxy caching service 1095 to gullible users. 1097 User agents should consider measures such as presenting a visual 1098 indication at the time of the credentials request of what 1099 authentication scheme is to be used, or remembering the strongest 1100 authentication scheme ever requested by a server and produce a 1101 warning message before using a weaker one. It might also be a good 1102 idea for the user agent to be configured to demand Digest 1103 authentication in general, or from specific sites. 1105 Or, a hostile proxy might spoof the client into making a request the 1106 attacker wanted rather than one the client wanted. Of course, this is 1107 still much harder than a comparable attack against Basic 1108 Authentication. 1110 5.8 Chosen plaintext attacks 1112 With Digest authentication, a MITM or a malicious server can 1113 arbitrarily choose the nonce that the client will use to compute the 1114 response. This is called a "chosen plaintext" attack. The ability to 1115 choose the nonce is known to make cryptanalysis much easier [8]. 1117 However, no way to analyze the MD5 one-way function used by Digest 1118 using chosen plaintext is currently known. 1120 The countermeasure against this attack is for clients to be 1121 configured to require the use of the optional "cnonce" directive; 1122 this allows the client to vary the input to the hash in a way not 1123 chosen by the attacker. 1125 5.9 Precomputed dictionary attacks 1127 With Digest authentication, if the attacker can execute a chosen 1128 plaintext attack, the attacker can precompute the response for many 1129 common words to a nonce of its choice, and store a dictionary of 1130 (response, password) pairs. Such precomputation can often be done in 1131 parallel on many machines. It can then use the chosen plaintext 1132 attack to acquire a response corresponding to that challenge, and 1133 just look up the password in the dictionary. Even if most passwords 1134 are not in the dictionary, some might be. Since the attacker gets to 1135 pick the challenge, the cost of computing the response for each 1136 password on the list can be amortized over finding many passwords. A 1137 dictionary with 100 million password/response pairs would take about 1138 3.2 gigabytes of disk storage. 1140 The countermeasure against this attack is to for clients to be 1141 configured to require the use of the optional "cnonce" directive. 1143 5.10 Batch brute force attacks 1145 With Digest authentication, a MITM can execute a chosen plaintext 1146 attack, and can gather responses from many users to the same nonce. 1147 It can then find all the passwords within any subset of password 1148 space that would generate one of the nonce/response pairs in a single 1149 pass over that space. It also reduces the time to find the first 1150 password by a factor equal to the number of nonce/response pairs 1151 gathered. This search of the password space can often be done in 1152 parallel on many machines, and even a single machine can search large 1153 subsets of the password space very quickly -- reports exist of 1154 searching all passwords with six or fewer letters in a few hours. 1156 The countermeasure against this attack is to for clients to be 1157 configured to require the use of the optional "cnonce" directive. 1159 5.11 Spoofing by Counterfeit Servers 1161 Basic Authentication is vulnerable to spoofing by counterfeit 1162 servers. If a user can be led to believe that she is connecting to a 1163 host containing information protected by a password she knows, when 1164 in fact she is connecting to a hostile server, then the hostile 1165 server can request a password, store it away for later use, and feign 1166 an error. This type of attack is more difficult with Digest 1167 Authentication -- but the client must know to demand that Digest 1168 authentication be used, perhaps using some of the techniques 1169 described above to counter "man-in-the-middle" attacks. Again, the 1170 user can be helped in detecting this attack by a visual indication of 1171 the authentication mechanism in use with appropriate guidance in 1172 interpreting the implications of each scheme. 1174 5.12 Storing passwords 1176 Digest authentication requires that the authenticating agent (usually 1177 the server) store some data derived from the user's name and password 1178 in a "password file" associated with a given realm. Normally this 1179 might contain pairs consisting of username and H(A1), where H(A1) is 1180 the digested value of the username, realm, and password as described 1181 above. 1183 The security implications of this are that if this password file is 1184 compromised, then an attacker gains immediate access to documents on 1185 the server using this realm. Unlike, say a standard UNIX password 1186 file, this information need not be decrypted in order to access 1187 documents in the server realm associated with this file. On the other 1188 hand, decryption, or more likely a brute force attack, would be 1189 necessary to obtain the user's password. This is the reason that the 1190 realm is part of the digested data stored in the password file. It 1191 means that if one Digest authentication password file is compromised, 1192 it does not automatically compromise others with the same username 1193 and password (though it does expose them to brute force attack). 1195 There are two important security consequences of this. First the 1196 password file must be protected as if it contained unencrypted 1197 passwords, because for the purpose of accessing documents in its 1198 realm, it effectively does. 1200 A second consequence of this is that the realm string should be 1201 unique among all realms which any single user is likely to use. In 1202 particular a realm string should include the name of the host doing 1203 the authentication. The inability of the client to authenticate the 1204 server is a weakness of Digest Authentication. 1206 5.13 Summary 1208 By modern cryptographic standards Digest Authentication is weak. But 1209 for a large range of purposes it is valuable as a replacement for 1210 Basic Authentication. It remedies some, but not all, weaknesses of 1211 Basic Authentication. Its strength may vary depending on the 1212 implementation. In particular the structure of the nonce (which is 1213 dependent on the server implementation) may affect the ease of 1214 mounting a replay attack. A range of server options is appropriate 1215 since, for example, some implementations may be willing to accept the 1216 server overhead of one-time nonces or digests to eliminate the 1217 possibility of replay. Others may satisfied with a nonce like the one 1218 recommended above restricted to a single IP address and a single ETag 1219 or with a limited lifetime. 1221 The bottom line is that *any* compliant implementation will be 1222 relatively weak by cryptographic standards, but *any* compliant 1223 implementation will be far superior to Basic Authentication. 1225 6 IANA Considerations 1227 This specification creates a new IANA registry named "HTTP Digest 1228 Hash Algorithms". When registering a new hash algorithm, the 1229 following information MUST be provided: 1231 o The textual name of the hash algorithm. 1232 o A reference to the specification that describes the new algorithm. 1234 The update policy for this registry shall be Specification Required. 1236 The initial registry will contain the following entries: 1238 Hash Algorithm Reference 1239 ------------------ --------- 1240 "MD5" RFC XXXX 1241 "MD5-sess" RFC XXXX 1242 "SHA2-256" RFC XXXX 1243 "SHA2-256-sess" RFC XXXX 1244 "SHA2-512-256" RFC XXXX 1245 "SHA2-512-256-sess" RFC XXXX 1247 7 Acknowledgments 1249 TODO 1251 8 References 1253 8.1 Normative References 1255 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1256 Requirement Levels", BCP 14, RFC 2119, March 1997. 1258 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1259 1 1995. 1261 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 1262 April 1 1996. 1264 8.2 Informative References 1266 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 1267 RFC 3514, April 1 2003. 1269 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 1270 Acronyms", RFC 5513, April 1 2009. 1272 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 1273 2009. 1275 Authors' Addresses 1277 Rifaat Shekh-Yusef (Editor) 1278 Avaya 1279 250 Sydney Street 1280 Belleville, Ontario 1281 Canada 1283 Phone: +1-613-967-5267 1284 Email: rifaat.ietf@gmail.com 1286 David Ahrens 1287 Avaya 1288 California 1289 USA 1291 EMail: ahrensdc@gmail.com 1293 Sophie Bremer 1294 Netzkonform 1295 Germany 1297 Email: sophie.bremer@netzkonform.de