idnits 2.17.1 draft-ietf-httpbis-p7-auth-25.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 (November 17, 2013) is 3807 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-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-25 -- 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 November 17, 2013 7 Expires: May 21, 2014 9 Hypertext Transfer Protocol (HTTP/1.1): Authentication 10 draft-ietf-httpbis-p7-auth-25 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.1. 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 May 21, 2014. 48 Copyright Notice 49 Copyright (c) 2013 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 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 83 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7 84 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7 85 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 86 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 7 87 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 8 88 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 8 89 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 91 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10 92 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10 93 5.1.2. Considerations for New Authentication Schemes . . . . 10 94 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11 95 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 6.1. Authentication Credentials and Idle Clients . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 15 106 Appendix D. Change Log (to be removed by RFC Editor before 107 publication) . . . . . . . . . . . . . . . . . . . . 16 108 D.1. Since draft-ietf-httpbis-p7-auth-24 . . . . . . . . . . . 16 109 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 111 1. Introduction 113 This document defines HTTP/1.1 access control and authentication. It 114 includes the relevant parts of RFC 2616 with only minor changes 115 ([RFC2616]), plus the general framework for HTTP authentication, as 116 previously defined in "HTTP Authentication: Basic and Digest Access 117 Authentication" ([RFC2617]). 119 HTTP provides several OPTIONAL challenge-response authentication 120 schemes that can be used by a server to challenge a client request 121 and by a client to provide authentication information. The "basic" 122 and "digest" authentication schemes continue to be specified in RFC 123 2617. 125 1.1. Conformance and Error Handling 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 Conformance criteria and considerations regarding error handling are 132 defined in Section 2.5 of [Part1]. 134 1.2. Syntax Notation 136 This specification uses the Augmented Backus-Naur Form (ABNF) 137 notation of [RFC5234] with the list rule extension defined in Section 138 7 of [Part1]. Appendix B describes rules imported from other 139 documents. Appendix C shows the collected ABNF with the list rule 140 expanded. 142 2. Access Authentication Framework 144 2.1. Challenge and Response 146 HTTP provides a simple challenge-response authentication framework 147 that can be used by a server to challenge a client request and by a 148 client to provide authentication information. It uses a case- 149 insensitive token as a means to identify the authentication scheme, 150 followed by additional information necessary for achieving 151 authentication via that scheme. The latter can either be a comma- 152 separated list of parameters or a single sequence of characters 153 capable of holding base64-encoded information. 155 Parameters are name-value pairs where the name is matched case- 156 insensitively, and each parameter name MUST only occur once per 157 challenge. 159 auth-scheme = token 161 auth-param = token BWS "=" BWS ( token / quoted-string ) 163 token68 = 1*( ALPHA / DIGIT / 164 "-" / "." / "_" / "~" / "+" / "/" ) *"=" 166 The "token68" syntax allows the 66 unreserved URI characters 167 ([RFC3986]), plus a few others, so that it can hold a base64, 168 base64url (URL and filename safe alphabet), base32, or base16 (hex) 169 encoding, with or without padding, but excluding whitespace 170 ([RFC4648]). 172 The 401 (Unauthorized) response message is used by an origin server 173 to challenge the authorization of a user agent. This response MUST 174 include a WWW-Authenticate header field containing at least one 175 challenge applicable to the requested resource. 177 The 407 (Proxy Authentication Required) response message is used by a 178 proxy to challenge the authorization of a client and MUST include a 179 Proxy-Authenticate header field containing at least one challenge 180 applicable to the proxy for the requested resource. 182 challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] 184 Note: Many clients fail to parse challenges containing unknown 185 schemes. A workaround for this problem is to list well-supported 186 schemes (such as "basic") first. 188 A user agent that wishes to authenticate itself with an origin server 189 -- usually, but not necessarily, after receiving a 401 (Unauthorized) 190 -- can do so by including an Authorization header field with the 191 request. 193 A client that wishes to authenticate itself with a proxy -- usually, 194 but not necessarily, after receiving a 407 (Proxy Authentication 195 Required) -- can do so by including a Proxy-Authorization header 196 field with the request. 198 Both the Authorization field value and the Proxy-Authorization field 199 value contain the client's credentials for the realm of the resource 200 being requested, based upon a challenge received in a response 201 (possibly at some point in the past). When creating their values, 202 the user agent ought to do so by selecting the challenge with what it 203 considers to be the most secure auth-scheme that it understands, 204 obtaining credentials from the user as appropriate. 206 credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] 208 Upon receipt of a request for a protected resource that omits 209 credentials, contains invalid credentials (e.g., a bad password) or 210 partial credentials (e.g., when the authentication scheme requires 211 more than one round trip), an origin server SHOULD send a 401 212 (Unauthorized) response that contains a WWW-Authenticate header field 213 with at least one (possibly new) challenge applicable to the 214 requested resource. 216 Likewise, upon receipt of a request that requires authentication by 217 proxies that omit credentials or contain invalid or partial 218 credentials, a proxy SHOULD send a 407 (Proxy Authentication 219 Required) response that contains a Proxy-Authenticate header field 220 with a (possibly new) challenge applicable to the proxy. 222 A server receiving credentials that are valid, but not adequate to 223 gain access, ought to respond with the 403 (Forbidden) status code 224 (Section 6.5.3 of [Part2]). 226 HTTP does not restrict applications to this simple challenge-response 227 framework for access authentication. Additional mechanisms can be 228 used, such as authentication at the transport level or via message 229 encapsulation, and with additional header fields specifying 230 authentication information. However, such additional mechanisms are 231 not defined by this specification. 233 A proxy MUST forward the WWW-Authenticate and Authorization header 234 fields unmodified and follow the rules found in Section 4.1. 236 2.2. Protection Space (Realm) 238 The authentication parameter realm is reserved for use by 239 authentication schemes that wish to indicate the scope of protection. 241 A protection space is defined by the canonical root URI (the scheme 242 and authority components of the effective request URI; see Section 243 5.5 of [Part1]) of the server being accessed, in combination with the 244 realm value if present. These realms allow the protected resources 245 on a server to be partitioned into a set of protection spaces, each 246 with its own authentication scheme and/or authorization database. 247 The realm value is a string, generally assigned by the origin server, 248 which can have additional semantics specific to the authentication 249 scheme. Note that a response can have multiple challenges with the 250 same auth-scheme but different realms. 252 The protection space determines the domain over which credentials can 253 be automatically applied. If a prior request has been authorized, 254 the user agent MAY reuse the same credentials for all other requests 255 within that protection space for a period of time determined by the 256 authentication scheme, parameters, and/or user preferences (such as a 257 configurable inactivity timeout). Unless specifically allowed by the 258 authentication scheme, a single protection space cannot extend 259 outside the scope of its server. 261 For historical reasons, a sender MUST only generate the quoted-string 262 syntax. Recipients might have to support both token and quoted- 263 string syntax for maximum interoperability with existing clients that 264 have been accepting both notations for a long time. 266 3. Status Code Definitions 268 3.1. 401 Unauthorized 270 The 401 (Unauthorized) status code indicates that the request has not 271 been applied because it lacks valid authentication credentials for 272 the target resource. The origin server MUST send a WWW-Authenticate 273 header field (Section 4.4) containing at least one challenge 274 applicable to the target resource. If the request included 275 authentication credentials, then the 401 response indicates that 276 authorization has been refused for those credentials. The user agent 277 MAY repeat the request with a new or replaced Authorization header 278 field (Section 4.1). If the 401 response contains the same challenge 279 as the prior response, and the user agent has already attempted 280 authentication at least once, then the user agent SHOULD present the 281 enclosed representation to the user, since it usually contains 282 relevant diagnostic information. 284 3.2. 407 Proxy Authentication Required 286 The 407 (Proxy Authentication Required) status code is similar to 401 287 (Unauthorized), but indicates that the client needs to authenticate 288 itself in order to use a proxy. The proxy MUST send a Proxy- 289 Authenticate header field (Section 4.2) containing a challenge 290 applicable to that proxy for the target resource. The client MAY 291 repeat the request with a new or replaced Proxy-Authorization header 292 field (Section 4.3). 294 4. Header Field Definitions 296 This section defines the syntax and semantics of HTTP/1.1 header 297 fields related to authentication. 299 4.1. Authorization 301 The "Authorization" header field allows a user agent to authenticate 302 itself with an origin server -- usually, but not necessarily, after 303 receiving a 401 (Unauthorized) response. Its value consists of 304 credentials containing the authentication information of the user 305 agent for the realm of the resource being requested. 307 Authorization = credentials 309 If a request is authenticated and a realm specified, the same 310 credentials are presumed to be valid for all other requests within 311 this realm (assuming that the authentication scheme itself does not 312 require otherwise, such as credentials that vary according to a 313 challenge value or using synchronized clocks). 315 See Section 3.2 of [Part6] for details of and requirements pertaining 316 to handling of the Authorization field by HTTP caches. 318 4.2. Proxy-Authenticate 320 The "Proxy-Authenticate" header field consists of at least one 321 challenge that indicates the authentication scheme(s) and parameters 322 applicable to the proxy for this effective request URI (Section 5.5 323 of [Part1]). It MUST be included as part of a 407 (Proxy 324 Authentication Required) response. 326 Proxy-Authenticate = 1#challenge 328 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 329 only to the next outbound client on the response chain that chose to 330 direct its request to the responding proxy. If that recipient is 331 also a proxy, it will generally consume the Proxy-Authenticate header 332 field (and generate an appropriate Proxy-Authorization in a 333 subsequent request) rather than forward the header field to its own 334 outbound clients. However, if a recipient proxy needs to obtain its 335 own credentials by requesting them from a further outbound client, it 336 will generate its own 407 response, which might have the appearance 337 of forwarding the Proxy-Authenticate header field if both proxies use 338 the same challenge set. 340 Note that the parsing considerations for WWW-Authenticate apply to 341 this header field as well; see Section 4.4 for details. 343 4.3. Proxy-Authorization 345 The "Proxy-Authorization" header field allows the client to identify 346 itself (or its user) to a proxy that requires authentication. Its 347 value consists of credentials containing the authentication 348 information of the client for the proxy and/or realm of the resource 349 being requested. 351 Proxy-Authorization = credentials 353 Unlike Authorization, the Proxy-Authorization header field applies 354 only to the next inbound proxy that demanded authentication using the 355 Proxy-Authenticate field. When multiple proxies are used in a chain, 356 the Proxy-Authorization header field is consumed by the first inbound 357 proxy that was expecting to receive credentials. A proxy MAY relay 358 the credentials from the client request to the next proxy if that is 359 the mechanism by which the proxies cooperatively authenticate a given 360 request. 362 4.4. WWW-Authenticate 364 The "WWW-Authenticate" header field consists of at least one 365 challenge that indicates the authentication scheme(s) and parameters 366 applicable to the effective request URI (Section 5.5 of [Part1]). 368 It MUST be included in 401 (Unauthorized) response messages and MAY 369 be included in other response messages to indicate that supplying 370 credentials (or different credentials) might affect the response. 372 WWW-Authenticate = 1#challenge 374 User agents are advised to take special care in parsing the field 375 value, as it might contain more than one challenge, and each 376 challenge can contain a comma-separated list of authentication 377 parameters. Furthermore, the header field itself can occur multiple 378 times. 380 For instance: 382 WWW-Authenticate: Newauth realm="apps", type=1, 383 title="Login to \"apps\"", Basic realm="simple" 385 This header field contains two challenges; one for the "Newauth" 386 scheme with a realm value of "apps", and two additional parameters 387 "type" and "title", and another one for the "Basic" scheme with a 388 realm value of "simple". 390 Note: The challenge grammar production uses the list syntax as 391 well. Therefore, a sequence of comma, whitespace, and comma can 392 be considered either as applying to the preceding challenge, or to 393 be an empty entry in the list of challenges. In practice, this 394 ambiguity does not affect the semantics of the header field value 395 and thus is harmless. 397 5. IANA Considerations 399 5.1. Authentication Scheme Registry 401 The HTTP Authentication Scheme Registry defines the name space for 402 the authentication schemes in challenges and credentials. It will be 403 created and maintained at (the suggested URI) 404 . 406 5.1.1. Procedure 408 Registrations MUST include the following fields: 410 o Authentication Scheme Name 412 o Pointer to specification text 414 o Notes (optional) 416 Values to be added to this name space require IETF Review (see 417 [RFC5226], Section 4.1). 419 5.1.2. Considerations for New Authentication Schemes 421 There are certain aspects of the HTTP Authentication Framework that 422 put constraints on how new authentication schemes can work: 424 o HTTP authentication is presumed to be stateless: all of the 425 information necessary to authenticate a request MUST be provided 426 in the request, rather than be dependent on the server remembering 427 prior requests. Authentication based on, or bound to, the 428 underlying connection is outside the scope of this specification 429 and inherently flawed unless steps are taken to ensure that the 430 connection cannot be used by any party other than the 431 authenticated user (see Section 2.3 of [Part1]). 433 o The authentication parameter "realm" is reserved for defining 434 Protection Spaces as defined in Section 2.2. New schemes MUST NOT 435 use it in a way incompatible with that definition. 437 o The "token68" notation was introduced for compatibility with 438 existing authentication schemes and can only be used once per 439 challenge or credential. New schemes thus ought to use the "auth- 440 param" syntax instead, because otherwise future extensions will be 441 impossible. 443 o The parsing of challenges and credentials is defined by this 444 specification, and cannot be modified by new authentication 445 schemes. When the auth-param syntax is used, all parameters ought 446 to support both token and quoted-string syntax, and syntactical 447 constraints ought to be defined on the field value after parsing 448 (i.e., quoted-string processing). This is necessary so that 449 recipients can use a generic parser that applies to all 450 authentication schemes. 452 Note: The fact that the value syntax for the "realm" parameter is 453 restricted to quoted-string was a bad design choice not to be 454 repeated for new parameters. 456 o Definitions of new schemes ought to define the treatment of 457 unknown extension parameters. In general, a "must-ignore" rule is 458 preferable over "must-understand", because otherwise it will be 459 hard to introduce new parameters in the presence of legacy 460 recipients. Furthermore, it's good to describe the policy for 461 defining new parameters (such as "update the specification", or 462 "use this registry"). 464 o Authentication schemes need to document whether they are usable in 465 origin-server authentication (i.e., using WWW-Authenticate), 466 and/or proxy authentication (i.e., using Proxy-Authenticate). 468 o The credentials carried in an Authorization header field are 469 specific to the User Agent, and therefore have the same effect on 470 HTTP caches as the "private" Cache-Control response directive 471 (Section 5.2.2.6 of [Part6]), within the scope of the request they 472 appear in. 474 Therefore, new authentication schemes that choose not to carry 475 credentials in the Authorization header field (e.g., using a newly 476 defined header field) will need to explicitly disallow caching, by 477 mandating the use of either Cache-Control request directives 478 (e.g., "no-store", Section 5.2.1.5 of [Part6]) or response 479 directives (e.g., "private"). 481 5.2. Status Code Registration 483 The HTTP Status Code Registry located at 484 shall be updated 485 with the registrations below: 487 +-------+-------------------------------+-------------+ 488 | Value | Description | Reference | 489 +-------+-------------------------------+-------------+ 490 | 401 | Unauthorized | Section 3.1 | 491 | 407 | Proxy Authentication Required | Section 3.2 | 492 +-------+-------------------------------+-------------+ 494 5.3. Header Field Registration 496 HTTP header fields are registered within the Message Header Field 497 Registry maintained at . 500 This document defines the following HTTP header fields, so their 501 associated registry entries shall be updated according to the 502 permanent registrations below (see [BCP90]): 504 +---------------------+----------+----------+-------------+ 505 | Header Field Name | Protocol | Status | Reference | 506 +---------------------+----------+----------+-------------+ 507 | Authorization | http | standard | Section 4.1 | 508 | Proxy-Authenticate | http | standard | Section 4.2 | 509 | Proxy-Authorization | http | standard | Section 4.3 | 510 | WWW-Authenticate | http | standard | Section 4.4 | 511 +---------------------+----------+----------+-------------+ 513 The change controller is: "IETF (iesg@ietf.org) - Internet 514 Engineering Task Force". 516 6. Security Considerations 518 This section is meant to inform developers, information providers, 519 and users of known security concerns specific to HTTP/1.1 520 authentication. More general security considerations are addressed 521 in HTTP messaging [Part1] and semantics [Part2]. 523 6.1. Authentication Credentials and Idle Clients 525 Existing HTTP clients and user agents typically retain authentication 526 information indefinitely. HTTP does not provide a mechanism for the 527 origin server to direct clients to discard these cached credentials, 528 since the protocol has no awareness of how credentials are obtained 529 or managed by the user agent. The mechanisms for expiring or 530 revoking credentials can be specified as part of an authentication 531 scheme definition. 533 Circumstances under which credential caching can interfere with the 534 application's security model include but are not limited to: 536 o Clients that have been idle for an extended period, following 537 which the server might wish to cause the client to re-prompt the 538 user for credentials. 540 o Applications that include a session termination indication (such 541 as a "logout" or "commit" button on a page) after which the server 542 side of the application "knows" that there is no further reason 543 for the client to retain the credentials. 545 User agents that cache credentials are encouraged to provide a 546 readily accessible mechanism for discarding cached credentials under 547 user control. 549 6.2. Protection Spaces 551 Authentication schemes that solely rely on the "realm" mechanism for 552 establishing a protection space will expose credentials to all 553 resources on an origin server. Clients that have successfully made 554 authenticated requests with a resource can use the same 555 authentication credentials for other resources on the same origin 556 server. This makes it possible for a different resource to harvest 557 authentication credentials for other resources. 559 This is of particular concern when an origin server hosts resources 560 for multiple parties under the same canonical root URI (Section 2.2). 561 Possible mitigation strategies include restricting direct access to 562 authentication credentials (i.e., not making the content of the 563 Authorization request header field available), and separating 564 protection spaces by using a different host name (or port number) for 565 each party. 567 7. Acknowledgments 569 This specification takes over the definition of the HTTP 570 Authentication Framework, previously defined in RFC 2617. We thank 571 John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. 572 Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for 573 their work on that specification. See Section 6 of [RFC2617] for 574 further acknowledgements. 576 See Section 10 of [Part1] for the Acknowledgments related to this 577 document revision. 579 8. References 580 8.1. Normative References 582 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 583 Protocol (HTTP/1.1): Message Syntax and Routing", 584 draft-ietf-httpbis-p1-messaging-25 (work in progress), 585 November 2013. 587 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 588 Protocol (HTTP/1.1): Semantics and Content", 589 draft-ietf-httpbis-p2-semantics-25 (work in progress), 590 November 2013. 592 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 593 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 594 draft-ietf-httpbis-p6-cache-25 (work in progress), 595 November 2013. 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 601 Specifications: ABNF", STD 68, RFC 5234, January 2008. 603 8.2. Informative References 605 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 606 Procedures for Message Header Fields", BCP 90, RFC 3864, 607 September 2004. 609 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 610 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 611 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 613 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 614 Leach, P., Luotonen, A., and L. Stewart, "HTTP 615 Authentication: Basic and Digest Access Authentication", 616 RFC 2617, June 1999. 618 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 619 Resource Identifier (URI): Generic Syntax", STD 66, 620 RFC 3986, January 2005. 622 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 623 Encodings", RFC 4648, October 2006. 625 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 626 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 627 May 2008. 629 Appendix A. Changes from RFCs 2616 and 2617 631 The framework for HTTP Authentication is now defined by this 632 document, rather than RFC 2617. 634 The "realm" parameter is no longer always required on challenges; 635 consequently, the ABNF allows challenges without any auth parameters. 636 (Section 2) 638 The "token68" alternative to auth-param lists has been added for 639 consistency with legacy authentication schemes such as "Basic". 640 (Section 2) 642 This specification introduces the Authentication Scheme Registry, 643 along with considerations for new authentication schemes. 644 (Section 5.1) 646 Appendix B. Imported ABNF 648 The following core rules are included by reference, as defined in 649 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 650 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 651 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 652 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 653 character). 655 The rules below are defined in [Part1]: 657 BWS = 658 OWS = 659 quoted-string = 660 token = 662 Appendix C. Collected ABNF 664 In the collected ABNF below, list rules are expanded as per Section 665 1.2 of [Part1]. 667 Authorization = credentials 669 BWS = 671 OWS = 673 Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS 674 challenge ] ) 675 Proxy-Authorization = credentials 677 WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge 678 ] ) 680 auth-param = token BWS "=" BWS ( token / quoted-string ) 681 auth-scheme = token 683 challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *( 684 OWS "," [ OWS auth-param ] ) ] ) ] 685 credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) 686 *( OWS "," [ OWS auth-param ] ) ] ) ] 688 quoted-string = 690 token = 691 token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) 692 *"=" 694 Appendix D. Change Log (to be removed by RFC Editor before publication) 696 Changes up to the IETF Last Call draft are summarized in . 699 D.1. Since draft-ietf-httpbis-p7-auth-24 701 Closed issues: 703 o : "SECDIR review 704 of draft-ietf-httpbis-p7-auth-24" 706 o : "APPSDIR 707 review of draft-ietf-httpbis-p7-auth-24" 709 o : "note about 710 WWW-A parsing potentially misleading" 712 Index 714 4 715 401 Unauthorized (status code) 7 716 407 Proxy Authentication Required (status code) 7 718 A 719 Authorization header field 7 721 C 722 Canonical Root URI 6 724 G 725 Grammar 726 auth-param 5 727 auth-scheme 5 728 Authorization 8 729 challenge 5 730 credentials 5 731 Proxy-Authenticate 8 732 Proxy-Authorization 8 733 token68 5 734 WWW-Authenticate 9 736 P 737 Protection Space 6 738 Proxy-Authenticate header field 8 739 Proxy-Authorization header field 8 741 R 742 Realm 6 744 W 745 WWW-Authenticate header field 9 747 Authors' Addresses 749 Roy T. Fielding (editor) 750 Adobe Systems Incorporated 751 345 Park Ave 752 San Jose, CA 95110 753 USA 755 EMail: fielding@gbiv.com 756 URI: http://roy.gbiv.com/ 757 Julian F. Reschke (editor) 758 greenbytes GmbH 759 Hafenweg 16 760 Muenster, NW 48155 761 Germany 763 EMail: julian.reschke@greenbytes.de 764 URI: http://greenbytes.de/tech/webdav/