idnits 2.17.1 draft-ietf-httpauth-digest-00.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 303 has weird spacing: '...quality of th...' == Line 335 has weird spacing: '...eturned by th...' == Line 607 has weird spacing: '...ptional clien...' == Line 653 has weird spacing: '...hanging nonce...' == Line 925 has weird spacing: '...ion. If qop=a...' == (1 more instance...) -- The document date (October 7, 2013) is 3854 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 section? 'RFC2616' on line 794 looks like a reference -- Missing reference section? 'RFC2119' on line 201 looks like a reference -- Missing reference section? '7' on line 280 looks like a reference -- Missing reference section? 'RFC2069' on line 459 looks like a reference -- Missing reference section? 'SHA3' on line 780 looks like a reference -- Missing reference section? 'RFC3629' on line 879 looks like a reference -- Missing reference section? '10' on line 916 looks like a reference -- Missing reference section? '9' on line 917 looks like a reference -- Missing reference section? '8' on line 1073 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 11 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, Ed. 4 Obsoletes: 2617 (if approved) Avaya 5 Intended Status: Standards Track October 7, 2013 6 Expires: April 10, 2014 8 HTTP Digest Access Authentication 9 draft-ietf-httpauth-digest-00.txt 11 Abstract 13 HTTP provides a simple challenge-response authentication mechanism 14 that may be used by a server to challenge a client request and by a 15 client to provide authentication information. This document defines 16 the HTTP Digest Authentication scheme that may be used with the 17 authentication mechanism. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2 Syntax Convention . . . . . . . . . . . . . . . . . . . . . . . 6 60 3 Digest Access Authentication Scheme . . . . . . . . . . . . . . 6 61 3.1 Overall Operation . . . . . . . . . . . . . . . . . . . . . 6 62 3.2 Representation of Digest Values . . . . . . . . . . . . . . 6 63 3.3 The WWW-Authenticate Response Header . . . . . . . . . . . . 7 64 3.4 The Authorization Request Header . . . . . . . . . . . . . . 10 65 3.4.1 Request-Digest . . . . . . . . . . . . . . . . . . . . . 12 66 3.4.2 A1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.4.3 A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 3.4.4 Directive Values and Quoted-String . . . . . . . . . . . 13 69 3.4.5 Various Considerations . . . . . . . . . . . . . . . . . 14 70 3.6 Digest Operation . . . . . . . . . . . . . . . . . . . . . . 16 71 3.7 Security Protocol Negotiation . . . . . . . . . . . . . . . 18 72 3.8 Proxy-Authentication and Proxy-Authorization . . . . . . . . 18 73 3.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 4 Internationalization . . . . . . . . . . . . . . . . . . . . . . 21 75 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 21 76 5.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 21 77 5.2 Authentication of Clients using Digest Authentication . . . 21 78 5.3 Limited Use Nonce Values . . . . . . . . . . . . . . . . . . 22 79 5.4 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 80 5.5 Weakness Created by Multiple Authentication Schemes . . . . 23 81 5.6 Online dictionary attacks . . . . . . . . . . . . . . . . . 24 82 5.7 Man in the Middle . . . . . . . . . . . . . . . . . . . . . 24 83 5.8 Chosen plaintext attacks . . . . . . . . . . . . . . . . . . 25 84 5.9 Precomputed dictionary attacks . . . . . . . . . . . . . . . 25 85 5.10 Batch brute force attacks . . . . . . . . . . . . . . . . . 25 86 5.11 Spoofing by Counterfeit Servers . . . . . . . . . . . . . . 26 87 5.12 Storing passwords . . . . . . . . . . . . . . . . . . . . . 26 88 5.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 90 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 92 7.2 Informative References . . . . . . . . . . . . . . . . . . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 95 1 Introduction 97 HTTP provides a simple challenge-response authentication mechanism 98 that MAY be used by a server to challenge a client request and by a 99 client to provide authentication information. It uses an extensible, 100 case-insensitive token to identify the authentication scheme, 101 followed by a comma-separated list of attribute-value pairs which 102 carry the parameters necessary for achieving authentication via that 103 scheme. 105 auth-scheme = token 106 auth-param = token "=" ( token | quoted-string ) 108 The 401 (Unauthorized) response message is used by an origin server 109 to challenge the authorization of a user agent. This response MUST 110 include a WWW-Authenticate header field containing at least one 111 challenge applicable to the requested resource. The 407 (Proxy 112 Authentication Required) response message is used by a proxy to 113 challenge the authorization of a client and MUST include a Proxy- 114 Authenticate header field containing at least one challenge 115 applicable to the proxy for the requested resource. 117 challenge = auth-scheme 1*SP 1#auth-param 119 Note: User agents will need to take special care in parsing the WWW- 120 Authenticate or Proxy-Authenticate header field value if it contains 121 more than one challenge, or if more than one WWW-Authenticate header 122 field is provided, since the contents of a challenge may itself 123 contain a comma-separated list of authentication parameters. 125 The authentication parameter realm is defined for all authentication 126 schemes: 128 realm = "realm" "=" realm-value 129 realm-value = quoted-string 131 The realm directive (case-insensitive) is required for all 132 authentication schemes that issue a challenge. The realm value (case- 133 sensitive), in combination with the canonical root URL (the 134 absoluteURI for the server whose abs_path is empty; see section 5.1.2 135 of [RFC2616]) of the server being accessed, defines the protection 136 space. These realms allow the protected resources on a server to be 137 partitioned into a set of protection spaces, each with its own 138 authentication scheme and/or authorization database. The realm value 139 is a string, generally assigned by the origin server, which may have 140 additional semantics specific to the authentication scheme. Note that 141 there may be multiple challenges with the same auth-scheme but 142 different realms. 144 A user agent that wishes to authenticate itself with an origin 145 server--usually, but not necessarily, after receiving a 401 146 (Unauthorized)--MAY do so by including an Authorization header field 147 with the request. A client that wishes to authenticate itself with a 148 proxy--usually, but not necessarily, after receiving a 407 (Proxy 149 Authentication Required)--MAY do so by including a Proxy- 150 Authorization header field with the request. Both the Authorization 151 field value and the Proxy-Authorization field value consist of 152 credentials containing the authentication information of the client 153 for the realm of the resource being requested. The user agent MUST 154 choose to use one of the challenges with the strongest auth-scheme it 155 understands and request credentials from the user based upon that 156 challenge. 158 credentials = auth-scheme #auth-param 160 Note that many browsers will only recognize Basic and will require 161 that it be the first auth-scheme presented. Servers should only 162 include Basic if it is minimally acceptable. 164 The protection space determines the domain over which credentials can 165 be automatically applied. If a prior request has been authorized, the 166 same credentials MAY be reused for all other requests within that 167 protection space for a period of time determined by the 168 authentication scheme, parameters, and/or user preference. Unless 169 otherwise defined by the authentication scheme, a single protection 170 space cannot extend outside the scope of its server. 172 If the origin server does not wish to accept the credentials sent 173 with a request, it SHOULD return a 401 (Unauthorized) response. The 174 response MUST include a WWW-Authenticate header field containing at 175 least one (possibly new) challenge applicable to the requested 176 resource. If a proxy does not accept the credentials sent with a 177 request, it SHOULD return a 407 (Proxy Authentication Required). The 178 response MUST include a Proxy-Authenticate header field containing a 179 (possibly new) challenge applicable to the proxy for the requested 180 resource. 182 The HTTP protocol does not restrict applications to this simple 183 challenge-response mechanism for access authentication. Additional 184 mechanisms MAY be used, such as encryption at the transport level or 185 via message encapsulation, and with additional header fields 186 specifying authentication information. However, these additional 187 mechanisms are not defined by this specification. 189 Proxies MUST be completely transparent regarding user agent 190 authentication by origin servers. That is, they must forward the WWW- 191 Authenticate and Authorization headers untouched, and follow the 192 rules found in section 14.8 of [RFC2616]. Both the Proxy-Authenticate 193 and the Proxy-Authorization header fields are hop-by-hop headers (see 194 section 13.5.1 of [RFC2616]). 196 1.1 Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in RFC 2119 [RFC2119]. 202 2 Syntax Convention 204 In the interest of clarity and readability, the extended parameters 205 or the headers and parameters in the examples in this document might 206 be broken into multiple lines. Any line that is indented in this 207 document is a continuation of the preceding line. 209 3 Digest Access Authentication Scheme 211 3.1 Overall Operation 213 The Digest scheme is based on a simple challenge-response paradigm. 214 The Digest scheme challenges using a nonce value. A valid response 215 contains a checksum of the username, the password, the given nonce 216 value, the HTTP method, and the requested URI. In this way, the 217 password is never sent in the clear. The username and password must 218 be prearranged in some fashion not addressed by this document. 220 3.2 Representation of Digest Values 222 An optional header allows the server to specify the algorithm used to 223 create the checksum or digest. By default the SHA2-256 algorithm is 224 used, with SHA2-512/256 being used as a backup algorithm. To 225 maintain backwards compatibility, the MD5 algorithm is still 226 supported but not recommended. 228 The size of the digest depends on the algorithm used. The bits in 229 the digest are converted from the most significant to the least 230 significant bit, four bits at a time to the ASCII representation as 231 follows. Each four bits is represented by its familiar hexadecimal 232 notation from the characters 0123456789abcdef, that is binary 0000 is 233 represented by the character '0', 0001 by '1' and so on up to the 234 representation of 1111 as 'f'. If the MD5 algorithm is used to 235 calculate the digest, then the digest will be represented as 32 236 hexadecimal characters, SHA2-256 and SHA2-512/256 by 64 hexadecimal 237 characters. 239 3.3 The WWW-Authenticate Response Header 241 If a server receives a request for an access-protected object, and an 242 acceptable Authorization header is not sent, the server responds with 243 a "401 Unauthorized" status code, and a WWW-Authenticate header as 244 per the framework defined above, which for the digest scheme is 245 utilized as follows: 247 challenge = "Digest" digest-challenge 249 digest-challenge = 1#( realm | [ domain ] | nonce | 250 [ opaque ] |[ stale ] | [ algorithm ] | 251 [ qop-options ] | [charset] | [auth-param]) 253 domain = "domain" "=" <"> URI ( 1*SP URI ) <"> 254 URI = absoluteURI | abs_path 255 nonce = "nonce" "=" nonce-value 256 nonce-value = quoted-string 257 opaque = "opaque" "=" quoted-string 258 stale = "stale" "=" ( "true" | "false" ) 259 algorithm = "algorithm" "=" ( 260 "MD5" | "MD5-sess" | 261 "SHA2-256" | "SHA2-256-sess" | 262 "SHA2-512-256" | "SHA2-512-256-sess" | 263 token) 264 qop-options = "qop" "=" <"> 1#qop-value <"> 265 qop-value = "auth" | "auth-int" | token 266 charset = "charset" "=" ("UTF-8" | token) 268 The meanings of the values of the directives used above are as 269 follows: 271 realm 272 A string to be displayed to users so they know which username and 273 password to use. This string should contain at least the name of 274 the host performing the authentication and might additionally 275 indicate the collection of users who might have access. An example 276 might be "registered_users@gotham.news.com". 278 domain 279 A quoted, space-separated list of URIs, as specified in RFC XURI 280 [7], that define the protection space. If a URI is an abs_path, 281 it is relative to the canonical root URL of the server being 282 accessed. An absoluteURI in this list may refer to a different 283 server than the one being accessed. The client can use this list 284 to determine the set of URIs for which the same authentication 285 information may be sent: any URI that has a URI in this list as a 286 prefix (after both have been made absolute) may be assumed to be 287 in the same protection space. If this directive is omitted or its 288 value is empty, the client should assume that the protection space 289 consists of all URIs on the responding server. 291 This directive is not meaningful in Proxy-Authenticate headers, 292 for which the protection space is always the entire proxy; if 293 present it should be ignored. 295 nonce 296 A server-specified data string which should be uniquely generated 297 each time a 401 response is made. It is recommended that this 298 string be base64 or hexadecimal data. Specifically, since the 299 string is passed in the header lines as a quoted string, the 300 double-quote character is not allowed. 302 The contents of the nonce are implementation dependent. The 303 quality of the implementation depends on a good choice. A nonce 304 might, for example, be constructed as the base 64 encoding of 306 time-stamp H(time-stamp ":" ETag ":" private-key) 308 where time-stamp is a server-generated time or other non-repeating 309 value, ETag is the value of the HTTP ETag header associated with 310 the requested entity, and private-key is data known only to the 311 server. With a nonce of this form a server would recalculate the 312 hash portion after receiving the client authentication header and 313 reject the request if it did not match the nonce from that header 314 or if the time-stamp value is not recent enough. In this way the 315 server can limit the time of the nonce's validity. The inclusion 316 of the ETag prevents a replay request for an updated version of 317 the resource. (Note: including the IP address of the client in 318 the nonce would appear to offer the server the ability to limit 319 the reuse of the nonce to the same client that originally got it. 320 However, that would break proxy farms, where requests from a 321 single user often go through different proxies in the farm. Also, 322 IP address spoofing is not that hard.) 324 An implementation might choose not to accept a previously used 325 nonce or a previously used digest, in order to protect against a 326 replay attack. Or, an implementation might choose to use one-time 327 nonces or digests for POST or PUT requests and a time-stamp for 328 GET requests. For more details on the issues involved see section 329 5 of this document. 331 The nonce is opaque to the client. 333 opaque 334 A string of data, specified by the server, which should be 335 returned by the client unchanged in the Authorization header of 336 subsequent requests with URIs in the same protection space. It is 337 recommended that this string be base64 or hexadecimal data. 339 stale 340 A flag, indicating that the previous request from the client was 341 rejected because the nonce value was stale. If stale is TRUE 342 (case-insensitive), the client may wish to simply retry the 343 request with a new encrypted response, without reprompting the 344 user for a new username and password. The server should only set 345 stale to TRUE if it receives a request for which the nonce is 346 invalid but with a valid digest for that nonce (indicating that 347 the client knows the correct username/password). If stale is 348 FALSE, or anything other than TRUE, or the stale directive is not 349 present, the username and/or password are invalid, and new values 350 must be obtained. 352 algorithm 353 A string indicating a pair of algorithms used to produce the 354 digest and a checksum. If this is not present it is assumed to be 355 "MD5". If the algorithm is not understood, the challenge should be 356 ignored (and a different one used, if there is more than one). 358 In this document the string obtained by applying the digest 359 algorithm to the data "data" with secret "secret" will be denoted 360 by KD(secret, data), and the string obtained by applying the 361 checksum algorithm to the data "data" will be denoted H(data). The 362 notation unq(X) means the value of the quoted-string X without the 363 surrounding quotes. 365 For the "MD5" and "MD5-sess" algorithms 367 H(data) = MD5(data) 369 For the "SHA2-256" and "SHA2-256-sess" algorithms 371 H(data) = SHA2-256(data) 373 For the "SHA2-512-256" and "SHA2-512-256-sess" algorithms 375 H(data) = SHA2-512-256(data) 377 and 379 KD(secret, data) = H(concat(secret, ":", data)) 381 i.e., the digest is the MD5 of the secret concatenated with a 382 colon concatenated with the data. The "MD5-sess" algorithm is 383 intended to allow efficient 3rd party authentication servers; 384 for the difference in usage, see the description in section 385 3.4.2. 387 qop-options 388 This directive is optional, but is made so only for backward 389 compatibility with RFC 2069 [RFC2069]; it SHOULD be used by all 390 implementations compliant with this version of the Digest scheme. 391 If present, it is a quoted string of one or more tokens indicating 392 the "quality of protection" values supported by the server. The 393 value "auth" indicates authentication; the value "auth-int" 394 indicates authentication with integrity protection; see the 395 descriptions below for calculating the response directive value 396 for the application of this choice. Unrecognized options MUST be 397 ignored. 399 charset 400 This is an optional parameter that could be used by the server to 401 indicate the encoding scheme it supports. 403 auth-param 404 This directive allows for future extensions. Any unrecognized 405 directive MUST be ignored. 407 3.4 The Authorization Request Header 409 The client is expected to retry the request, passing an Authorization 410 header line, which is defined according to the framework above, 411 utilized as follows. 413 credentials = "Digest" digest-response 414 digest-response = 1#( username | realm | nonce | digest-uri | 415 response | [ algorithm ] | [cnonce] | 416 [opaque] | [message-qop] | 417 [nonce-count] | [charset] | [auth-param] ) 418 username = "username" "=" username-value 419 username-value = quoted-string 420 digest-uri = "uri" "=" digest-uri-value 421 digest-uri-value = request-uri ; As specified by HTTP/1.1 422 message-qop = "qop" "=" qop-value 423 cnonce = "cnonce" "=" cnonce-value 424 cnonce-value = nonce-value 425 nonce-count = "nc" "=" nc-value 426 nc-value = 8LHEX 427 response = "response" "=" request-digest 428 request-digest = <"> digest-size LHEX <"> 429 digest-size = "32" | "64" 430 LHEX = "0" | "1" | "2" | "3" | 431 "4" | "5" | "6" | "7" | 432 "8" | "9" | "a" | "b" | 433 "c" | "d" | "e" | "f" 434 charset = "charset" "=" ("UTF-8" | token) 436 The values of the opaque and algorithm fields must be those supplied 437 in the WWW-Authenticate response header for the entity being 438 requested. 440 response 441 A string of digest-size hex digits computed as defined below, 442 which proves that the user knows a password 444 username 445 The user's name in the specified realm. 447 digest-uri 448 The URI from Request-URI of the Request-Line; duplicated here 449 because proxies are allowed to change the Request-Line in transit. 451 qop 452 Indicates what "quality of protection" the client has applied to 453 the message. If present, its value MUST be one of the alternatives 454 the server indicated it supports in the WWW-Authenticate header. 455 These values affect the computation of the request-digest. Note 456 that this is a single token, not a quoted list of alternatives as 457 in WWW- Authenticate. This directive is optional in order to 458 preserve backward compatibility with a minimal implementation of 459 RFC 2069 [RFC2069], but SHOULD be used if the server indicated 460 that qop is supported by providing a qop directive in the WWW- 461 Authenticate header field. 463 cnonce 464 This MUST be specified if a qop directive is sent (see above), and 465 MUST NOT be specified if the server did not send a qop directive 466 in the WWW-Authenticate header field. The cnonce-value is an 467 opaque quoted string value provided by the client and used by both 468 client and server to avoid chosen plaintext attacks, to provide 469 mutual authentication, and to provide some message integrity 470 protection. See the descriptions below of the calculation of the 471 response- digest and request-digest values. 473 nonce-count 474 This MUST be specified if a qop directive is sent (see above), and 475 MUST NOT be specified if the server did not send a qop directive 476 in the WWW-Authenticate header field. The nc-value is the 477 hexadecimal count of the number of requests (including the current 478 request) that the client has sent with the nonce value in this 479 request. For example, in the first request sent in response to a 480 given nonce value, the client sends "nc=00000001". The purpose of 481 this directive is to allow the server to detect request replays by 482 maintaining its own copy of this count - if the same nc-value is 483 seen twice, then the request is a replay. See the description 484 below of the construction of the request-digest value. 486 charset 487 This is an optional parameter that could be used by the client to 488 indicate the encoding scheme it supports. 490 auth-param 491 This directive allows for future extensions. Any unrecognized 492 directive MUST be ignored. 494 If a directive or its value is improper, or required directives are 495 missing, the proper response is 400 Bad Request. If the request- 496 digest is invalid, then a login failure should be logged, since 497 repeated login failures from a single client may indicate an attacker 498 attempting to guess passwords. 500 The definition of request-digest above indicates the encoding for its 501 value. The following definitions show how the value is computed. 503 3.4.1 Request-Digest 505 If the "qop" value is "auth" or "auth-int": 507 request-digest = <"> < KD ( H(A1), unq(nonce-value) 508 ":" nc-value 509 ":" unq(cnonce-value) 510 ":" unq(qop-value) 511 ":" H(A2) 512 ) <"> 514 If the "qop" directive is not present (this construction is for 515 compatibility with RFC 2069): 517 request-digest = 518 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > 519 <"> 521 See below for the definitions for A1 and A2. 523 3.4.2 A1 525 If the "algorithm" directive's value is "MD5", "SHA2-256", or "SHA2- 526 512-256", then A1 is: 528 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 530 where 532 passwd = < user's password > 534 If the "algorithm" directive's value is "MD5-sess", "SHA2-256", or 535 "SHA2-512-256", then A1 is calculated only once - on the first 536 request by the client following receipt of a WWW-Authenticate 537 challenge from the server. It uses the server nonce from that 538 challenge, and the first client nonce value to construct A1 as 539 follows: 541 A1 = H( unq(username-value) ":" unq(realm-value) 542 ":" passwd ) 543 ":" unq(nonce-value) ":" unq(cnonce-value) 545 This creates a 'session key' for the authentication of subsequent 546 requests and responses which is different for each "authentication 547 session", thus limiting the amount of material hashed with any one 548 key. (Note: see further discussion of the authentication session in 549 section 3.6.) Because the server need only use the hash of the user 550 credentials in order to create the A1 value, this construction could 551 be used in conjunction with a third party authentication service so 552 that the web server would not need the actual password value. The 553 specification of such a protocol is beyond the scope of this 554 specification. 556 3.4.3 A2 558 If the "qop" directive's value is "auth" or is unspecified, then A2 559 is: 561 A2 = Method ":" digest-uri-value 563 If the "qop" value is "auth-int", then A2 is: 565 A2 = Method ":" digest-uri-value ":" H(entity-body) 567 3.4.4 Directive Values and Quoted-String 568 Note that the value of many of the directives, such as "username- 569 value", are defined as a "quoted-string". However, the "unq" notation 570 indicates that surrounding quotation marks are removed in forming the 571 string A1. Thus if the Authorization header includes the fields 573 username="Mufasa", realm=myhost@testrealm.com 575 and the user Mufasa has password "Circle Of Life" then H(A1) would be 576 H(Mufasa:myhost@testrealm.com:Circle Of Life) with no quotation marks 577 in the digested string. 579 No white space is allowed in any of the strings to which the digest 580 function H() is applied unless that white space exists in the quoted 581 strings or entity body whose contents make up the string to be 582 digested. For example, the string A1 illustrated above must be 584 Mufasa:myhost@testrealm.com:Circle Of Life 586 with no white space on either side of the colons, but with the white 587 space between the words used in the password value. Likewise, the 588 other strings digested by H() must not have white space on either 589 side of the colons which delimit their fields unless that white space 590 was in the quoted strings or entity body being digested. 592 Also note that if integrity protection is applied (qop=auth-int), the 593 H(entity-body) is the hash of the entity body, not the message body - 594 it is computed before any transfer encoding is applied by the sender 595 and after it has been removed by the recipient. Note that this 596 includes multipart boundaries and embedded headers in each part of 597 any multipart content-type. 599 3.4.5 Various Considerations 601 The "Method" value is the HTTP request method as specified in section 602 5.1.1 of [RFC2616]. The "request-uri" value is the Request-URI from 603 the request line as specified in section 5.1.2 of [RFC2616]. This may 604 be "*", an "absoluteURL" or an "abs_path" as specified in section 605 5.1.2 of [RFC2616], but it MUST agree with the Request-URI. In 606 particular, it MUST be an "absoluteURL" if the Request-URI is an 607 "absoluteURL". The "cnonce-value" is an optional client-chosen value 608 whose purpose is to foil chosen plaintext attacks. 610 The authenticating server must assure that the resource designated by 611 the "uri" directive is the same as the resource specified in the 612 Request-Line; if they are not, the server SHOULD return a 400 Bad 613 Request error. (Since this may be a symptom of an attack, server 614 implementers may want to consider logging such errors.) The purpose 615 of duplicating information from the request URL in this field is to 616 deal with the possibility that an intermediate proxy may alter the 617 client's Request-Line. This altered (but presumably semantically 618 equivalent) request would not result in the same digest as that 619 calculated by the client. 621 Implementers should be aware of how authenticated transactions 622 interact with shared caches. The HTTP/1.1 protocol specifies that 623 when a shared cache (see section 13.7 of [RFC2616]) has received a 624 request containing an Authorization header and a response from 625 relaying that request, it MUST NOT return that response as a reply to 626 any other request, unless one of two Cache-Control (see section 14.9 627 of [RFC2616]) directives was present in the response. If the original 628 response included the "must-revalidate" Cache-Control directive, the 629 cache MAY use the entity of that response in replying to a subsequent 630 request, but MUST first revalidate it with the origin server, using 631 the request headers from the new request to allow the origin server 632 to authenticate the new request. Alternatively, if the original 633 response included the "public" Cache-Control directive, the response 634 entity MAY be returned in reply to any subsequent request. 636 3.5 The Authentication-Info Header 638 The Authentication-Info header is used by the server to communicate 639 some information regarding the successful authentication in the 640 response. 642 AuthenticationInfo = "Authentication-Info" ":" auth-info 643 auth-info = 1#(nextnonce | [ message-qop ] 644 | [ response-auth ] | [ cnonce ] 645 | [nonce-count] ) 646 nextnonce = "nextnonce" "=" nonce-value 647 response-auth = "rspauth" "=" response-digest 648 response-digest = <"> *LHEX <"> 650 The value of the nextnonce directive is the nonce the server wishes 651 the client to use for a future authentication response. The server 652 may send the Authentication-Info header with a nextnonce field as a 653 means of implementing one-time or otherwise changing nonces. If the 654 nextnonce field is present the client SHOULD use it when constructing 655 the Authorization header for its next request. Failure of the client 656 to do so may result in a request to re-authenticate from the server 657 with the "stale=TRUE". 659 Server implementations should carefully consider the performance 660 implications of the use of this mechanism; pipelined requests will 661 not be possible if every response includes a nextnonce directive 662 that must be used on the next request received by the server. 664 Consideration should be given to the performance vs. security 665 tradeoffs of allowing an old nonce value to be used for a limited 666 time to permit request pipelining. Use of the nonce-count can 667 retain most of the security advantages of a new server nonce 668 without the deleterious affects on pipelining. 670 message-qop 671 Indicates the "quality of protection" options applied to the 672 response by the server. The value "auth" indicates 673 authentication; the value "auth-int" indicates authentication with 674 integrity protection. The server SHOULD use the same value for the 675 message- qop directive in the response as was sent by the client 676 in the corresponding request. 678 The optional response digest in the "response-auth" directive 679 supports mutual authentication -- the server proves that it knows the 680 user's secret, and with qop=auth-int also provides limited integrity 681 protection of the response. The "response-digest" value is calculated 682 as for the "request-digest" in the Authorization header, except that 683 if "qop=auth" or is not specified in the Authorization header for the 684 request, A2 is 686 A2 = ":" digest-uri-value 688 and if "qop=auth-int", then A2 is 690 A2 = ":" digest-uri-value ":" H(entity-body) 692 where "digest-uri-value" is the value of the "uri" directive on the 693 Authorization header in the request. The "cnonce-value" and "nc- 694 value" MUST be the ones for the client request to which this message 695 is the response. The "response-auth", "cnonce", and "nonce-count" 696 directives MUST BE present if "qop=auth" or "qop=auth-int" is 697 specified. 699 The Authentication-Info header is allowed in the trailer of an HTTP 700 message transferred via chunked transfer-coding. 702 3.6 Digest Operation 704 Upon receiving the Authorization header, the server may check its 705 validity by looking up the password that corresponds to the submitted 706 username. Then, the server must perform the same digest operation 707 (e.g., MD5) performed by the client, and compare the result to the 708 given request-digest value. 710 Note that the HTTP server does not actually need to know the user's 711 cleartext password. As long as H(A1) is available to the server, the 712 validity of an Authorization header may be verified. 714 The client response to a WWW-Authenticate challenge for a protection 715 space starts an authentication session with that protection space. 716 The authentication session lasts until the client receives another 717 WWW-Authenticate challenge from any server in the protection space. A 718 client should remember the username, password, nonce, nonce count and 719 opaque values associated with an authentication session to use to 720 construct the Authorization header in future requests within that 721 protection space. The Authorization header may be included 722 preemptively; doing so improves server efficiency and avoids extra 723 round trips for authentication challenges. The server may choose to 724 accept the old Authorization header information, even though the 725 nonce value included might not be fresh. Alternatively, the server 726 may return a 401 response with a new nonce value, causing the client 727 to retry the request; by specifying stale=TRUE with this response, 728 the server tells the client to retry with the new nonce, but without 729 prompting for a new username and password. 731 Because the client is required to return the value of the opaque 732 directive given to it by the server for the duration of a session, 733 the opaque data may be used to transport authentication session state 734 information. (Note that any such use can also be accomplished more 735 easily and safely by including the state in the nonce.) For example, 736 a server could be responsible for authenticating content that 737 actually sits on another server. It would achieve this by having the 738 first 401 response include a domain directive whose value includes a 739 URI on the second server, and an opaque directive whose value 740 contains the state information. The client will retry the request, at 741 which time the server might respond with a 301/302 redirection, 742 pointing to the URI on the second server. The client will follow the 743 redirection, and pass an Authorization header , including the 744 data. 746 As with the basic scheme, proxies must be completely transparent in 747 the Digest access authentication scheme. That is, they must forward 748 the WWW-Authenticate, Authentication-Info and Authorization headers 749 untouched. If a proxy wants to authenticate a client before a request 750 is forwarded to the server, it can be done using the Proxy- 751 Authenticate and Proxy-Authorization headers described in section 3.6 752 below. 754 3.7 Security Protocol Negotiation 756 It is useful for a server to be able to know which security schemes a 757 client is capable of handling. 759 It is possible that a server may want to require Digest as its 760 authentication method, even if the server does not know that the 761 client supports it. A client is encouraged to fail gracefully if the 762 server specifies only authentication schemes it cannot handle. 764 When a server receives a request to access a resource, the server 765 might challenge the client by responding with "401 Unauthorized" 766 status code, and include one or more WWW-Authenticate headers. If the 767 server challenges with multiple Digest headers, then each one of 768 these headers MUST use a different digest algorithm. The server MUST 769 add these Digest headers to the response in order of preference, 770 starting with the most preferred header, followed by the less 771 preferred headers. 773 This specification defines the following preference list, starting 774 with the most preferred algorithm: 776 * SHA2-256 as the default algorithm. 777 * SHA2-512/256 as a backup algorithm. 778 * MD5 for backward compatibility. 780 A future version of this document might add SHA3 [SHA3] as a backup 781 algorithm, once its definition has been finalized and published. 783 When the client receives the response it SHOULD use the topmost 784 header that it supports, unless a local policy dictates otherwise. 785 The client should ignore any challenge it does not understand. 787 3.8 Proxy-Authentication and Proxy-Authorization 789 The digest authentication scheme may also be used for authenticating 790 users to proxies, proxies to proxies, or proxies to origin servers by 791 use of the Proxy-Authenticate and Proxy-Authorization headers. These 792 headers are instances of the Proxy-Authenticate and Proxy- 793 Authorization headers specified in sections 10.33 and 10.34 of the 794 HTTP/1.1 specification [RFC2616] and their behavior is subject to 795 restrictions described there. The transactions for proxy 796 authentication are very similar to those already described. Upon 797 receiving a request which requires authentication, the proxy/server 798 must issue the "407 Proxy Authentication Required" response with a 799 "Proxy-Authenticate" header. The digest-challenge used in the Proxy- 800 Authenticate header is the same as that for the WWW- Authenticate 801 header as defined above in section 3.2.1. 803 The client/proxy must then re-issue the request with a Proxy- 804 Authorization header, with directives as specified for the 805 Authorization header in section 3.4 above. 807 On subsequent responses, the server sends Proxy-Authentication-Info 808 with directives the same as those for the Authentication-Info header 809 field. 811 Note that in principle a client could be asked to authenticate itself 812 to both a proxy and an end-server, but never in the same response. 814 3.9 Example 816 The following example is borrowed from RFC2617 and assumes that an 817 access protected document is being requested from the server via a 818 GET request. The URI of the document is 819 http://www.nowhere.org/dir/index.html". Both client and server know 820 that the username for this document is "Mufasa" and the password is 821 "Circle of Life" ( with one space between each of the three words). 823 The first time the client requests the document, no Authorization 824 header is sent, so the server responds with: 826 HTTP/1.1 401 Unauthorized 827 WWW-Authenticate: Digest 828 realm = "testrealm@host.com", 829 qop="auth, auth-int", 830 algorithm="SHA2-256", 831 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 832 opaque="5ccc069c403ebaf9f0171e9517f40e41" 833 WWW-Authenticate: Digest 834 realm="testrealm@host.com", 835 qop="auth, auth-int", 836 algorithm="MD5", 837 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 838 opaque="5ccc069c403ebaf9f0171e9517f40ef41" 840 The client may prompt the user for their username and password, after 841 which it will respond with a new request, including the following 842 Authorization header if the client chooses MD5 digest: 844 Authorization:Digest username="Mufasa", 845 realm="testrealm@host.com", 846 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 847 uri="/dir/index.html", 848 qop="auth", 849 algorithm="MD5", 850 nc=00000001, 851 cnonce="0a4f113b", 852 response="6629fae49393a05397450978507c4ef1", 853 opaque="5ccc069c403ebaf9f0171e9517f40e41" 855 If the client chooses to use the SHA2-256 algorithm for calculating 856 the response, the client responds with a new request including the 857 following Authorization header: 859 Authorization:Digest username="Mufasa", 860 realm="testrealm@host.com", 861 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 862 uri="/dir/index.html", 863 qop="auth", 864 algorithm="SHA2-256", 865 nc=00000001, 866 cnonce="0a4f113b", 867 response="5abdd07184ba512a22c53f41470e5eea7dcaa3a93 868 a59b630c13dfe0a5dc6e38b", 869 opaque="5ccc069c403ebaf9f0171e9517f40e41" 871 4 Internationalization 873 In challenges, servers SHOULD use the "charset" authentication 874 parameter (case-insensitive) to express the character encoding they 875 expect the user agent to use. 877 The only allowed value is "UTF-8", to be matched case-insensitively, 878 indicating that the server expects the UTF-8 character encoding to be 879 used ([RFC3629]). 881 If the user agent supports the encoding indicated by the server, it 882 MAY add the "charset" parameter, with the value it received from the 883 server, to the Proxy-Authenticate or WWW-Authenticate header fields 884 it sends back to the server. 886 If the user agent does not support the encoding indicated by the 887 server, it MAY add the "charset" parameter to the Proxy-Authenticate 888 or WWW-Authenticate header fields it sends back to the server, but 889 the value in the parameter should be preceded by an exclamation point 890 (!). 892 5 Security Considerations 894 5.1 Limitations 896 HTTP Digest authentication, when used with human-memorable passwords, 897 is vulnerable to dictionary attacks. Such attacks are much easier 898 than cryptographic attacks on any widely used algorithm, including 899 those that are no longer considered secure. In other words, algorithm 900 agility does not make this usage any more secure. 902 As a result, Digest authentication SHOULD be used only with passwords 903 that have a reasonable amount of entropy, e.g. 128-bit or more. Such 904 passwords typically cannot be memorized by humans but can be used for 905 automated web services. 907 It is recommended that Digest authentication be used over a secure 908 channel like HTTPS. 910 5.2 Authentication of Clients using Digest Authentication 912 Digest Authentication does not provide a strong authentication 913 mechanism, when compared to public key based mechanisms, for example. 915 However, it is significantly stronger than (e.g.) CRAM-MD5, which has 916 been proposed for use with LDAP [10], POP and IMAP (see RFC 2195 917 [9]). It is intended to replace the much weaker and even more 918 dangerous Basic mechanism. 920 Digest Authentication offers no confidentiality protection beyond 921 protecting the actual password. All of the rest of the request and 922 response are available to an eavesdropper. 924 Digest Authentication offers only limited integrity protection for 925 the messages in either direction. If qop=auth-int mechanism is used, 926 those parts of the message used in the calculation of the WWW- 927 Authenticate and Authorization header field response directive values 928 (see section 3.2 above) are protected. Most header fields and their 929 values could be modified as a part of a man-in-the-middle attack. 931 Many needs for secure HTTP transactions cannot be met by Digest 932 Authentication. For those needs TLS or SHTTP are more appropriate 933 protocols. In particular Digest authentication cannot be used for any 934 transaction requiring confidentiality protection. Nevertheless many 935 functions remain for which Digest authentication is both useful and 936 appropriate. Any service in present use that uses Basic should be 937 switched to Digest as soon as practical. 939 5.3 Limited Use Nonce Values 941 The Digest scheme uses a server-specified nonce to seed the 942 generation of the request-digest value (as specified in section 943 3.2.2.1 above). As shown in the example nonce in section 3.2.1, the 944 server is free to construct the nonce such that it may only be used 945 from a particular client, for a particular resource, for a limited 946 period of time or number of uses, or any other restrictions. Doing 947 so strengthens the protection provided against, for example, replay 948 attacks (see 4.5). However, it should be noted that the method 949 chosen for generating and checking the nonce also has performance and 950 resource implications. For example, a server may choose to allow 951 each nonce value to be used only once by maintaining a record of 952 whether or not each recently issued nonce has been returned and 953 sending a next-nonce directive in the Authentication-Info header 954 field of every response. This protects against even an immediate 955 replay attack, but has a high cost checking nonce values, and perhaps 956 more important will cause authentication failures for any pipelined 957 requests (presumably returning a stale nonce indication). Similarly, 958 incorporating a request-specific element such as the Etag value for a 959 resource limits the use of the nonce to that version of the resource 960 and also defeats pipelining. Thus it may be useful to do so for 961 methods with side effects but have unacceptable performance for those 962 that do not. 964 5.4 Replay Attacks 965 A replay attack against Digest authentication would usually be 966 pointless for a simple GET request since an eavesdropper would 967 already have seen the only document he could obtain with a replay. 968 This is because the URI of the requested document is digested in the 969 client request and the server will only deliver that document. By 970 contrast under Basic Authentication once the eavesdropper has the 971 user's password, any document protected by that password is open to 972 him. 974 Thus, for some purposes, it is necessary to protect against replay 975 attacks. A good Digest implementation can do this in various ways. 976 The server created "nonce" value is implementation dependent, but if 977 it contains a digest of the client IP, a time-stamp, the resource 978 ETag, and a private server key (as recommended above) then a replay 979 attack is not simple. An attacker must convince the server that the 980 request is coming from a false IP address and must cause the server 981 to deliver the document to an IP address different from the address 982 to which it believes it is sending the document. An attack can only 983 succeed in the period before the time-stamp expires. Digesting the 984 client IP and time-stamp in the nonce permits an implementation which 985 does not maintain state between transactions. 987 For applications where no possibility of replay attack can be 988 tolerated the server can use one-time nonce values which will not be 989 honored for a second use. This requires the overhead of the server 991 remembering which nonce values have been used until the nonce time- 992 stamp (and hence the digest built with it) has expired, but it 993 effectively protects against replay attacks. 995 An implementation must give special attention to the possibility of 996 replay attacks with POST and PUT requests. Unless the server employs 997 one-time or otherwise limited-use nonces and/or insists on the use of 998 the integrity protection of qop=auth-int, an attacker could replay 999 valid credentials from a successful request with counterfeit form 1000 data or other message body. Even with the use of integrity protection 1001 most metadata in header fields is not protected. Proper nonce 1002 generation and checking provides some protection against replay of 1003 previously used valid credentials, but see 4.8. 1005 5.5 Weakness Created by Multiple Authentication Schemes 1007 An HTTP/1.1 server may return multiple challenges with a 401 1008 (Authenticate) response, and each challenge may use a different auth- 1009 scheme. A user agent MUST choose to use the strongest auth- scheme it 1010 understands and request credentials from the user based upon that 1011 challenge. 1013 Note that many browsers will only recognize Basic and will require 1014 that it be the first auth-scheme presented. Servers should only 1015 include Basic if it is minimally acceptable. 1017 When the server offers choices of authentication schemes using the 1018 WWW-Authenticate header, the strength of the resulting authentication 1019 is only as good as that of the of the weakest of the authentication 1020 schemes. See section 4.8 below for discussion of particular attack 1021 scenarios that exploit multiple authentication schemes. 1023 5.6 Online dictionary attacks 1025 If the attacker can eavesdrop, then it can test any overheard 1026 nonce/response pairs against a list of common words. Such a list is 1027 usually much smaller than the total number of possible passwords. The 1028 cost of computing the response for each password on the list is paid 1029 once for each challenge. 1031 The server can mitigate this attack by not allowing users to select 1032 passwords that are in a dictionary. 1034 5.7 Man in the Middle 1036 Both Basic and Digest authentication are vulnerable to "man in the 1037 middle" (MITM) attacks, for example, from a hostile or compromised 1038 proxy. Clearly, this would present all the problems of eavesdropping. 1039 But it also offers some additional opportunities to the attacker. 1041 A possible man-in-the-middle attack would be to add a weak 1042 authentication scheme to the set of choices, hoping that the client 1043 will use one that exposes the user's credentials (e.g. password). For 1044 this reason, the client should always use the strongest scheme that 1045 it understands from the choices offered. 1047 An even better MITM attack would be to remove all offered choices, 1048 replacing them with a challenge that requests only Basic 1049 authentication, then uses the cleartext credentials from the Basic 1050 authentication to authenticate to the origin server using the 1051 stronger scheme it requested. A particularly insidious way to mount 1052 such a MITM attack would be to offer a "free" proxy caching service 1053 to gullible users. 1055 User agents should consider measures such as presenting a visual 1056 indication at the time of the credentials request of what 1057 authentication scheme is to be used, or remembering the strongest 1058 authentication scheme ever requested by a server and produce a 1059 warning message before using a weaker one. It might also be a good 1060 idea for the user agent to be configured to demand Digest 1061 authentication in general, or from specific sites. 1063 Or, a hostile proxy might spoof the client into making a request the 1064 attacker wanted rather than one the client wanted. Of course, this is 1065 still much harder than a comparable attack against Basic 1066 Authentication. 1068 5.8 Chosen plaintext attacks 1070 With Digest authentication, a MITM or a malicious server can 1071 arbitrarily choose the nonce that the client will use to compute the 1072 response. This is called a "chosen plaintext" attack. The ability to 1073 choose the nonce is known to make cryptanalysis much easier [8]. 1075 However, no way to analyze the MD5 one-way function used by Digest 1076 using chosen plaintext is currently known. 1078 The countermeasure against this attack is for clients to be 1079 configured to require the use of the optional "cnonce" directive; 1080 this allows the client to vary the input to the hash in a way not 1081 chosen by the attacker. 1083 5.9 Precomputed dictionary attacks 1085 With Digest authentication, if the attacker can execute a chosen 1086 plaintext attack, the attacker can precompute the response for many 1087 common words to a nonce of its choice, and store a dictionary of 1088 (response, password) pairs. Such precomputation can often be done in 1089 parallel on many machines. It can then use the chosen plaintext 1090 attack to acquire a response corresponding to that challenge, and 1091 just look up the password in the dictionary. Even if most passwords 1092 are not in the dictionary, some might be. Since the attacker gets to 1093 pick the challenge, the cost of computing the response for each 1094 password on the list can be amortized over finding many passwords. A 1095 dictionary with 100 million password/response pairs would take about 1096 3.2 gigabytes of disk storage. 1098 The countermeasure against this attack is to for clients to be 1099 configured to require the use of the optional "cnonce" directive. 1101 5.10 Batch brute force attacks 1103 With Digest authentication, a MITM can execute a chosen plaintext 1104 attack, and can gather responses from many users to the same nonce. 1105 It can then find all the passwords within any subset of password 1106 space that would generate one of the nonce/response pairs in a single 1107 pass over that space. It also reduces the time to find the first 1108 password by a factor equal to the number of nonce/response pairs 1109 gathered. This search of the password space can often be done in 1110 parallel on many machines, and even a single machine can search large 1111 subsets of the password space very quickly -- reports exist of 1112 searching all passwords with six or fewer letters in a few hours. 1114 The countermeasure against this attack is to for clients to be 1115 configured to require the use of the optional "cnonce" directive. 1117 5.11 Spoofing by Counterfeit Servers 1119 Basic Authentication is vulnerable to spoofing by counterfeit 1120 servers. If a user can be led to believe that she is connecting to a 1121 host containing information protected by a password she knows, when 1122 in fact she is connecting to a hostile server, then the hostile 1123 server can request a password, store it away for later use, and feign 1124 an error. This type of attack is more difficult with Digest 1125 Authentication -- but the client must know to demand that Digest 1126 authentication be used, perhaps using some of the techniques 1127 described above to counter "man-in-the-middle" attacks. Again, the 1128 user can be helped in detecting this attack by a visual indication of 1129 the authentication mechanism in use with appropriate guidance in 1130 interpreting the implications of each scheme. 1132 5.12 Storing passwords 1134 Digest authentication requires that the authenticating agent (usually 1135 the server) store some data derived from the user's name and password 1136 in a "password file" associated with a given realm. Normally this 1137 might contain pairs consisting of username and H(A1), where H(A1) is 1138 the digested value of the username, realm, and password as described 1139 above. 1141 The security implications of this are that if this password file is 1142 compromised, then an attacker gains immediate access to documents on 1143 the server using this realm. Unlike, say a standard UNIX password 1144 file, this information need not be decrypted in order to access 1145 documents in the server realm associated with this file. On the other 1146 hand, decryption, or more likely a brute force attack, would be 1147 necessary to obtain the user's password. This is the reason that the 1148 realm is part of the digested data stored in the password file. It 1149 means that if one Digest authentication password file is compromised, 1150 it does not automatically compromise others with the same username 1151 and password (though it does expose them to brute force attack). 1153 There are two important security consequences of this. First the 1154 password file must be protected as if it contained unencrypted 1155 passwords, because for the purpose of accessing documents in its 1156 realm, it effectively does. 1158 A second consequence of this is that the realm string should be 1159 unique among all realms which any single user is likely to use. In 1160 particular a realm string should include the name of the host doing 1161 the authentication. The inability of the client to authenticate the 1162 server is a weakness of Digest Authentication. 1164 5.13 Summary 1166 By modern cryptographic standards Digest Authentication is weak. But 1167 for a large range of purposes it is valuable as a replacement for 1168 Basic Authentication. It remedies some, but not all, weaknesses of 1169 Basic Authentication. Its strength may vary depending on the 1170 implementation. In particular the structure of the nonce (which is 1171 dependent on the server implementation) may affect the ease of 1172 mounting a replay attack. A range of server options is appropriate 1173 since, for example, some implementations may be willing to accept the 1174 server overhead of one-time nonces or digests to eliminate the 1175 possibility of replay. Others may satisfied with a nonce like the one 1176 recommended above restricted to a single IP address and a single ETag 1177 or with a limited lifetime. 1179 The bottom line is that *any* compliant implementation will be 1180 relatively weak by cryptographic standards, but *any* compliant 1181 implementation will be far superior to Basic Authentication. 1183 6 IANA Considerations 1185 1187 7 References 1189 7.1 Normative References 1191 7.2 Informative References 1193 Authors' Addresses 1195 Rifaat Shekh-Yusef 1196 Avaya 1197 250 Sydney Street 1198 Belleville, Ontario 1199 Canada 1201 Phone: +1-613-967-5267 1202 Email: rifaat.ietf@gmail.com 1204 David Ahrens 1205 Avaya 1206 California 1207 USA 1209 EMail: ahrensdc@gmail.com