idnits 2.17.1 draft-ietf-http-authentication-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 7) being 73 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([5], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 138: '...user agent. This response MUST include...' RFC 2119 keyword, line 142: '... of a client and MUST include a Proxy-...' RFC 2119 keyword, line 181: '...agent MUST choose to use one of the ch...' RFC 2119 keyword, line 193: '...credentials MAY be reused for all othe...' RFC 2119 keyword, line 200: '...request, it SHOULD return a 401 (Unaut...' (27 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 679 has weird spacing: '...ptional clien...' == Line 724 has weird spacing: '...hanging nonce...' == Line 952 has weird spacing: '...ion. If qop=a...' == Line 955 has weird spacing: '... 0) are prote...' == Line 1048 has weird spacing: '... use of the i...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 7, 1998) is 9386 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'HASHLEN' on line 1241 -- Looks like a reference, but probably isn't: 'HASHHEXLEN' on line 1299 == Unused Reference: '3' is defined on line 1431, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2069 (ref. '6') (Obsoleted by RFC 2617) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group J. Franks, Northwestern University 3 INTERNET DRAFT P. Hallam-Baker, Verisign, Inc. 4 J. Hostetler, Spyglass, Inc. 5 S. Lawrence, Agranat, Inc. 6 P. Leach, Microsoft Corporation 7 A. Luotonen, Netscape Communications Corporation 8 L. Stewart, Open Market, Inc. 9 Expires: February 7, 1999 August 7, 1998 11 HTTP Authentication: Basic and Digest Access Authentication 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or made obsolete by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), or ftp.isi.edu (US West Coast). 30 Distribution of this document is unlimited. Please send comments to the 31 HTTP working group at . Discussions of the 32 working group are archived at 33 . 35 Copyright NoticeCopyright (C) The Internet Society (1998). All Rights 36 Reserved. See section 9 for the full copyright notice. 38 Abstract 40 "HTTP/1.0" includes the specification for a Basic Access Authentication 41 scheme. This scheme is not considered to be a secure method of user 42 authentication (unless used in conjunction with some external secure 43 system such as SSL [5]), as the user name and password are passed over 44 the network as cleartext. 46 This document also provides the specification for HTTP's authentication 47 framework, the original Basic authentication scheme and a scheme based 48 on cryptographic hashes, referred to as "Digest Access Authentication". 49 It is therefore also intended to serve as a replacement for RFC 2069 50 [6]. Some optional elements specified by RFC 2069 have been removed 51 from this specification due to problems found since its publication; 52 other new elements have been added -for compatibility, those new 53 elements have been made optional, but are strongly recommended. 55 Like Basic, Digest access authentication verifies that both parties to a 56 communication know a shared secret (a password); unlike Basic, this 57 verification can be done without sending the password in the clear, 58 which is Basic's biggest weakness. As with most other authentication 59 protocols, the greatest sources of risks are usually found not in the 60 core protocol itself but in policies and procedures surrounding its use. 62 Table of Contents 64 HTTP AUTHENTICATION: BASIC AND DIGEST ACCESS AUTHENTICATION1 66 Status of this Memo........................................1 68 Abstract...................................................1 70 Table of Contents..........................................3 72 1 Access Authentication.................................5 73 1.1 Reliance on the HTTP/1.1 Specification..............5 74 1.2 Access Authentication Framework.....................5 76 2 Basic Authentication Scheme...........................6 78 3 Digest Access Authentication Scheme...................7 79 3.1 Introduction........................................7 80 3.1.1 Purpose..........................................7 81 3.1.2 Overall Operation................................8 82 3.1.3 Representation of digest values..................8 83 3.1.4 Limitations......................................8 84 3.2 Specification of Digest Headers.....................8 85 3.2.1 The WWW-Authenticate Response Header.............8 86 3.2.2 The Authorization Request Header................11 87 3.2.3 The Authentication-Info Header..................15 88 3.3 Digest Operation...................................16 89 3.4 Security Protocol Negotiation......................16 90 3.5 Example............................................17 91 3.6 Proxy-Authentication and Proxy-Authorization.......17 93 4 Security Considerations..............................18 94 4.1 Authentication of Clients using Basic Authentication18 95 4.2 Authentication of Clients using Digest Authentication18 96 4.3 Limited Use Nonce Values...........................19 97 4.4 Comparison of Digest with Basic Authentication.....19 98 4.5 Replay Attacks.....................................20 99 4.6 Weakness Created by Multiple Authentication Schemes20 100 4.7 Online dictionary attacks..........................21 101 4.8 Man in the Middle..................................21 102 4.9 Chosen plaintext attacks...........................22 103 4.10 Precomputed dictionary attacks.....................22 104 4.11 Batch brute force attacks..........................22 105 4.12 Spoofing by Counterfeit Servers....................22 106 4.13 Storing passwords..................................23 107 4.14 Summary............................................23 109 5 Sample implementation................................23 111 6 Acknowledgments......................................27 113 7 References...........................................27 115 8 Authors' Addresses...................................28 116 1 Access Authentication 118 1.1 Reliance on the HTTP/1.1 Specification 120 This specification is a companion to the HTTP/1.1 specification [2]. It 121 uses the augmented BNF section 2.1 of that document, and relies on both 122 the non-terminals defined in that document and other aspects of the 123 HTTP/1.1 specification. 125 1.2 Access Authentication Framework 127 HTTP provides a simple challenge-response authentication mechanism that 128 MAY be used by a server to challenge a client request and by a client to 129 provide authentication information. It uses an extensible, case- 130 insensitive token to identify the authentication scheme, followed by a 131 comma-separated list of attribute-value pairs which carry the parameters 132 necessary for achieving authentication via that scheme. 134 auth-scheme = token 135 auth-param = token "=" ( token | quoted-string ) 137 The 401 (Unauthorized) response message is used by an origin server to 138 challenge the authorization of a user agent. This response MUST include 139 a WWW-Authenticate header field containing at least one challenge 140 applicable to the requested resource. The 407 (Proxy Authentication 141 Required) response message is used by a proxy to challenge the 142 authorization of a client and MUST include a Proxy-Authenticate header 143 field containing at least one challenge applicable to the proxy for the 144 requested resource. 146 challenge = auth-scheme 1*SP 1#auth-param 148 Note: User agents will need to take special care in parsing the WWW- 149 Authenticate or Proxy-Authenticate header field value if it contains 150 more than one challenge, or if more than one WWW-Authenticate header 151 field is provided, since the contents of a challenge may itself contain 152 a comma-separated list of authentication parameters. 154 The authentication parameter realm is defined for all authentication 155 schemes: 157 realm = "realm" "=" realm-value 158 realm-value = quoted-string 160 The realm directive (case-insensitive) is required for all 161 authentication schemes that issue a challenge. The realm value (case- 162 sensitive), in combination with the canonical root URL (the absoluteURI 163 for the server whose abs_path is empty; see section 5.1.2 of [2]) of the 164 server being accessed, defines the protection space. These realms allow 165 the protected resources on a server to be partitioned into a set of 166 protection spaces, each with its own authentication scheme and/or 167 authorization database. The realm value is a string, generally assigned 168 by the origin server, which may have additional semantics specific to 169 the authentication scheme. Note that there may be multiple challenges 170 with the same auth-scheme but different realms. 172 A user agent that wishes to authenticate itself with an origin server-- 173 usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY 174 do so by including an Authorization header field with the request. A 175 client that wishes to authenticate itself with a proxy--usually, but not 176 necessarily, after receiving a 407 (Proxy Authentication Required)--MAY 177 do so by including a Proxy-Authorization header field with the request. 178 Both the Authorization field value and the Proxy-Authorization field 179 value consist of credentials containing the authentication information 180 of the client for the realm of the resource being requested. The user 181 agent MUST choose to use one of the challenges with the strongest auth- 182 scheme it understands and request credentials from the user based upon 183 that challenge. 185 credentials = auth-scheme #auth-param 187 Note that many browsers will only recognize Basic and will require 188 that it be the first auth-scheme presented. Servers should only 189 include Basic if it is minimally acceptable. 191 The protection space determines the domain over which credentials can be 192 automatically applied. If a prior request has been authorized, the same 193 credentials MAY be reused for all other requests within that protection 194 space for a period of time determined by the authentication scheme, 195 parameters, and/or user preference. Unless otherwise defined by the 196 authentication scheme, a single protection space cannot extend outside 197 the scope of its server. 199 If the origin server does not wish to accept the credentials sent with a 200 request, it SHOULD return a 401 (Unauthorized) response. The response 201 MUST include a WWW-Authenticate header field containing at least one 202 (possibly new) challenge applicable to the requested resource. If a 203 proxy does not accept the credentials sent with a request, it SHOULD 204 return a 407 (Proxy Authentication Required). The response MUST include 205 a Proxy-Authenticate header field containing a (possibly new) challenge 206 applicable to the proxy for the requested resource. 208 The HTTP protocol does not restrict applications to this simple 209 challenge-response mechanism for access authentication. Additional 210 mechanisms MAY be used, such as encryption at the transport level or via 211 message encapsulation, and with additional header fields specifying 212 authentication information. However, these additional mechanisms are not 213 defined by this specification. 215 Proxies MUST be completely transparent regarding user agent 216 authentication by origin servers. That is, they must forward the WWW- 217 Authenticate and Authorization headers untouched, and follow the rules 218 found in section 14.8 of [2]. Both the Proxy-Authenticate and the Proxy- 219 Authorization header fields are hop-by-hop headers (see section 13.5.1 220 of [2]). 222 2 Basic Authentication Scheme 224 The "basic" authentication scheme is based on the model that the client 225 must authenticate itself with a user-ID and a password for each realm. 226 The realm value should be considered an opaque string which can only be 227 compared for equality with other realms on that server. The server will 228 service the request only if it can validate the user-ID and password for 229 the protection space of the Request-URI. There are no optional 230 authentication parameters. 232 For Basic, the framework above is utilized as follows: 234 challenge = "Basic" realm 235 credentials = "Basic" basic-credentials 237 Upon receipt of an unauthorized request for a URI within the protection 238 space, the origin server MAY respond with a challenge like the 239 following: 241 WWW-Authenticate: Basic realm="WallyWorld" 243 where "WallyWorld" is the string assigned by the server to identify the 244 protection space of the Request-URI. A proxy may respond with the same 245 challenge using the Proxy-Authenticate header field. 247 To receive authorization, the client sends the userid and password, 248 separated by a single colon (":") character, within a base64 249 [7 251 ] encoded 252 string in the credentials. 254 basic-credentials = base64-user-pass 255 base64-user-pass = 257 user-pass = userid ":" password 258 userid = * 259 password = *TEXT 261 Userids might be case sensitive. 263 If the user agent wishes to send the userid "Aladdin" and password "open 264 sesame", it would use the following header field: 266 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 268 A client SHOULD assume that all paths at or deeper than the depth of the 269 last symbolic element in the path field of the Request-URI also are 270 within the protection space specified by the Basic realm value of the 271 current challenge. A client MAY send the corresponding Authorization 272 header with requests for resources in that space without receipt of 273 another challenge from the server. 275 If a client wishes to send the same userid and password to a proxy, it 276 would use the Proxy-Authorization header field. See section 4 for 277 security considerations associated with Basic authentication. 279 3 Digest Access Authentication Scheme 281 3.1 Introduction 283 3.1.1 Purpose 285 The protocol referred to as "HTTP/1.0" includes the specification for a 286 Basic Access Authentication scheme[1]. This scheme is not considered to 287 be a secure method of user authentication, as the user name and password 288 are passed over the network in an unencrypted form. This document 289 provides the specification for such a scheme, which does not send the 290 password in cleartext. It is referred to as "Digest Access 291 Authentication". 293 The Digest Access Authentication scheme is not intended to be a complete 294 answer to the need for security in the World Wide Web. This scheme 295 provides no encryption of message content. The intent is simply to 296 create an access authentication method which avoids the most serious 297 flaws of Basic authentication. 299 3.1.2 Overall Operation 301 Like Basic Access Authentication, the Digest scheme is based on a simple 302 challenge-response paradigm. The Digest scheme challenges using a nonce 303 value. A valid response contains a checksum (by default the MD5 304 checksum) of the username, the password, the given nonce value, the HTTP 305 method, and the requested URI. In this way, the password is never sent 306 in the clear. Just as with the Basic scheme, the username and password 307 must be prearranged in some fashion not addressed by this document. 309 3.1.3 Representation of digest values 311 An optional header allows the server to specify the algorithm used to 312 create the checksum or digest. By default the MD5 algorithm is used and 313 that is the only algorithm described in this document. 315 For the purposes of this document, an MD5 digest of 128 bits is 316 represented as 32 ASCII printable characters. The bits in the 128 bit 317 digest are converted from most significant to least significant bit, 318 four bits at a time to their ASCII presentation as follows. Each four 319 bits is represented by its familiar hexadecimal notation from the 320 characters 0123456789abcdef. That is, binary 0000 gets represented by 321 the character '0', 0001, by '1', and so on up to the representation of 322 1111 as 'f'. 324 3.1.4 Limitations 326 The Digest authentication scheme described in this document suffers from 327 many known limitations. It is intended as a replacement for Basic 328 authentication and nothing more. It is a password-based system and (on 329 the server side) suffers from all the same problems of any password 330 system. In particular, no provision is made in this protocol for the 331 initial secure arrangement between user and server to establish the 332 user's password. 334 Users and implementors should be aware that this protocol is not as 335 secure as Kerberos, and not as secure as any client-side private-key 336 scheme. Nevertheless it is better than nothing, better than what is 337 commonly used with telnet and ftp, and better than Basic authentication. 339 3.2 Specification of Digest Headers 341 The Digest Access Authentication scheme is conceptually similar to the 342 Basic scheme. The formats of the modified WWW-Authenticate header line 343 and the Authorization header line are specified below. In addition, a 344 new header, Authentication-Info, is specified. 346 3.2.1 The WWW-Authenticate Response Header 348 If a server receives a request for an access-protected object, and an 349 acceptable Authorization header is not sent, the server responds with a 350 "401 Unauthorized" status code, and a WWW-Authenticate header as per the 351 framework defined above, which for the digest scheme is utilized as 352 follows: 354 challenge = "Digest" digest-challenge 356 digest-challenge = 1#( realm | [ domain ] | nonce | 357 [ opaque ] |[ stale ] | [ algorithm ] | 358 [ qop-options ] | [auth-param] ) 360 domain = "domain" "=" <"> URI ( 1*SP URI ) <"> 361 URI = absoluteURI | abs_path 362 nonce = "nonce" "=" nonce-value 363 nonce-value = quoted-string 364 opaque = "opaque" "=" quoted-string 365 stale = "stale" "=" ( "true" | "false" ) 366 algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | 367 token ) 368 qop-options = "qop" "=" <"> 1#qop-value <"> 369 qop-value = "auth" | "auth-int" | token 371 The meanings of the values of the parameters used above are as follows: 373 realm 374 A string to be displayed to users so they know which username and 375 password to use. This string should contain at least the name of the 376 host performing the authentication and might additionally indicate 377 the collection of users who might have access. An example might be 378 "registered_users@gotham.news.com". 380 domain 381 A space-separated list of URIs, as specified in RFC XURI [7], that 382 define the protection space. If a URI is an abs_path, it is relative 383 to canonical root URL (see section 1.2 above) of the server being 384 accessed. An absoluteURI in this list may refer to a different server 385 than the one being accessed. The client can use this list to 386 determine the set of URIs for which the same authentication 387 information may be sent: any URI that has a URI in this list as a 388 prefix (after both have been made absolute) may be assumed to be in 389 the same protection space. If this directive is omitted or its value 390 is empty, the client should assume that the protection space consists 391 of all URIs on the responding server. This directive is not 392 meaningful in Proxy-Authenticate headers, for which the protection 393 space is always the entire proxy; if present it should be ignored. 395 nonce 396 A server-specified data string which may be uniquely generated each 397 time a 401 response is made. It is recommended that this string be 398 base64 or hexadecimal data. Specifically, since the string is passed 399 in the header lines as a quoted string, the double-quote character is 400 not allowed. 402 The contents of the nonce are implementation dependent. The quality 403 of the implementation depends on a good choice. A nonce might, for 404 example, be constructed as the base 64 encoding of 406 time-stamp H(time-stamp ":" ETag ":" private-key) 408 where time-stamp is a server-generated time or other non-repeating 409 value, ETag is the value of the HTTP ETag header associated with the 410 requested entity, and private-key is data known only to the server. 411 With a nonce of this form a server would recalculate the hash portion 412 after receiving the client authentication header and reject the 413 request if it did not match the nonce from that header or if the 414 time-stamp value is not recent enough. In this way the server can 415 limit the time of the nonce's validity. The inclusion of the ETag 416 prevents a replay request for an updated version of the resource. 417 (Note: including the IP address of the client in the nonce would 418 appear to offer the server the ability to limit the reuse of the 419 nonce to the same client that originally got it. However, that would 420 break proxy farms, where requests from a single user often go through 421 different proxies in the farm. Also, IP address spoofing is not that 422 hard.) 424 An implementation might choose not to accept a previously used nonce 425 or a previously used digest to protect against a replay attack. Or, 426 an implementation might choose to use one-time nonces or digests for 427 POST or PUT requests and a time-stamp for GET requests. For more 428 details on the issues involved see section 4. of this document. 430 The nonce is opaque to the client. 432 opaque 433 A string of data, specified by the server, which should be returned 434 by the client unchanged. It is recommended that this string be base64 435 or hexadecimal data. 437 stale 438 A flag, indicating that the previous request from the client was 439 rejected because the nonce value was stale. If stale is TRUE (case- 440 insensitive), the client may wish to simply retry the request with a 441 new encrypted response, without reprompting the user for a new 442 username and password. The server should only set stale to true if it 443 receives a request for which the nonce is invalid but with a valid 444 digest for that nonce (indicating that the client knows the correct 445 username/password). 447 algorithm 448 A string indicating a pair of algorithms used to produce the digest 449 and a checksum. If this is not present it is assumed to be "MD5". If 450 the algorithm is not understood, the challenge should be ignored (and 451 a different one used, if there is more than one). In this document 452 the string obtained by applying the digest algorithm to the data 453 "data" with secret "secret" will be denoted by KD(secret, data), and 454 the string obtained by applying the checksum algorithm to the data 455 "data" will be denoted H(data). The notation unq(X) means the value 456 of the quoted-string X without the surrounding quotes. 458 For the "MD5" and "MD5-sess" algorithms 460 H(data) = MD5(data) 462 and 464 KD(secret, data) = H(concat(secret, ":", data)) 466 i.e., the digest is the MD5 of the secret concatenated with a 467 colon concatenated with the data. The "MD5-sess" algorithm is 468 intended to allow efficient 3rd party authentication servers; 469 for the difference in usage, see the description . 471 qop-options 472 This directive is optional, but is made so only for backward 473 compatibility with RFC 2069 [6]; it SHOULD be used by all 474 implementations compliant with this version of the Digest scheme. 475 If present, it is a quoted string of one or more tokens indicating 476 the "quality of protection" values supported by the server. The 477 value "auth" indicates authentication; the value "auth-int" indicates 478 authentication with integrity protection; see the descriptions below 479 for calculating the response directive value for the application of 480 this choice. Unrecognized options MUST be ignored. 482 auth-param 483 This directive allows for future extensions. Any unrecognized 484 directive MUST be ignored. 486 3.2.2 The Authorization Request Header 488 The client is expected to retry the request, passing an 489 Authorization header line, which is defined according to the 490 framework above, utilized as follows. 492 credentials = "Digest" digest-response 494 digest-response = 1#( username | realm | nonce | 495 digest-uri | response | [ algorithm ] | 496 [cnonce] | [opaque] | [message-qop] | 497 [nonce-count] | [auth-param] ) 499 username = "username" "=" username-value 500 username-value = quoted-string 501 digest-uri = "uri" "=" digest-uri-value 502 digest-uri-value = request-uri ; As specified by HTTP/1.1 503 message-qop = "qop" "=" qop-value 504 cnonce = "cnonce" "=" cnonce-value 505 cnonce-value = nonce-value 506 nonce-count = "nc" "=" nc-value 507 nc-value = 8LHEX 508 response = "response" "=" request-digest 509 request-digest = <"> 32LHEX <"> 510 LHEX = "0" | "1" | "2" | "3" | 511 "4" | "5" | "6" | "7" | 512 "8" | "9" | "a" | "b" | 513 "c" | "d" | "e" | "f" 515 The values of the opaque and algorithm fields must be those 516 supplied in the WWW-Authenticate response header for the entity 517 being requested. 519 response 520 A string of 32 hex digits computed as defined below, which proves 521 that the user knows a password 523 username 524 The user's name in the specified realm. 526 digest-uri 527 The URI from Request-URI of the Request-Line; duplicated here because 528 proxies are allowed to change the Request-Line in transit. 530 qop 531 Indicates what "quality of protection" the client has applied to the 532 message. If present, its value MUST be one of the alternatives the 533 server indicated it supports in the WWW-Authenticate header. These 534 values affect the computation of the request-digest. Note that this 535 is a single token, not a quoted list of alternatives as in WWW- 536 Authenticate. This directive is optional in order to preserve 537 backward compatibility with a minimal implementation of RFC 2069 [6], 538 but SHOULD be used if the server indicated that qop is supported by 539 providing a qop directive in the WWW-Authenticate header field. 541 cnonce 542 This MUST be specified if a qop directive is sent (see above), and 543 MUST NOT be specified if the server did not send a qop directive in 544 the WWW-Authenticate header field. The cnonce-value is an opaque 545 quoted string value provided by the client and used by both client 546 and server to avoid chosen plaintext attacks, to provide mutual 547 authentication, and to provide some message integrity protection. 548 See the descriptions below of the calculation of the response-digest 549 and request-digest values. 551 nonce-count 552 This MUST be specified if a qop directive is sent (see above), and 553 MUST NOT be specified if the server did not send a qop directive in 554 the WWW-Authenticate header field. The nc-value is the hexadecimal 555 count of the number of requests (including the current request) that 556 the client has sent with the nonce value in this request. For 557 example, in the first request sent in response to a given nonce 558 value, the client sends "nc=00000001". The purpose of this directive 559 is to allow the server to detect request replays by maintaining its 560 own copy of this count - if the same nc-value is seen twice, then the 561 request is a replay. See the description below of the construction 562 of the request-digest value. 564 auth-param 565 This directive allows for future extensions. Any unrecognized 566 directive MUST be ignored. 568 If a directive or its value is improper, or required directives 569 are missing, the proper response is 400 Bad Request. 571 The definition of request-digest above indicates the encoding for 572 its value. The following definitions show how the value is 573 computed. 575 3.2.2.1 Request-Digest 577 If the "qop" directive is not present (this construction is for 578 compatibility with RFC 2069): 580 request-digest = 581 <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > 582 <"> 584 See below for the definitions for A1 and A2. 586 If the "qop" value is "auth" or "auth-int": 588 request-digest = <"> < KD ( H(A1), unq(nonce-value) 589 ":" nc-value 590 ":" unq(cnonce-value) 591 ":" unq(qop-value) 592 ":" H(A2) 593 ) <"> 595 3.2.2.2 A1 597 If the "algorithm" directive's value is "MD5" or is unspecified, then A1 598 is: 600 A1 = unq(username-value) ":" unq(realm-value) ":" passwd 602 where 604 passwd = < user's password > 606 If the "algorithm" directive's value is "MD5-sess", then A1 is 607 calculated only once - on the first request by the client 608 following receipt of a WWW-Authenticate challenge from the 609 server. It uses the server nonce from that challenge, and the 610 first client nonce value to construct A1 as follows: 612 A1 = H( unq(username-value) ":" unq(realm-value) 613 ":" passwd ) 614 ":" unq(nonce-value) ":" unq(cnonce-value) 616 This creates a 'session key' for the authentication of subsequent 617 requests and responses which is different for each session, thus 618 limiting the amount of material hashed with any one key. Because the 619 server need only use the hash of the user credentials in order to create 620 the A1 value, this construction could be used as part of authentication 621 using a third party service so that the web server would not need the 622 actual password value. The specification of such a protocol is beyond 623 the scope of this specification. 625 3.2.2.3 A2 627 If the "qop" directive's value is "auth" or is unspecified, then A2 is: 629 A2 = Method ":" digest-uri-value 631 If the "qop" value is "auth-int", then A2 is: 633 A2 = Method ":" digest-uri-value ":" H(entity-body) 635 3.2.2.4 Directive values and quoted-string 637 Note that the value of many of the directives, such as "username- 638 value", are defined as a "quoted-string". However, the "unq" 639 notation indicates that surrounding quotation marks are removed 640 in forming the string A1. Thus if the Authorization header 641 includes the fields 643 username="Mufasa", realm=myhost@testrealm.com 645 and the user Mufasa has password "Circle Of Life" then H(A1) 646 would be H(Mufasa:myhost@testrealm.com:Circle Of Life) with no 647 quotation marks in the digested string. 649 No white space is allowed in any of the strings to which the 650 digest function H() is applied unless that white space exists in 651 the quoted strings or entity body whose contents make up the 652 string to be digested. For example, the string A1 illustrated 653 above must be 655 Mufasa:myhost@testrealm.com:Circle Of Life 657 with no white space on either side of the colons, but with the 658 white space between the words used in the password value. 659 Likewise, the other strings digested by H() must not have white 660 space on either side of the colons which delimit their fields 661 unless that white space was in the quoted strings or entity body 662 being digested. 664 Also note that if integrity protection is applied (qop=auth-int), the 665 H(entity-body) is the hash of the entity body, not the message body - it 666 is computed before any transfer encoding is applied by the sender and 667 after it has been removed by the recipient. Note that this includes 668 multipart boundaries and embedded headers in each part of any multipart 669 content-type. 671 3.2.2.5 Various considerations 673 The "Method" value is the HTTP request method as specified in 674 section 5.1.1 of [2]. The "request-uri" value is the Request-URI 675 from the request line as specified in section 5.1.2 of [2]. This 676 may be "*", an "absoluteURL" or an "abs_path" as specified in 677 section 5.1.2 of [2], but it MUST agree with the Request-URI. In 678 particular, it MUST be an "absoluteURL" if the Request-URI is an 679 "absoluteURL". The "cnonce-value" is an optional client-chosen 680 value whose purpose is to foil chosen plaintext attacks. 682 The authenticating server must assure that the document 683 designated by the "uri" parameter is the same as the document 684 served. The purpose of duplicating information from the request 685 URL in this field is to deal with the possibility that an 686 intermediate proxy may alter the client's request. This altered 687 (but presumably semantically equivalent) request would not result 688 in the same digest as that calculated by the client. 690 Implementers should be aware of how authenticated transactions 691 interact with shared caches. The HTTP/1.1 protocol specifies that 692 when a shared cache (see section 13.7 of [2]) has received a 693 request containing an Authorization header and a response from 694 relaying that request, it MUST NOT return that response as a 695 reply to any other request, unless one of two Cache-Control (see 696 section 14.9 of [2]) directives was present in the response. If 697 the original response included the "must-revalidate" Cache- 698 Control directive, the cache MAY use the entity of that response 699 in replying to a subsequent request, but MUST first revalidate it 700 with the origin server, using the request headers from the new 701 request to allow the origin server to authenticate the new 702 request. Alternatively, if the original response included the 703 "public" Cache-Control directive, the response entity MAY be 704 returned in reply to any subsequent request. 706 3.2.3 The Authentication-Info Header 708 The Authentication-Info header is used by the server to 709 communicate some information regarding the successful 710 authentication in the response. 712 AuthenticationInfo = "Authentication-Info" ":" auth-info 713 auth-info = 1#(nextnonce | [ message-qop ] 714 | [ response-auth ] | [ cnonce ] 715 | [nonce-count] ) 716 nextnonce = "nextnonce" "=" nonce-value 717 response-auth = "rspauth" "=" response-digest 718 response-digest = <"> *LHEX <"> 720 The value of the nextnonce parameter is the nonce the server 721 wishes the client to use for a future authentication response. 722 The server may send the Authentication-Info header with a 723 nextnonce field as a means of implementing one-time or otherwise 724 changing nonces. If the nextnonce field is present the client 725 SHOULD use it when constructing the Authorization header for its 726 next request. Failure of the client to do so may result in a 727 request to re-authenticate from the server with the "stale=TRUE". 729 Server implementations should carefully consider the 730 performance implications of the use of this mechanism; 731 pipelined requests will not be possible if every response 732 includes a nextnonce directive that must be used on the next 733 request received by the server. Consideration should be given 734 to the performance vs. security tradeoffs of allowing an old 735 nonce value to be used for a limited time to permit request 736 pipelining. Use of 738 message-qop 739 Indicates the "quality of protection" options applied to the 740 response by the server. The value "auth" indicates authentication; 741 the value "auth-int" indicates authentication with integrity 742 protection. The server SHOULD use the same value for the message-qop 743 directive in the response as was sent by the client in the 744 corresponding request. 746 The optional response digest in the "response-auth" directive 747 supports mutual authentication -- the server proves that it knows 748 the user's secret, and with qop=auth-int also provides limited 749 integrity protection of the response. The "response-digest" value 750 is calculated as for the "request-digest" in the Authorization 751 header, except that if "qop=auth" or is not specified in the 752 Authorization header for the request, A2 is 754 A2 = ":" digest-uri-value 756 and if "qop=auth-int", then A2 is 758 A2 = ":" digest-uri-value ":" H(entity-body) 760 where "digest-uri-value" is the value of the "uri" directive on the 761 Authorization header in the request. The "cnonce-value" and "nc-value" 762 MUST be the ones for the client request to which this message is the 763 response. The "response-auth", "cnonce", and "nonce-count" directives 764 MUST BE present if "qop=auth" or "qop=auth-int" is specified. 766 The Authentication-Info header is allowed in the trailer of an 767 HTTP message transferred via chunked transfer-coding. 769 3.3 Digest Operation 771 Upon receiving the Authorization header, the server may check its 772 validity by looking up its known password which corresponds to 773 the submitted username. Then, the server must perform the same 774 digest operation (e.g., MD5) performed by the client, and compare 775 the result to the given request-digest value. 777 Note that the HTTP server does not actually need to know the 778 user's cleartext password. As long as H(A1) is available to the 779 server, the validity of an Authorization header may be verified. 781 A client may remember the username, password and nonce values, so 782 that future requests within the specified may include 783 the Authorization header preemptively. The server may choose to 784 accept the old Authorization header information, even though the 785 nonce value included might not be fresh. Alternatively, the 786 server could return a 401 response with a new nonce value, 787 causing the client to retry the request. By specifying stale=TRUE 788 with this response, the server hints to the client that the 789 request should be retried with the new nonce, without reprompting 790 the user for a new username and password. 792 The opaque data is useful for transporting state information. For 793 example, a server could be responsible for authenticating content 794 which actually sits on another server. The first 401 response 795 would include a domain field which includes the URI on the second 796 server, and the opaque field for specifying state information. 797 The client will retry the request, at which time the server may 798 respond with a 301/302 redirection, pointing to the URI on the 799 second server. The client will follow the redirection, and pass 800 the same Authorization header, including the data which 801 the second server may require. 803 As with the basic scheme, proxies must be completely transparent 804 in the Digest access authentication scheme. That is, they must 805 forward the WWW-Authenticate, Authentication-Info and 806 Authorization headers untouched. If a proxy wants to authenticate 807 a client before a request is forwarded to the server, it can be 808 done using the Proxy-Authenticate and Proxy-Authorization headers 809 described in section 3.6 below. 811 3.4 Security Protocol Negotiation 813 It is useful for a server to be able to know which security 814 schemes a client is capable of handling. 816 It is possible that a server may want to require Digest as its 817 authentication method, even if the server does not know that the 818 client supports it. A client is encouraged to fail gracefully if 819 the server specifies only authentication schemes it cannot 820 handle. 822 3.5 Example 824 The following example assumes that an access-protected document 825 is being requested from the server via a GET request. The URI of 826 the document is "http://www.nowhere.org/dir/index.html". Both 827 client and server know that the username for this document is 828 "Mufasa", and the password is "Circle Of Life" (with one space 829 between each of the three words). 831 The first time the client requests the document, no Authorization 832 header is sent, so the server responds with: 834 HTTP/1.1 401 Unauthorized 835 WWW-Authenticate: Digest 836 realm="testrealm@host.com", 837 qop="auth,auth-int", 838 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 839 opaque="5ccc069c403ebaf9f0171e9517f40e41" 841 The client may prompt the user for the username and password, 842 after which it will respond with a new request, including the 843 following Authorization header: 845 Authorization: Digest username="Mufasa", 846 realm="testrealm@host.com", 847 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 848 uri="/dir/index.html", 849 qop=auth, 850 nc=00000001, 851 cnonce="0a4f113b", 852 response="6629fae49393a05397450978507c4ef1", 853 opaque="5ccc069c403ebaf9f0171e9517f40e41" 855 3.6 Proxy-Authentication and Proxy-Authorization 857 The digest authentication scheme may also be used for 858 authenticating users to proxies, proxies to proxies, or proxies 859 to origin servers by use of the Proxy-Authenticate and Proxy- 860 Authorization headers. These headers are instances of the Proxy- 861 Authenticate and Proxy-Authorization headers specified in 862 sections 10.33 and 10.34 of the HTTP/1.1 specification [2] and 863 their behavior is subject to restrictions described there. The 864 transactions for proxy authentication are very similar to those 865 already described. Upon receiving a request which requires 866 authentication, the proxy/server must issue the "407 Proxy 867 Authentication Required" response with a "Proxy-Authenticate" 868 header. The digest-challenge used in the Proxy-Authenticate 869 header is the same as that for the WWW-Authenticate header as 870 defined above in section 3.2.1. 872 The client/proxy must then re-issue the request with a Proxy- 873 Authorization header, with directives as specified for the Authorization 874 header in section 3.2.2 above. 876 On subsequent responses, the server sends Proxy-Authentication-Info with 877 directives the same as those for the Authentication-Info header field. 879 Note that in principle a client could be asked to authenticate 880 itself to both a proxy and an end-server, but never in the same 881 response. 883 4 Security Considerations 885 4.1 Authentication of Clients using Basic Authentication 887 The Basic authentication scheme is not a secure method of user 888 authentication, nor does it in any way protect the entity, which is 889 transmitted in cleartext across the physical network used as the 890 carrier. HTTP does not prevent additional authentication schemes and 891 encryption mechanisms from being employed to increase security or the 892 addition of enhancements (such as schemes to use one-time passwords) to 893 Basic authentication. 895 The most serious flaw in Basic authentication is that it results in the 896 essentially cleartext transmission of the user�s password over the 897 physical network. It is this problem which Digest Authentication 898 attempts to address. 900 Because Basic authentication involves the cleartext transmission of 901 passwords it SHOULD NOT be used (without enhancements) to protect 902 sensitive or valuable information. 904 A common use of Basic authentication is for identification purposes -- 905 requiring the user to provide a user name and password as a means of 906 identification, for example, for purposes of gathering accurate usage 907 statistics on a server. When used in this way it is tempting to think 908 that there is no danger in its use if illicit access to the protected 909 documents is not a major concern. This is only correct if the server 910 issues both user name and password to the users and in particular does 911 not allow the user to choose his or her own password. The danger arises 912 because naive users frequently reuse a single password to avoid the task 913 of maintaining multiple passwords. 915 If a server permits users to select their own passwords, then the threat 916 is not only illicit access to documents on the server but also illicit 917 access to the accounts of all users who have chosen to use their account 918 password. If users are allowed to choose their own password that also 919 means the server must maintain files containing the (presumably 920 encrypted) passwords. Many of these may be the account passwords of 921 users perhaps at distant sites. The owner or administrator of such a 922 system could conceivably incur liability if this information is not 923 maintained in a secure fashion. 925 Basic Authentication is also vulnerable to spoofing by counterfeit 926 servers. If a user can be led to believe that he is connecting to a host 927 containing information protected by Basic authentication when, in fact, 928 he is connecting to a hostile server or gateway, then the attacker can 929 request a password, store it for later use, and feign an error. This 930 type of attack is not possible with Digest Authentication. Server 931 implementers SHOULD guard against the possibility of this sort of 932 counterfeiting by gateways or CGI scripts. In particular it is very 933 dangerous for a server to simply turn over a connection to a gateway. 934 That gateway can then use the persistent connection mechanism to engage 935 in multiple transactions with the client while impersonating the 936 original server in a way that is not detectable by the client. 938 4.2 Authentication of Clients using Digest Authentication 940 Digest Authentication does not provide a strong authentication 941 mechanism, when compared to public key based mechanisms, for 942 example. However, it is significantly stronger than (e.g.) CRAM- 943 MD5 which has been proposed for use with LDAP [10], POP and IMAP 944 (see RFC 2195 [9]). It is intended to replace the much weaker 945 and even more dangerous Basic mechanism. 947 Digest Authentication offers no confidentiality protection beyond 948 protecting the actual password. All of the rest of the request 949 and response are available to an eavesdropper. 951 Digest Authentication offers only limited integrity protection 952 for the messages in either direction. If qop=auth-int mechanism 953 is used, those parts of the message used in the calculation of 954 the WWW-Authenticate and Authorization header field response 955 directive values (see section 0) are protected. Most header 956 fields and their values could be modified as a part of a man-in- 957 the-middle attack. 959 Many needs for secure HTTP transactions cannot be met by Digest 960 Authentication. For those needs TLS or SHTTP are more appropriate 961 protocols. In particular Digest authentication cannot be used for 962 any transaction requiring confidentiality protection. 963 Nevertheless many functions remain for which Digest 964 authentication is both useful and appropriate (any service in 965 present use that uses Basic should be switched to Digest as soon 966 as practical). 968 4.3 Limited Use Nonce Values 970 The Digest scheme uses a server-specified nonce to seed the generation 971 of the response-digest value (as specified in section 0). As shown in 972 the example in 0, the server is free to construct the nonce such that it 973 may only be used from a particular client, for a particular resource, 974 for a limited period of time or number of uses, or any other 975 restrictions. Doing so strengthens the protection provided against, for 976 example, replay attacks (see 4.5). However, it should be noted that the 977 method chosen for generating and checking the nonce also has performance 978 and resource implications. For example, a server may choose to allow 979 each nonce value to be used only once by maintaining a record of whether 980 or not each recently issued nonce has been returned and sending a next- 981 nonce directive in the Authentication-Info header field of every 982 response. This protects against even an immediate replay attack, but has 983 a high cost checking nonce values, and perhaps more important will cause 984 authentication failures for any pipelined requests (presumably returning 985 a stale nonce indication). Similarly, incorporating a request-specific 986 element such as the Etag value for a resource limits the use of the 987 nonce to that version of the resource and also defeats pipelining. Thus 988 it may be useful to do so for methods with side effects but have 989 unacceptable performance for those that do not. 991 4.4 Comparison of Digest with Basic Authentication 993 Both Digest and Basic Authentication are very much on the weak 994 end of the security strength spectrum. But a comparison between 995 the two points out the utility, even necessity, of replacing 996 Basic by Digest. 998 The greatest threat to the type of transactions for which these 999 protocols are used is network snooping. This kind of transaction 1000 might involve, for example, online access to a database whose use 1001 is restricted to paying subscribers. With Basic authentication an 1002 eavesdropper can obtain the password of the user. This not only 1003 permits him to access anything in the database, but, often worse, 1004 will permit access to anything else the user protects with the 1005 same password. 1007 By contrast, with Digest Authentication the eavesdropper only gets 1008 access to the transaction in question and not to the user's password. 1009 The information gained by the eavesdropper would permit a replay attack, 1010 but only with a request for the same document, and even that may be 1011 limited by the servers choice of nonce. 1013 4.5 Replay Attacks 1015 A replay attack against Digest authentication would usually be 1016 pointless for a simple GET request since an eavesdropper would 1017 already have seen the only document he could obtain with a 1018 replay. This is because the URI of the requested document is 1019 digested in the client request and the server will only deliver 1020 that document. By contrast under Basic Authentication once the 1021 eavesdropper has the user's password, any document protected by 1022 that password is open to him. 1024 Thus, for some purposes, it is necessary to protect against 1025 replay attacks. A good Digest implementation can do this in 1026 various ways. The server created "nonce" value is implementation 1027 dependent, but if it contains a digest of the client IP, a time- 1028 stamp, the resource ETag, and a private server key (as 1029 recommended above) then a replay attack is not simple. An 1030 attacker must convince the server that the request is coming from 1031 a false IP address and must cause the server to deliver the 1032 document to an IP address different from the address to which it 1033 believes it is sending the document. An attack can only succeed 1034 in the period before the time-stamp expires. Digesting the client 1035 IP and time-stamp in the nonce permits an implementation which 1036 does not maintain state between transactions. 1038 For applications where no possibility of replay attack can be 1039 tolerated the server can use one-time nonce values which will not 1040 be honored for a second use. This requires the overhead of the 1041 server remembering which nonce values have been used until the 1042 nonce time-stamp (and hence the digest built with it) has 1043 expired, but it effectively protects against replay attacks. 1045 An implementation must give special attention to the possibility 1046 of replay attacks with POST and PUT requests. Unless the server 1047 employs one-time or otherwise limited-use nonces and/or insists 1048 on the use of the integrity protection of qop=auth-int, an 1049 attacker could replay valid credentials from a successful request 1050 with counterfeit form data or other message body. Even with the 1051 use of integrity protection most metadata in header fields is 1052 not protected. Proper nonce generation and checking provides some 1053 protection against replay of previously used valid credentials, 1054 but see 4.8. 1056 4.6 Weakness Created by Multiple Authentication Schemes 1058 An HTTP/1.1 server may return multiple challenges with a 401 1059 (Authenticate) response, and each challenge may use a different auth- 1060 scheme. A user agent MUST choose to use the strongest auth-scheme it 1061 understands and request credentials from the user based upon that 1062 challenge. 1064 Note that many browsers will only recognize Basic and will require 1065 that it be the first auth-scheme presented. Servers should only 1066 include Basic if it is minimally acceptable. 1068 When the server offers choices of authentication schemes using the WWW- 1069 Authenticate header, the strength of the resulting authentication is 1070 only as good as that of the of the weakest of the authentication 1071 schemes. See section 4.8 below for discussion of particular attack 1072 scenarios that exploit multiple authentication schemes. 1074 4.7 Online dictionary attacks 1076 If the attacker can eavesdrop, then it can test any overheard 1077 nonce/response pairs against a list of common words. Such a list is 1078 usually much smaller than the total number of possible passwords. The 1079 cost of computing the response for each password on the list is paid 1080 once for each challenge. 1082 This attack can be mitigated by checking the password against a 1083 dictionary when a user tries to change it and disallowing passwords that 1084 are in the dictionary. 1086 4.8 Man in the Middle 1088 Both Basic and Digest authentication are vulnerable to "man in the 1089 middle" (MITM) attacks, for example, from a hostile or compromised 1090 proxy. Clearly, this would present all the problems of eavesdropping. 1091 But it also offers some additional opportunities to the attacker. 1093 A possible man-in-the-middle attack would be to add a weak 1094 authentication scheme to the set of choices, hoping that the client will 1095 use one that exposes the user's credentials (e.g. password). For this 1096 reason, the client should always use the strongest scheme that it 1097 understands from the choices offered. 1099 An even better MITM attack would be to remove all offered choices, 1100 replacing them with a challenge that requests only Basic authentication, 1101 then uses the cleartext credentials from the Basic authentication to 1102 authenticate to the origin server using the stronger scheme it 1103 requested. A particularly insidious way to mount such a MITM attack 1104 would be to offer a "free" proxy caching service to gullible users. 1106 User agents should consider measures such as presenting a visual 1107 indication at the time of the credentials request of what authentication 1108 scheme is to be used, or remembering the strongest authentication scheme 1109 ever requested by a server and produce a warning message before using a 1110 weaker one. It might also be a good idea for the user agent to be 1111 configured to demand Digest authentication in general, or from specific 1112 sites. 1114 Or, a hostile proxy might spoof the client into making a request the 1115 attacker wanted rather than one the client wanted. Of course, this is 1116 still much harder than a comparable attack against Basic Authentication. 1118 4.9 Chosen plaintext attacks 1120 With Digest authentication, a MITM or a malicious server can arbitrarily 1121 choose the nonce that the client will use to compute the response. This 1122 is called a "chosen plaintext" attack. The ability to choose the nonce 1123 is known to make cryptanalysis much easier [8]. 1125 However, no way to analyze the MD5 one-way function used by Digest using 1126 chosen plaintext is currently known. 1128 The countermeasure against this attack is to for clients to be 1129 configured to require the use of the optional "cnonce" directive; this 1130 allows the client to vary the input to the hash in a way not chosen by 1131 the attacker. 1133 4.10 Precomputed dictionary attacks 1135 With Digest authentication, if the attacker can execute a chosen 1136 plaintext attack, the attacker can precompute the response for many 1137 common words to a nonce of its choice, and store a dictionary of 1138 (response, password) pairs. Such precomputation can often be done in 1139 parallel on many machines. It can then use the chosen plaintext attack 1140 to acquire a response corresponding to that challenge, and just look up 1141 the password in the dictionary. Even if most passwords are not in the 1142 dictionary, some might be. Since the attacker gets to pick the 1143 challenge, the cost of computing the response for each password on the 1144 list can be amortized over finding many passwords. A dictionary with 100 1145 million password/response pairs would take about 3.2 gigabytes of disk 1146 storage. 1148 The countermeasure against this attack is to for clients to be 1149 configured to require the use of the optional "cnonce" directive. 1151 4.11 Batch brute force attacks 1153 With Digest authentication, a MITM can execute a chosen plaintext 1154 attack, and can gather responses from many users to the same nonce. It 1155 can then find all the passwords within any subset of password space that 1156 would generate one of the nonce/response pairs in a single pass over 1157 that space. It also reduces the time to find the first password by a 1158 factor equal to the number of nonce/response pairs gathered. This search 1159 of the password space can often be done in parallel on many machines, 1160 and even a single machine can search large subsets of the password space 1161 very quickly � reports exist of searching all passwords with six or 1162 fewer letters in a few hours. 1164 The countermeasure against this attack is to for clients to be 1165 configured to require the use of the optional "cnonce" directive. 1167 4.12 Spoofing by Counterfeit Servers 1169 Basic Authentication is vulnerable to spoofing by counterfeit servers. 1170 If a user can be led to believe that she is connecting to a host 1171 containing information protected by a password she knows, when in fact 1172 she is connecting to a hostile server, then the hostile server can 1173 request a password, store it away for later use, and feign an error. 1174 This type of attack is more difficult with Digest Authentication -- but 1175 the client must know to demand that Digest authentication be used, 1176 perhaps using some of the techniques described above to counter "man-in- 1177 the-middle" attacks. Again, the user can be helped in detecting this 1178 attack by a visual indication of the authentication mechanism in use 1179 with appropriate guidance in interpreting the implications of each 1180 scheme. 1182 4.13 Storing passwords 1184 Digest authentication requires that the authenticating agent (usually 1185 the server) store some data derived from the user's name and password in 1186 a "password file" associated with a given realm. Normally this might 1187 contain pairs consisting of username and H(A1), where H(A1) is the 1188 digested value of the username, realm, and password as described above. 1190 The security implications of this are that if this password file is 1191 compromised, then an attacker gains immediate access to documents on the 1192 server using this realm. Unlike, say a standard UNIX password file, this 1193 information need not be decrypted in order to access documents in the 1194 server realm associated with this file. On the other hand, decryption, 1195 or more likely a brute force attack, would be necessary to obtain the 1196 user's password. This is the reason that the realm is part of the 1197 digested data stored in the password file. It means that if one Digest 1198 authentication password file is compromised, it does not automatically 1199 compromise others with the same username and password (though it does 1200 expose them to brute force attack). 1202 There are two important security consequences of this. First the 1203 password file must be protected as if it contained unencrypted 1204 passwords, because for the purpose of accessing documents in its realm, 1205 it effectively does. 1207 A second consequence of this is that the realm string should be unique 1208 among all realms which any single user is likely to use. In particular a 1209 realm string should include the name of the host doing the 1210 authentication. The inability of the client to authenticate the server 1211 is a weakness of Digest Authentication. 1213 4.14 Summary 1215 By modern cryptographic standards Digest Authentication is weak. But for 1216 a large range of purposes it is valuable as a replacement for Basic 1217 Authentication. It remedies some, but not all, weaknesses of Basic 1218 Authentication. Its strength may vary depending on the implementation. 1219 In particular the structure of the nonce (which is dependent on the 1220 server implementation) may affect the ease of mounting a replay attack. 1221 A range of server options is appropriate since, for example, some 1222 implementations may be willing to accept the server overhead of one-time 1223 nonces or digests to eliminate the possibility of replay. Others may 1224 satisfied with a nonce like the one recommended above restricted to a 1225 single IP address and a single ETag or with a limited lifetime. 1227 The bottom line is that *any* compliant implementation will be 1228 relatively weak by cryptographic standards, but *any* compliant 1229 implementation will be far superior to Basic Authentication. 1231 5 Sample implementation 1233 The following code implements the calculations of H(A1), H(A2), request- 1234 digest and response-digest, and a test program which computes the values 1235 used in the example of section 3.5. It uses the MD5 implementation from 1236 RFC 1321. 1238 File "digcalc.h": 1240 #define HASHLEN 16 1241 typedef char HASH[HASHLEN]; 1242 #define HASHHEXLEN 32 1243 typedef char HASHHEX[HASHHEXLEN+1]; 1244 #define IN 1245 #define OUT 1247 /* calculate H(A1) as per HTTP Digest spec */ 1248 void DigestCalcHA1( 1249 IN char * pszAlg, 1250 IN char * pszUserName, 1251 IN char * pszRealm, 1252 IN char * pszPassword, 1253 IN char * pszNonce, 1254 IN char * pszCNonce, 1255 OUT HASHHEX SessionKey 1256 ); 1258 /* calculate request-digest/response-digest as per HTTP Digest spec */ 1259 void DigestCalcResponse( 1260 IN HASHHEX HA1, /* H(A1) */ 1261 IN char * pszNonce, /* nonce from server */ 1262 IN char * pszNonceCount, /* 8 hex digits */ 1263 IN char * pszCNonce, /* client nonce */ 1264 IN char * pszQop, /* qop-value: "", "auth", "auth-int" */ 1265 IN char * pszMethod, /* method from the request */ 1266 IN char * pszDigestUri, /* requested URL */ 1267 IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */ 1268 OUT HASHHEX Response /* request-digest or response-digest */ 1269 ); 1271 File "digcalc.c": 1273 #include 1274 #include 1275 #include 1276 #include "digcalc.h" 1278 void CvtHex( 1279 IN HASH Bin, 1280 OUT HASHHEX Hex 1281 ) 1282 { 1283 unsigned short i; 1284 unsigned char j; 1286 for (i = 0; i < HASHLEN; i++) { 1287 j = (Bin[i] >> 4) & 0xf; 1288 if (j <= 9) 1289 Hex[i*2] = (j + '0'); 1290 else 1291 Hex[i*2] = (j + 'a' - 10); 1293 j = Bin[i] & 0xf; 1294 if (j <= 9) 1295 Hex[i*2+1] = (j + '0'); 1296 else 1297 Hex[i*2+1] = (j + 'a' - 10); 1298 }; 1299 Hex[HASHHEXLEN] = '\0'; 1300 }; 1302 /* calculate H(A1) as per spec */ 1303 void DigestCalcHA1( 1304 IN char * pszAlg, 1305 IN char * pszUserName, 1306 IN char * pszRealm, 1307 IN char * pszPassword, 1308 IN char * pszNonce, 1309 IN char * pszCNonce, 1310 OUT HASHHEX SessionKey 1311 ) 1312 { 1313 MD5_CTX Md5Ctx; 1314 HASH HA1; 1316 MD5Init(&Md5Ctx); 1317 MD5Update(&Md5Ctx, pszUserName, strlen(pszUserName)); 1318 MD5Update(&Md5Ctx, ":", 1); 1319 MD5Update(&Md5Ctx, pszRealm, strlen(pszRealm)); 1320 MD5Update(&Md5Ctx, ":", 1); 1321 MD5Update(&Md5Ctx, pszPassword, strlen(pszPassword)); 1322 MD5Final(HA1, &Md5Ctx); 1323 if (stricmp(pszAlg, "md5-sess") == 0) { 1324 MD5Init(&Md5Ctx); 1325 MD5Update(&Md5Ctx, HA1, HASHLEN); 1326 MD5Update(&Md5Ctx, ":", 1); 1327 MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce)); 1328 MD5Update(&Md5Ctx, ":", 1); 1329 MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce)); 1330 MD5Final(HA1, &Md5Ctx); 1331 }; 1332 CvtHex(HA1, SessionKey); 1333 }; 1335 /* calculate request-digest/response-digest as per HTTP Digest spec */ 1336 void DigestCalcResponse( 1337 IN HASHHEX HA1, /* H(A1) */ 1338 IN char * pszNonce, /* nonce from server */ 1339 IN char * pszNonceCount, /* 8 hex digits */ 1340 IN char * pszCNonce, /* client nonce */ 1341 IN char * pszQop, /* qop-value: "", "auth", "auth-int" */ 1342 IN char * pszMethod, /* method from the request */ 1343 IN char * pszDigestUri, /* requested URL */ 1344 IN HASHHEX HEntity, /* H(entity body) if qop="auth-int" */ 1345 OUT HASHHEX Response /* request-digest or response-digest */ 1346 ) 1347 { 1348 MD5_CTX Md5Ctx; 1349 HASH HA2; 1350 HASH RespHash; 1351 HASHHEX HA2Hex; 1353 // calculate H(A2) 1354 MD5Init(&Md5Ctx); 1355 MD5Update(&Md5Ctx, pszMethod, strlen(pszMethod)); 1356 MD5Update(&Md5Ctx, ":", 1); 1357 MD5Update(&Md5Ctx, pszDigestUri, strlen(pszDigestUri)); 1358 if (stricmp(pszQop, "auth-int") == 0) { 1359 MD5Update(&Md5Ctx, ":", 1); 1360 MD5Update(&Md5Ctx, HEntity, HASHHEXLEN); 1361 }; 1362 MD5Final(HA2, &Md5Ctx); 1363 CvtHex(HA2, HA2Hex); 1365 // calculate response 1366 MD5Init(&Md5Ctx); 1367 MD5Update(&Md5Ctx, HA1, HASHHEXLEN); 1368 MD5Update(&Md5Ctx, ":", 1); 1369 MD5Update(&Md5Ctx, pszNonce, strlen(pszNonce)); 1370 MD5Update(&Md5Ctx, ":", 1); 1371 if (*pszQop) { 1372 MD5Update(&Md5Ctx, pszNonceCount, strlen(pszNonceCount)); 1373 MD5Update(&Md5Ctx, ":", 1); 1374 MD5Update(&Md5Ctx, pszCNonce, strlen(pszCNonce)); 1375 MD5Update(&Md5Ctx, ":", 1); 1376 MD5Update(&Md5Ctx, pszQop, strlen(pszQop)); 1377 MD5Update(&Md5Ctx, ":", 1); 1378 }; 1379 MD5Update(&Md5Ctx, HA2Hex, HASHHEXLEN); 1380 MD5Final(RespHash, &Md5Ctx); 1381 CvtHex(RespHash, Response); 1382 }; 1384 File "digtest.c": 1386 #include 1387 #include "digcalc.h" 1389 void main(int argc, char ** argv) { 1391 char * pszNonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093"; 1392 char * pszCNonce = "0a4f113b"; 1393 char * pszUser = "Mufasa"; 1394 char * pszRealm = "testrealm@host.com"; 1395 char * pszPass = "Circle Of Life"; 1396 char * pszAlg = "md5"; 1397 char szNonceCount[9] = "00000001"; 1398 char * pszMethod = "GET"; 1399 char * pszQop = "auth"; 1400 char * pszURI = "/dir/index.html"; 1401 HASHHEX HA1; 1402 HASHHEX HA2 = ""; 1403 HASHHEX Response; 1404 DigestCalcHA1(pszAlg, pszUser, pszRealm, pszPass, pszNonce, 1405 pszCNonce, HA1); 1406 DigestCalcResponse(HA1, pszNonce, szNonceCount, pszCNonce, pszQop, 1407 pszMethod, pszURI, HA2, Response); 1408 printf("Response = %s\n", Response); 1409 }; 1411 6 Acknowledgments 1413 Eric W. Sink, of AbiSource, Inc., was one of the original authors before 1414 the specification underwent substantial revision. 1416 In addition to the authors, valuable discussion instrumental in creating 1417 this document has come from Peter J. Churchyard, Ned Freed, and David M. 1418 Kristol. 1420 Jim Gettys and Larry Masinter edited this document for update. 1422 7 References 1424 [1] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer 1425 Protocol -- HTTP/1.0", RFC 1945, May 1996. 1427 [2] Fielding, R., Gettys, J., Mogul, J. C., Frysyk, H., Masinter, L., 1428 Leach, P., Berners-Lee, T., " Hypertext Transfer Protocol -- 1429 HTTP/1.1", Work In Progress of the HTTP working group, July, 1998. 1431 [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1432 1992. 1434 [4] Freed, N., and N. Borenstein. "Multipurpose Internet Mail 1435 Extensions (MIME) Part One: Format of Internet Message Bodies." RFC 1436 2045, Innosoft, First Virtual, November 1996. 1438 [5] Dierks, T. and C. Allen "The TLS Protocol, Version 1.0," Work In 1439 Progress of the TLS working group, November, 1997. 1441 [6] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, 1442 A., Sink, E., Stewart, L.,"An Extension to HTTP : Digest Access 1443 Authentication." RFC 2069, January, 1997. 1445 [7] Berners Lee, T, Fielding, R., Masinter, L., "Uniform Resource 1446 Identifiers (URI): Generic Syntax and Semantics," Work in Progress, 1447 November, 1997. 1449 [8] Kaliski, B.,Robshaw, M., "Message Authentication with MD5", 1450 CryptoBytes, Sping 1995, RSA Inc, 1451 (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm) 1453 [9] Klensin, J.,Catoe, R., Krumviede, P., "IMAP/POP AUTHorize Extension 1454 for Simple Challenge/Response", September 1997. 1456 [10] Morgan, B., Alvestrand, H., Hodges, J., Wahl, M., "Authentication 1457 Methods for LDAP", 07/07/1998. Work in progress, 1459 8 Authors' Addresses 1461 John Franks 1462 Professor of Mathematics 1463 Department of Mathematics 1464 Northwestern University 1465 Evanston, IL 60208-2730, USA 1467 EMail: john@math.nwu.edu 1469 Phillip M. Hallam-Baker 1470 Principal Consultant 1471 Verisign Inc. 1472 301 Edgewater Place 1473 Suite 210 1474 Wakefield MA 01880, USA 1476 EMail: pbaker@verisign.com 1478 Jeffery L. Hostetler 1479 Software Craftsman 1480 AbiSource, Inc. 1481 6 Dunlap Court 1482 Savoy, IL 61874 1484 EMail: jeff@AbiSource.com 1486 Scott D. Lawrence 1487 Agranat Systems, Inc. 1488 1345 Main St. 1489 Waltham, MA 02154, USA 1491 EMail: lawrence@agranat.com 1493 Paul J. Leach 1494 Microsoft Corporation 1495 1 Microsoft Way 1496 Redmond, WA 98052, USA 1498 EMail: paulle@microsoft.com 1500 Ari Luotonen 1501 Member of Technical Staff 1502 Netscape Communications Corporation 1503 501 East Middlefield Road 1504 Mountain View, CA 94043, USA 1506 EMail: luotonen@netscape.com 1508 Lawrence C. Stewart 1509 Open Market, Inc. 1510 215 First Street 1511 Cambridge, MA 02142, USA 1513 EMail: stewart@OpenMarket.com 1515 9 Full Copyright Statement 1517 Copyright (C) The Internet Society (1998). All Rights Reserved. 1519 This document and translations of it may be copied and furnished to 1520 others, and derivative works that comment on or otherwise explain it or 1521 assist in its implmentation may be prepared, copied, published and 1522 distributed, in whole or in part, without restriction of any kind, 1523 provided that the above copyright notice and this paragraph are included 1524 on all such copies and derivative works. However, this document itself 1525 may not be modified in any way, such as by removing the copyright notice 1526 or references to the Internet Society or other Internet organizations, 1527 except as needed for the purpose of developing Internet standards in 1528 which case the procedures for copyrights defined in the Internet 1529 Standards process must be followed, or as required to translate it into 1530 languages other than English. 1532 The limited permissions granted above are perpetual and will not be 1533 revoked by the Internet Society or its successors or assigns. 1535 This document and the information contained herein is provided on an "AS 1536 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1537 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1538 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1539 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1540 FITNESS FOR A PARTICULAR PURPOSE.