idnits 2.17.1 draft-ietf-httpbis-p7-auth-21.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2616, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates 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 (Using the creation date from RFC2617, updated by this document, for RFC5378 checks: 1997-12-01) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2012) is 4219 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) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-21 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2616 (if approved) J. Reschke, Ed. 5 Updates: 2617 (if approved) greenbytes 6 Intended status: Standards Track October 4, 2012 7 Expires: April 7, 2013 9 Hypertext Transfer Protocol (HTTP/1.1): Authentication 10 draft-ietf-httpbis-p7-auth-21 12 Abstract 14 The Hypertext Transfer Protocol (HTTP) is an application-level 15 protocol for distributed, collaborative, hypermedia information 16 systems. This document defines the HTTP Authentication framework. 18 Editorial Note (To be removed by RFC Editor) 20 Discussion of this draft takes place on the HTTPBIS working group 21 mailing list (ietf-http-wg@w3.org), which is archived at 22 . 24 The current issues list is at 25 and related 26 documents (including fancy diffs) can be found at 27 . 29 The changes in this draft are summarized in Appendix D.2. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 7, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 78 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 79 2. Access Authentication Framework . . . . . . . . . . . . . . . 4 80 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4 81 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 82 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 83 2.3.1. Considerations for New Authentication Schemes . . . . 7 84 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 85 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 86 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 87 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 88 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 89 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 90 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 91 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12 94 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 95 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 6.1. Authentication Credentials and Idle Clients . . . . . . . 13 98 6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13 99 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 102 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 103 Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 104 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 105 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 106 Appendix D. Change Log (to be removed by RFC Editor before 107 publication) . . . . . . . . . . . . . . . . . . . . 16 108 D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16 109 D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17 110 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 112 1. Introduction 114 This document defines HTTP/1.1 access control and authentication. It 115 includes the relevant parts of RFC 2616 with only minor changes 116 ([RFC2616]), plus the general framework for HTTP authentication, as 117 previously defined in "HTTP Authentication: Basic and Digest Access 118 Authentication" ([RFC2617]). 120 HTTP provides several OPTIONAL challenge-response authentication 121 mechanisms which can be used by a server to challenge a client 122 request and by a client to provide authentication information. The 123 "basic" and "digest" authentication schemes continue to be specified 124 in RFC 2617. 126 1.1. Conformance and Error Handling 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 Conformance criteria and considerations regarding error handling are 133 defined in Section 2.5 of [Part1]. 135 1.2. Syntax Notation 137 This specification uses the Augmented Backus-Naur Form (ABNF) 138 notation of [RFC5234] with the list rule extension defined in Section 139 1.2 of [Part1]. Appendix B describes rules imported from other 140 documents. Appendix C shows the collected ABNF with the list rule 141 expanded. 143 2. Access Authentication Framework 145 2.1. Challenge and Response 147 HTTP provides a simple challenge-response authentication mechanism 148 that can be used by a server to challenge a client request and by a 149 client to provide authentication information. It uses an extensible, 150 case-insensitive token to identify the authentication scheme, 151 followed by additional information necessary for achieving 152 authentication via that scheme. The latter can either be a comma- 153 separated list of parameters or a single sequence of characters 154 capable of holding base64-encoded information. 156 Parameters are name-value pairs where the name is matched case- 157 insensitively, and each parameter name MUST only occur once per 158 challenge. 160 auth-scheme = token 162 auth-param = token BWS "=" BWS ( token / quoted-string ) 164 token68 = 1*( ALPHA / DIGIT / 165 "-" / "." / "_" / "~" / "+" / "/" ) *"=" 167 The "token68" syntax allows the 66 unreserved URI characters 168 ([RFC3986]), plus a few others, so that it can hold a base64, 169 base64url (URL and filename safe alphabet), base32, or base16 (hex) 170 encoding, with or without padding, but excluding whitespace 171 ([RFC4648]). 173 The 401 (Unauthorized) response message is used by an origin server 174 to challenge the authorization of a user agent. This response MUST 175 include a WWW-Authenticate header field containing at least one 176 challenge applicable to the requested resource. 178 The 407 (Proxy Authentication Required) response message is used by a 179 proxy to challenge the authorization of a client and MUST include a 180 Proxy-Authenticate header field containing at least one challenge 181 applicable to the proxy for the requested resource. 183 challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] 185 Note: User agents will need to take special care in parsing the 186 WWW-Authenticate and Proxy-Authenticate header field values 187 because they can contain more than one challenge, or if more than 188 one of each is provided, since the contents of a challenge can 189 itself contain a comma-separated list of authentication 190 parameters. 192 Note: Many clients fail to parse challenges containing unknown 193 schemes. A workaround for this problem is to list well-supported 194 schemes (such as "basic") first. 196 A user agent that wishes to authenticate itself with an origin server 197 -- usually, but not necessarily, after receiving a 401 (Unauthorized) 198 -- can do so by including an Authorization header field with the 199 request. 201 A client that wishes to authenticate itself with a proxy -- usually, 202 but not necessarily, after receiving a 407 (Proxy Authentication 203 Required) -- can do so by including a Proxy-Authorization header 204 field with the request. 206 Both the Authorization field value and the Proxy-Authorization field 207 value contain the client's credentials for the realm of the resource 208 being requested, based upon a challenge received from the server 209 (possibly at some point in the past). When creating their values, 210 the user agent ought to do so by selecting the challenge with what it 211 considers to be the most secure auth-scheme that it understands, 212 obtaining credentials from the user as appropriate. 214 credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] 216 Upon a request for a protected resource that omits credentials, 217 contains invalid credentials (e.g., a bad password) or partial 218 credentials (e.g., when the authentication scheme requires more than 219 one round trip), an origin server SHOULD return a 401 (Unauthorized) 220 response. Such responses MUST include a WWW-Authenticate header 221 field containing at least one (possibly new) challenge applicable to 222 the requested resource. 224 Likewise, upon a request that requires authentication by proxies that 225 omit credentials or contain invalid or partial credentials, a proxy 226 SHOULD return a 407 (Proxy Authentication Required) response. Such 227 responses MUST include a Proxy-Authenticate header field containing a 228 (possibly new) challenge applicable to the proxy. 230 A server receiving credentials that are valid, but not adequate to 231 gain access, ought to respond with the 403 (Forbidden) status code 232 (Section 7.5.3 of [Part2]). 234 The HTTP protocol does not restrict applications to this simple 235 challenge-response mechanism for access authentication. Additional 236 mechanisms MAY be used, such as encryption at the transport level or 237 via message encapsulation, and with additional header fields 238 specifying authentication information. However, such additional 239 mechanisms are not defined by this specification. 241 Proxies MUST forward the WWW-Authenticate and Authorization header 242 fields unmodified and follow the rules found in Section 4.1. 244 2.2. Protection Space (Realm) 246 The authentication parameter realm is reserved for use by 247 authentication schemes that wish to indicate the scope of protection. 249 A protection space is defined by the canonical root URI (the scheme 250 and authority components of the effective request URI; see Section 251 5.5 of [Part1]) of the server being accessed, in combination with the 252 realm value if present. These realms allow the protected resources 253 on a server to be partitioned into a set of protection spaces, each 254 with its own authentication scheme and/or authorization database. 255 The realm value is a string, generally assigned by the origin server, 256 which can have additional semantics specific to the authentication 257 scheme. Note that there can be multiple challenges with the same 258 auth-scheme but different realms. 260 The protection space determines the domain over which credentials can 261 be automatically applied. If a prior request has been authorized, 262 the same credentials MAY be reused for all other requests within that 263 protection space for a period of time determined by the 264 authentication scheme, parameters, and/or user preference. Unless 265 otherwise defined by the authentication scheme, a single protection 266 space cannot extend outside the scope of its server. 268 For historical reasons, senders MUST only use the quoted-string 269 syntax. Recipients might have to support both token and quoted- 270 string syntax for maximum interoperability with existing clients that 271 have been accepting both notations for a long time. 273 2.3. Authentication Scheme Registry 275 The HTTP Authentication Scheme Registry defines the name space for 276 the authentication schemes in challenges and credentials. 278 Registrations MUST include the following fields: 280 o Authentication Scheme Name 282 o Pointer to specification text 284 o Notes (optional) 286 Values to be added to this name space require IETF Review (see 287 [RFC5226], Section 4.1). 289 The registry itself is maintained at 290 . 292 2.3.1. Considerations for New Authentication Schemes 294 There are certain aspects of the HTTP Authentication Framework that 295 put constraints on how new authentication schemes can work: 297 o HTTP authentication is presumed to be stateless: all of the 298 information necessary to authenticate a request MUST be provided 299 in the request, rather than be dependent on the server remembering 300 prior requests. Authentication based on, or bound to, the 301 underlying connection is outside the scope of this specification 302 and inherently flawed unless steps are taken to ensure that the 303 connection cannot be used by any party other than the 304 authenticated user (see Section 2.3 of [Part1]). 306 o The authentication parameter "realm" is reserved for defining 307 Protection Spaces as defined in Section 2.2. New schemes MUST NOT 308 use it in a way incompatible with that definition. 310 o The "token68" notation was introduced for compatibility with 311 existing authentication schemes and can only be used once per 312 challenge/credentials. New schemes thus ought to use the "auth- 313 param" syntax instead, because otherwise future extensions will be 314 impossible. 316 o The parsing of challenges and credentials is defined by this 317 specification, and cannot be modified by new authentication 318 schemes. When the auth-param syntax is used, all parameters ought 319 to support both token and quoted-string syntax, and syntactical 320 constraints ought to be defined on the field value after parsing 321 (i.e., quoted-string processing). This is necessary so that 322 recipients can use a generic parser that applies to all 323 authentication schemes. 325 Note: The fact that the value syntax for the "realm" parameter is 326 restricted to quoted-string was a bad design choice not to be 327 repeated for new parameters. 329 o Definitions of new schemes ought to define the treatment of 330 unknown extension parameters. In general, a "must-ignore" rule is 331 preferable over "must-understand", because otherwise it will be 332 hard to introduce new parameters in the presence of legacy 333 recipients. Furthermore, it's good to describe the policy for 334 defining new parameters (such as "update the specification", or 335 "use this registry"). 337 o Authentication schemes need to document whether they are usable in 338 origin-server authentication (i.e., using WWW-Authenticate), 339 and/or proxy authentication (i.e., using Proxy-Authenticate). 341 o The credentials carried in an Authorization header field are 342 specific to the User Agent, and therefore have the same effect on 343 HTTP caches as the "private" Cache-Control response directive, 344 within the scope of the request they appear in. 346 Therefore, new authentication schemes which choose not to carry 347 credentials in the Authorization header field (e.g., using a newly 348 defined header field) will need to explicitly disallow caching, by 349 mandating the use of either Cache-Control request directives 350 (e.g., "no-store") or response directives (e.g., "private"). 352 3. Status Code Definitions 354 3.1. 401 Unauthorized 356 The request requires user authentication. The response MUST include 357 a WWW-Authenticate header field (Section 4.4) containing a challenge 358 applicable to the target resource. The client MAY repeat the request 359 with a suitable Authorization header field (Section 4.1). If the 360 request already included Authorization credentials, then the 401 361 response indicates that authorization has been refused for those 362 credentials. If the 401 response contains the same challenge as the 363 prior response, and the user agent has already attempted 364 authentication at least once, then the user SHOULD be presented the 365 representation that was given in the response, since that 366 representation might include relevant diagnostic information. 368 3.2. 407 Proxy Authentication Required 370 This code is similar to 401 (Unauthorized), but indicates that the 371 client ought to first authenticate itself with the proxy. The proxy 372 MUST return a Proxy-Authenticate header field (Section 4.2) 373 containing a challenge applicable to the proxy for the target 374 resource. The client MAY repeat the request with a suitable Proxy- 375 Authorization header field (Section 4.3). 377 4. Header Field Definitions 379 This section defines the syntax and semantics of HTTP/1.1 header 380 fields related to authentication. 382 4.1. Authorization 384 The "Authorization" header field allows a user agent to authenticate 385 itself with a server -- usually, but not necessarily, after receiving 386 a 401 (Unauthorized) response. Its value consists of credentials 387 containing information of the user agent for the realm of the 388 resource being requested. 390 Authorization = credentials 392 If a request is authenticated and a realm specified, the same 393 credentials SHOULD be valid for all other requests within this realm 394 (assuming that the authentication scheme itself does not require 395 otherwise, such as credentials that vary according to a challenge 396 value or using synchronized clocks). 398 When a shared cache (see Section 1.2 of [Part6]) receives a request 399 containing an Authorization field, it MUST NOT return the 400 corresponding response as a reply to any other request, unless one of 401 the following specific exceptions holds: 403 1. If the response includes the "s-maxage" cache-control directive, 404 the cache MAY use that response in replying to a subsequent 405 request. But (if the specified maximum age has passed) a proxy 406 cache MUST first revalidate it with the origin server, using the 407 header fields from the new request to allow the origin server to 408 authenticate the new request. (This is the defined behavior for 409 s-maxage.) If the response includes "s-maxage=0", the proxy MUST 410 always revalidate it before re-using it. 412 2. If the response includes the "must-revalidate" cache-control 413 directive, the cache MAY use that response in replying to a 414 subsequent request. But if the response is stale, all caches 415 MUST first revalidate it with the origin server, using the header 416 fields from the new request to allow the origin server to 417 authenticate the new request. 419 3. If the response includes the "public" cache-control directive, it 420 MAY be returned in reply to any subsequent request. 422 4.2. Proxy-Authenticate 424 The "Proxy-Authenticate" header field consists of at least one 425 challenge that indicates the authentication scheme(s) and parameters 426 applicable to the proxy for this effective request URI (Section 5.5 427 of [Part1]). It MUST be included as part of a 407 (Proxy 428 Authentication Required) response. 430 Proxy-Authenticate = 1#challenge 432 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 433 only to the current connection, and intermediaries SHOULD NOT forward 434 it to downstream clients. However, an intermediate proxy might need 435 to obtain its own credentials by requesting them from the downstream 436 client, which in some circumstances will appear as if the proxy is 437 forwarding the Proxy-Authenticate header field. 439 Note that the parsing considerations for WWW-Authenticate apply to 440 this header field as well; see Section 4.4 for details. 442 4.3. Proxy-Authorization 444 The "Proxy-Authorization" header field allows the client to identify 445 itself (or its user) to a proxy which requires authentication. Its 446 value consists of credentials containing the authentication 447 information of the user agent for the proxy and/or realm of the 448 resource being requested. 450 Proxy-Authorization = credentials 452 Unlike Authorization, the Proxy-Authorization header field applies 453 only to the next outbound proxy that demanded authentication using 454 the Proxy-Authenticate field. When multiple proxies are used in a 455 chain, the Proxy-Authorization header field is consumed by the first 456 outbound proxy that was expecting to receive credentials. A proxy 457 MAY relay the credentials from the client request to the next proxy 458 if that is the mechanism by which the proxies cooperatively 459 authenticate a given request. 461 4.4. WWW-Authenticate 463 The "WWW-Authenticate" header field consists of at least one 464 challenge that indicates the authentication scheme(s) and parameters 465 applicable to the effective request URI (Section 5.5 of [Part1]). 467 It MUST be included in 401 (Unauthorized) response messages and MAY 468 be included in other response messages to indicate that supplying 469 credentials (or different credentials) might affect the response. 471 WWW-Authenticate = 1#challenge 473 User agents are advised to take special care in parsing the WWW- 474 Authenticate field value as it might contain more than one challenge, 475 or if more than one WWW-Authenticate header field is provided, the 476 contents of a challenge itself can contain a comma-separated list of 477 authentication parameters. 479 For instance: 481 WWW-Authenticate: Newauth realm="apps", type=1, 482 title="Login to \"apps\"", Basic realm="simple" 484 This header field contains two challenges; one for the "Newauth" 485 scheme with a realm value of "apps", and two additional parameters 486 "type" and "title", and another one for the "Basic" scheme with a 487 realm value of "simple". 489 Note: The challenge grammar production uses the list syntax as 490 well. Therefore, a sequence of comma, whitespace, and comma can 491 be considered both as applying to the preceding challenge, or to 492 be an empty entry in the list of challenges. In practice, this 493 ambiguity does not affect the semantics of the header field value 494 and thus is harmless. 496 5. IANA Considerations 498 5.1. Authentication Scheme Registry 500 The registration procedure for HTTP Authentication Schemes is defined 501 by Section 2.3 of this document. 503 The HTTP Method Authentication Scheme shall be created at 504 . 506 5.2. Status Code Registration 508 The HTTP Status Code Registry located at 509 shall be updated 510 with the registrations below: 512 +-------+-------------------------------+-------------+ 513 | Value | Description | Reference | 514 +-------+-------------------------------+-------------+ 515 | 401 | Unauthorized | Section 3.1 | 516 | 407 | Proxy Authentication Required | Section 3.2 | 517 +-------+-------------------------------+-------------+ 519 5.3. Header Field Registration 521 The Message Header Field Registry located at shall be 523 updated with the permanent registrations below (see [RFC3864]): 525 +---------------------+----------+----------+-------------+ 526 | Header Field Name | Protocol | Status | Reference | 527 +---------------------+----------+----------+-------------+ 528 | Authorization | http | standard | Section 4.1 | 529 | Proxy-Authenticate | http | standard | Section 4.2 | 530 | Proxy-Authorization | http | standard | Section 4.3 | 531 | WWW-Authenticate | http | standard | Section 4.4 | 532 +---------------------+----------+----------+-------------+ 534 The change controller is: "IETF (iesg@ietf.org) - Internet 535 Engineering Task Force". 537 6. Security Considerations 539 This section is meant to inform application developers, information 540 providers, and users of the security limitations in HTTP/1.1 as 541 described by this document. The discussion does not include 542 definitive solutions to the problems revealed, though it does make 543 some suggestions for reducing security risks. 545 6.1. Authentication Credentials and Idle Clients 547 Existing HTTP clients and user agents typically retain authentication 548 information indefinitely. HTTP/1.1 does not provide a method for a 549 server to direct clients to discard these cached credentials. This 550 is a significant defect that requires further extensions to HTTP. 551 Circumstances under which credential caching can interfere with the 552 application's security model include but are not limited to: 554 o Clients which have been idle for an extended period following 555 which the server might wish to cause the client to reprompt the 556 user for credentials. 558 o Applications which include a session termination indication (such 559 as a "logout" or "commit" button on a page) after which the server 560 side of the application "knows" that there is no further reason 561 for the client to retain the credentials. 563 This is currently under separate study. There are a number of work- 564 arounds to parts of this problem, and we encourage the use of 565 password protection in screen savers, idle time-outs, and other 566 methods which mitigate the security problems inherent in this 567 problem. In particular, user agents which cache credentials are 568 encouraged to provide a readily accessible mechanism for discarding 569 cached credentials under user control. 571 6.2. Protection Spaces 573 Authentication schemes that solely rely on the "realm" mechanism for 574 establishing a protection space will expose credentials to all 575 resources on a server. Clients that have successfully made 576 authenticated requests with a resource can use the same 577 authentication credentials for other resources on the same server. 578 This makes it possible for a different resource to harvest 579 authentication credentials for other resources. 581 This is of particular concern when a server hosts resources for 582 multiple parties under the same canonical root URI (Section 2.2). 583 Possible mitigation strategies include restricting direct access to 584 authentication credentials (i.e., not making the content of the 585 Authorization request header field available), and separating 586 protection spaces by using a different host name for each party. 588 7. Acknowledgments 590 This specification takes over the definition of the HTTP 591 Authentication Framework, previously defined in RFC 2617. We thank 592 John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. 594 Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for 595 their work on that specification. See Section 6 of [RFC2617] for 596 further acknowledgements. 598 See Section 9 of [Part1] for the Acknowledgments related to this 599 document revision. 601 8. References 603 8.1. Normative References 605 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 606 Protocol (HTTP/1.1): Message Syntax and Routing", 607 draft-ietf-httpbis-p1-messaging-21 (work in progress), 608 October 2012. 610 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 611 Protocol (HTTP/1.1): Semantics and Content", 612 draft-ietf-httpbis-p2-semantics-21 (work in progress), 613 October 2012. 615 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 616 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 617 draft-ietf-httpbis-p6-cache-21 (work in progress), 618 October 2012. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 624 Specifications: ABNF", STD 68, RFC 5234, January 2008. 626 8.2. Informative References 628 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 629 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 630 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 632 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 633 Leach, P., Luotonen, A., and L. Stewart, "HTTP 634 Authentication: Basic and Digest Access Authentication", 635 RFC 2617, June 1999. 637 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 638 Procedures for Message Header Fields", BCP 90, RFC 3864, 639 September 2004. 641 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 642 Resource Identifier (URI): Generic Syntax", STD 66, 643 RFC 3986, January 2005. 645 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 646 Encodings", RFC 4648, October 2006. 648 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 649 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 650 May 2008. 652 Appendix A. Changes from RFCs 2616 and 2617 654 The "realm" parameter isn't required anymore in general; 655 consequently, the ABNF allows challenges without any auth parameters. 656 (Section 2) 658 The "token68" alternative to auth-param lists has been added for 659 consistency with legacy authentication schemes such as "Basic". 660 (Section 2) 662 Introduce Authentication Scheme Registry. (Section 2.3) 664 Appendix B. Imported ABNF 666 The following core rules are included by reference, as defined in 667 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 668 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 669 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 670 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 671 character). 673 The rules below are defined in [Part1]: 675 BWS = 676 OWS = 677 quoted-string = 678 token = 680 Appendix C. Collected ABNF 682 Authorization = credentials 684 BWS = 686 OWS = 688 Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS 689 challenge ] ) 690 Proxy-Authorization = credentials 692 WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge 693 ] ) 695 auth-param = token BWS "=" BWS ( token / quoted-string ) 696 auth-scheme = token 698 challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *( 699 OWS "," [ OWS auth-param ] ) ] ) ] 700 credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) 701 *( OWS "," [ OWS auth-param ] ) ] ) ] 703 quoted-string = 705 token = 706 token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) 707 *"=" 709 Appendix D. Change Log (to be removed by RFC Editor before publication) 711 Changes up to the first Working Group Last Call draft are summarized 712 in . 715 D.1. Since draft-ietf-httpbis-p7-auth-19 717 Closed issues: 719 o : "Realms and 720 scope" 722 o : "Strength" 724 o : 725 "Authentication exchanges" 727 o : "ABNF 728 requirements for recipients" 730 o : "note 731 introduction of new IANA registries as normative changes" 733 D.2. Since draft-ietf-httpbis-p7-auth-20 735 Closed issues: 737 o : "rename 738 b64token for clarity" 740 Other changes: 742 o Conformance criteria and considerations regarding error handling 743 are now defined in Part 1. 745 Index 747 4 748 401 Unauthorized (status code) 9 749 407 Proxy Authentication Required (status code) 9 751 A 752 Authorization header field 9 754 C 755 Canonical Root URI 6 757 G 758 Grammar 759 auth-param 5 760 auth-scheme 5 761 Authorization 9 762 challenge 5 763 credentials 6 764 Proxy-Authenticate 10 765 Proxy-Authorization 11 766 token68 5 767 WWW-Authenticate 11 769 P 770 Protection Space 6 771 Proxy-Authenticate header field 10 772 Proxy-Authorization header field 10 774 R 775 Realm 6 777 W 778 WWW-Authenticate header field 11 780 Authors' Addresses 782 Roy T. Fielding (editor) 783 Adobe Systems Incorporated 784 345 Park Ave 785 San Jose, CA 95110 786 USA 788 EMail: fielding@gbiv.com 789 URI: http://roy.gbiv.com/ 791 Julian F. Reschke (editor) 792 greenbytes GmbH 793 Hafenweg 16 794 Muenster, NW 48155 795 Germany 797 EMail: julian.reschke@greenbytes.de 798 URI: http://greenbytes.de/tech/webdav/