| draft-ietf-httpbis-p7-auth-23.txt |  | draft-ietf-httpbis-p7-auth-24.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Reschke, Ed. |  | Obsoletes: 2616 (if approved) J. Reschke, Ed. |
| Updates: 2617 (if approved) greenbytes |  | Updates: 2617 (if approved) greenbytes |
| Intended status: Standards Track July 15, 2013 |  | Intended status: Standards Track September 25, 2013 |
| Expires: January 16, 2014 |  | Expires: March 29, 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Authentication |  | Hypertext Transfer Protocol (HTTP/1.1): Authentication |
| draft-ietf-httpbis-p7-auth-23 |  | draft-ietf-httpbis-p7-auth-24 |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. This document defines the HTTP Authentication framework. |  | systems. This document defines the HTTP Authentication framework. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft takes place on the HTTPBIS working group |  | Discussion of this draft takes place on the HTTPBIS working group |
| mailing list (ietf-http-wg@w3.org), which is archived at |  | mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix D.4. |  | The changes in this draft are summarized in Appendix D.5. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on January 16, 2014. |  | This Internet-Draft will expire on March 29, 2014. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2013 IETF Trust and the persons identified as the |  | Copyright (c) 2013 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| skipping to change at page 3, line 43 |  | skipping to change at page 3, line 43 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 |
| Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 |  | Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 |
| Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 |  | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 |
| Appendix D. Change Log (to be removed by RFC Editor before |  | Appendix D. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 16 |  | publication) . . . . . . . . . . . . . . . . . . . . 16 |
| D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16 |  | D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16 |
| D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17 |  | D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17 |
| D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17 |  | D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17 |
| D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17 |  | D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | D.5. Since draft-ietf-httpbis-p7-auth-23 . . . . . . . . . . . 17 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 access control and authentication. It |  | This document defines HTTP/1.1 access control and authentication. It |
| includes the relevant parts of RFC 2616 with only minor changes |  | includes the relevant parts of RFC 2616 with only minor changes |
| ([RFC2616]), plus the general framework for HTTP authentication, as |  | ([RFC2616]), plus the general framework for HTTP authentication, as |
| previously defined in "HTTP Authentication: Basic and Digest Access |  | previously defined in "HTTP Authentication: Basic and Digest Access |
| Authentication" ([RFC2617]). |  | Authentication" ([RFC2617]). |
| HTTP provides several OPTIONAL challenge-response authentication |  | HTTP provides several OPTIONAL challenge-response authentication |
| skipping to change at page 4, line 32 |  | skipping to change at page 4, line 32 |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| Conformance criteria and considerations regarding error handling are |  | Conformance criteria and considerations regarding error handling are |
| defined in Section 2.5 of [Part1]. |  | defined in Section 2.5 of [Part1]. |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in Section |  | notation of [RFC5234] with the list rule extension defined in Section |
| 1.2 of [Part1]. Appendix B describes rules imported from other |  | 7 of [Part1]. Appendix B describes rules imported from other |
| documents. Appendix C shows the collected ABNF with the list rule |  | documents. Appendix C shows the collected ABNF with the list rule |
| expanded. |  | expanded. |
| 2. Access Authentication Framework |  | 2. Access Authentication Framework |
| 2.1. Challenge and Response |  | 2.1. Challenge and Response |
| HTTP provides a simple challenge-response authentication framework |  | HTTP provides a simple challenge-response authentication framework |
| that can be used by a server to challenge a client request and by a |  | that can be used by a server to challenge a client request and by a |
| client to provide authentication information. It uses a case- |  | client to provide authentication information. It uses a case- |
| skipping to change at page 6, line 36 |  | skipping to change at page 6, line 36 |
| gain access, ought to respond with the 403 (Forbidden) status code |  | gain access, ought to respond with the 403 (Forbidden) status code |
| (Section 6.5.3 of [Part2]). |  | (Section 6.5.3 of [Part2]). |
| The HTTP protocol does not restrict applications to this simple |  | The HTTP protocol does not restrict applications to this simple |
| challenge-response framework for access authentication. Additional |  | challenge-response framework for access authentication. Additional |
| mechanisms MAY be used, such as encryption at the transport level or |  | mechanisms MAY be used, such as encryption at the transport level or |
| via message encapsulation, and with additional header fields |  | via message encapsulation, and with additional header fields |
| specifying authentication information. However, such additional |  | specifying authentication information. However, such additional |
| mechanisms are not defined by this specification. |  | mechanisms are not defined by this specification. |
| Proxies MUST forward the WWW-Authenticate and Authorization header |  | A proxy MUST forward the WWW-Authenticate and Authorization header |
| fields unmodified and follow the rules found in Section 4.1. |  | fields unmodified and follow the rules found in Section 4.1. |
| 2.2. Protection Space (Realm) |  | 2.2. Protection Space (Realm) |
| The authentication parameter realm is reserved for use by |  | The authentication parameter realm is reserved for use by |
| authentication schemes that wish to indicate the scope of protection. |  | authentication schemes that wish to indicate the scope of protection. |
| A protection space is defined by the canonical root URI (the scheme |  | A protection space is defined by the canonical root URI (the scheme |
| and authority components of the effective request URI; see Section |  | and authority components of the effective request URI; see Section |
| 5.5 of [Part1]) of the server being accessed, in combination with the |  | 5.5 of [Part1]) of the server being accessed, in combination with the |
| realm value if present. These realms allow the protected resources |  | realm value if present. These realms allow the protected resources |
| on a server to be partitioned into a set of protection spaces, each |  | on a server to be partitioned into a set of protection spaces, each |
| with its own authentication scheme and/or authorization database. |  | with its own authentication scheme and/or authorization database. |
| The realm value is a string, generally assigned by the origin server, |  | The realm value is a string, generally assigned by the origin server, |
| that can have additional semantics specific to the authentication |  | which can have additional semantics specific to the authentication |
| scheme. Note that a response can have multiple challenges with the |  | scheme. Note that a response can have multiple challenges with the |
| same auth-scheme but different realms. |  | same auth-scheme but different realms. |
| The protection space determines the domain over which credentials can |  | The protection space determines the domain over which credentials can |
| be automatically applied. If a prior request has been authorized, |  | be automatically applied. If a prior request has been authorized, |
| the same credentials MAY be reused for all other requests within that |  | the user agent MAY reuse the same credentials for all other requests |
| protection space for a period of time determined by the |  | within that protection space for a period of time determined by the |
| authentication scheme, parameters, and/or user preference. Unless |  | authentication scheme, parameters, and/or user preference. Unless |
| specifically allowed by the authentication scheme, a single |  | specifically allowed by the authentication scheme, a single |
| protection space cannot extend outside the scope of its server. |  | protection space cannot extend outside the scope of its server. |
| For historical reasons, senders MUST only generate the quoted-string |  | For historical reasons, a sender MUST only generate the quoted-string |
| syntax. Recipients might have to support both token and quoted- |  | syntax. Recipients might have to support both token and quoted- |
| string syntax for maximum interoperability with existing clients that |  | string syntax for maximum interoperability with existing clients that |
| have been accepting both notations for a long time. |  | have been accepting both notations for a long time. |
| 3. Status Code Definitions |  | 3. Status Code Definitions |
| 3.1. 401 Unauthorized |  | 3.1. 401 Unauthorized |
| The 401 (Unauthorized) status code indicates that the request has not |  | The 401 (Unauthorized) status code indicates that the request has not |
| been applied because it lacks valid authentication credentials for |  | been applied because it lacks valid authentication credentials for |
| skipping to change at page 8, line 10 |  | skipping to change at page 8, line 10 |
| 4. Header Field Definitions |  | 4. Header Field Definitions |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to authentication. |  | fields related to authentication. |
| 4.1. Authorization |  | 4.1. Authorization |
| The "Authorization" header field allows a user agent to authenticate |  | The "Authorization" header field allows a user agent to authenticate |
| itself with an origin server -- usually, but not necessarily, after |  | itself with an origin server -- usually, but not necessarily, after |
| receiving a 401 (Unauthorized) response. Its value consists of |  | receiving a 401 (Unauthorized) response. Its value consists of |
| credentials containing information of the user agent for the realm of |  | credentials containing the authentication information of the user |
| the resource being requested. |  | agent for the realm of the resource being requested. |
| Authorization = credentials |  | Authorization = credentials |
| If a request is authenticated and a realm specified, the same |  | If a request is authenticated and a realm specified, the same |
| credentials SHOULD be valid for all other requests within this realm |  | credentials are presumed to be valid for all other requests within |
| (assuming that the authentication scheme itself does not require |  | this realm (assuming that the authentication scheme itself does not |
| otherwise, such as credentials that vary according to a challenge |  | require otherwise, such as credentials that vary according to a |
| value or using synchronized clocks). |  | challenge value or using synchronized clocks). |
| See Section 3.2 of [Part6] for details of and requirements pertaining |  | See Section 3.2 of [Part6] for details of and requirements pertaining |
| to handling of the Authorization field by HTTP caches. |  | to handling of the Authorization field by HTTP caches. |
| 4.2. Proxy-Authenticate |  | 4.2. Proxy-Authenticate |
| The "Proxy-Authenticate" header field consists of at least one |  | The "Proxy-Authenticate" header field consists of at least one |
| challenge that indicates the authentication scheme(s) and parameters |  | challenge that indicates the authentication scheme(s) and parameters |
| applicable to the proxy for this effective request URI (Section 5.5 |  | applicable to the proxy for this effective request URI (Section 5.5 |
| of [Part1]). It MUST be included as part of a 407 (Proxy |  | of [Part1]). It MUST be included as part of a 407 (Proxy |
| Authentication Required) response. |  | Authentication Required) response. |
| Proxy-Authenticate = 1#challenge |  | Proxy-Authenticate = 1#challenge |
| Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |  | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |
| only to the current connection, and intermediaries SHOULD NOT forward |  | only to the next outbound client on the response chain that chose to |
| it to downstream clients. However, an intermediate proxy might need |  | direct its request to the responding proxy. If that recipient is |
| to obtain its own credentials by requesting them from the downstream |  | also a proxy, it will generally consume the Proxy-Authenticate header |
| client, which in some circumstances will appear as if the proxy is |  | field (and generate an appropriate Proxy-Authorization in a |
| forwarding the Proxy-Authenticate header field. |  | subsequent request) rather than forward the header field to its own |
|  |  | outbound clients. However, if a recipient proxy needs to obtain its |
|  |  | own credentials by requesting them from a further outbound client, it |
|  |  | will generate its own 407 response, which might have the appearance |
|  |  | of forwarding the Proxy-Authenticate header field if both proxies use |
|  |  | the same challenge set. |
| Note that the parsing considerations for WWW-Authenticate apply to |  | Note that the parsing considerations for WWW-Authenticate apply to |
| this header field as well; see Section 4.4 for details. |  | this header field as well; see Section 4.4 for details. |
| 4.3. Proxy-Authorization |  | 4.3. Proxy-Authorization |
| The "Proxy-Authorization" header field allows the client to identify |  | The "Proxy-Authorization" header field allows the client to identify |
| itself (or its user) to a proxy that requires authentication. Its |  | itself (or its user) to a proxy that requires authentication. Its |
| value consists of credentials containing the authentication |  | value consists of credentials containing the authentication |
| information of the client for the proxy and/or realm of the resource |  | information of the client for the proxy and/or realm of the resource |
| being requested. |  | being requested. |
| Proxy-Authorization = credentials |  | Proxy-Authorization = credentials |
| Unlike Authorization, the Proxy-Authorization header field applies |  | Unlike Authorization, the Proxy-Authorization header field applies |
| only to the next outbound proxy that demanded authentication using |  | only to the next inbound proxy that demanded authentication using the |
| the Proxy-Authenticate field. When multiple proxies are used in a |  | Proxy-Authenticate field. When multiple proxies are used in a chain, |
| chain, the Proxy-Authorization header field is consumed by the first |  | the Proxy-Authorization header field is consumed by the first inbound |
| outbound proxy that was expecting to receive credentials. A proxy |  | proxy that was expecting to receive credentials. A proxy MAY relay |
| MAY relay the credentials from the client request to the next proxy |  | the credentials from the client request to the next proxy if that is |
| if that is the mechanism by which the proxies cooperatively |  | the mechanism by which the proxies cooperatively authenticate a given |
| authenticate a given request. |  | request. |
| 4.4. WWW-Authenticate |  | 4.4. WWW-Authenticate |
| The "WWW-Authenticate" header field consists of at least one |  | The "WWW-Authenticate" header field consists of at least one |
| challenge that indicates the authentication scheme(s) and parameters |  | challenge that indicates the authentication scheme(s) and parameters |
| applicable to the effective request URI (Section 5.5 of [Part1]). |  | applicable to the effective request URI (Section 5.5 of [Part1]). |
| It MUST be included in 401 (Unauthorized) response messages and MAY |  | It MUST be included in 401 (Unauthorized) response messages and MAY |
| be included in other response messages to indicate that supplying |  | be included in other response messages to indicate that supplying |
| credentials (or different credentials) might affect the response. |  | credentials (or different credentials) might affect the response. |
| skipping to change at page 11, line 30 |  | skipping to change at page 11, line 33 |
| defining new parameters (such as "update the specification", or |  | defining new parameters (such as "update the specification", or |
| "use this registry"). |  | "use this registry"). |
| o Authentication schemes need to document whether they are usable in |  | o Authentication schemes need to document whether they are usable in |
| origin-server authentication (i.e., using WWW-Authenticate), |  | origin-server authentication (i.e., using WWW-Authenticate), |
| and/or proxy authentication (i.e., using Proxy-Authenticate). |  | and/or proxy authentication (i.e., using Proxy-Authenticate). |
| o The credentials carried in an Authorization header field are |  | o The credentials carried in an Authorization header field are |
| specific to the User Agent, and therefore have the same effect on |  | specific to the User Agent, and therefore have the same effect on |
| HTTP caches as the "private" Cache-Control response directive |  | HTTP caches as the "private" Cache-Control response directive |
| (Section 7.2.2.6 of [Part6]), within the scope of the request they |  | (Section 5.2.2.6 of [Part6]), within the scope of the request they |
| appear in. |  | appear in. |
| Therefore, new authentication schemes that choose not to carry |  | Therefore, new authentication schemes that choose not to carry |
| credentials in the Authorization header field (e.g., using a newly |  | credentials in the Authorization header field (e.g., using a newly |
| defined header field) will need to explicitly disallow caching, by |  | defined header field) will need to explicitly disallow caching, by |
| mandating the use of either Cache-Control request directives |  | mandating the use of either Cache-Control request directives |
| (e.g., "no-store", Section 7.2.1.5 of [Part6]) or response |  | (e.g., "no-store", Section 5.2.1.5 of [Part6]) or response |
| directives (e.g., "private"). |  | directives (e.g., "private"). |
| 5.2. Status Code Registration |  | 5.2. Status Code Registration |
| The HTTP Status Code Registry located at |  | The HTTP Status Code Registry located at |
| <http://www.iana.org/assignments/http-status-codes> shall be updated |  | <http://www.iana.org/assignments/http-status-codes> shall be updated |
| with the registrations below: |  | with the registrations below: |
| +-------+-------------------------------+-------------+ |  | +-------+-------------------------------+-------------+ |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| skipping to change at page 12, line 44 |  | skipping to change at page 12, line 44 |
| 6. Security Considerations |  | 6. Security Considerations |
| This section is meant to inform developers, information providers, |  | This section is meant to inform developers, information providers, |
| and users of known security concerns specific to HTTP/1.1 |  | and users of known security concerns specific to HTTP/1.1 |
| authentication. More general security considerations are addressed |  | authentication. More general security considerations are addressed |
| in HTTP messaging [Part1] and semantics [Part2]. |  | in HTTP messaging [Part1] and semantics [Part2]. |
| 6.1. Authentication Credentials and Idle Clients |  | 6.1. Authentication Credentials and Idle Clients |
| Existing HTTP clients and user agents typically retain authentication |  | Existing HTTP clients and user agents typically retain authentication |
| information indefinitely. HTTP/1.1 does not provide a method for a |  | information indefinitely. HTTP does not provide a mechanism for the |
| server to direct clients to discard these cached credentials. This |  | origin server to direct clients to discard these cached credentials, |
| is a significant defect that requires further extensions to HTTP. |  | since the protocol has no awareness of how credentials are obtained |
|  |  | or managed by the user agent. The mechanisms for expiring or |
|  |  | revoking credentials can be specified as part of an authentication |
|  |  | scheme definition. |
| Circumstances under which credential caching can interfere with the |  | Circumstances under which credential caching can interfere with the |
| application's security model include but are not limited to: |  | application's security model include but are not limited to: |
| o Clients that have been idle for an extended period, following |  | o Clients that have been idle for an extended period, following |
| which the server might wish to cause the client to re-prompt the |  | which the server might wish to cause the client to re-prompt the |
| user for credentials. |  | user for credentials. |
| o Applications that include a session termination indication (such |  | o Applications that include a session termination indication (such |
| as a "logout" or "commit" button on a page) after which the server |  | as a "logout" or "commit" button on a page) after which the server |
| side of the application "knows" that there is no further reason |  | side of the application "knows" that there is no further reason |
| for the client to retain the credentials. |  | for the client to retain the credentials. |
| This is currently under separate study. There are a number of work- |  | User agents that cache credentials are encouraged to provide a |
| arounds to parts of this problem, and we encourage the use of |  | readily accessible mechanism for discarding cached credentials under |
| password protection in screen savers, idle time-outs, and other |  | user control. |
| methods that mitigate the security problems inherent in this problem. |  |  |
| In particular, user agents that cache credentials are encouraged to |  |  |
| provide a readily accessible mechanism for discarding cached |  |  |
| credentials under user control. |  |  |
| 6.2. Protection Spaces |  | 6.2. Protection Spaces |
| Authentication schemes that solely rely on the "realm" mechanism for |  | Authentication schemes that solely rely on the "realm" mechanism for |
| establishing a protection space will expose credentials to all |  | establishing a protection space will expose credentials to all |
| resources on an origin server. Clients that have successfully made |  | resources on an origin server. Clients that have successfully made |
| authenticated requests with a resource can use the same |  | authenticated requests with a resource can use the same |
| authentication credentials for other resources on the same origin |  | authentication credentials for other resources on the same origin |
| server. This makes it possible for a different resource to harvest |  | server. This makes it possible for a different resource to harvest |
| authentication credentials for other resources. |  | authentication credentials for other resources. |
| skipping to change at page 13, line 45 |  | skipping to change at page 13, line 45 |
| 7. Acknowledgments |  | 7. Acknowledgments |
| This specification takes over the definition of the HTTP |  | This specification takes over the definition of the HTTP |
| Authentication Framework, previously defined in RFC 2617. We thank |  | Authentication Framework, previously defined in RFC 2617. We thank |
| John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. |  | John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. |
| Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for |  | Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for |
| their work on that specification. See Section 6 of [RFC2617] for |  | their work on that specification. See Section 6 of [RFC2617] for |
| further acknowledgements. |  | further acknowledgements. |
| See Section 9 of [Part1] for the Acknowledgments related to this |  | See Section 10 of [Part1] for the Acknowledgments related to this |
| document revision. |  | document revision. |
| 8. References |  | 8. References |
| 8.1. Normative References |  | 8.1. Normative References |
| [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Message Syntax and Routing", |  | Protocol (HTTP/1.1): Message Syntax and Routing", |
| draft-ietf-httpbis-p1-messaging-23 (work in progress), |  | draft-ietf-httpbis-p1-messaging-24 (work in progress), |
| July 2013. |  | September 2013. |
| [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |  | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
| Protocol (HTTP/1.1): Semantics and Content", |  | Protocol (HTTP/1.1): Semantics and Content", |
| draft-ietf-httpbis-p2-semantics-23 (work in progress), |  | draft-ietf-httpbis-p2-semantics-24 (work in progress), |
| July 2013. |  | September 2013. |
| [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |  | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |  | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
| draft-ietf-httpbis-p6-cache-23 (work in progress), |  | draft-ietf-httpbis-p6-cache-24 (work in progress), |
| July 2013. |  | September 2013. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 8.2. Informative References |  | 8.2. Informative References |
| [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| skipping to change at page 17, line 43 |  | skipping to change at page 17, line 43 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology: |
| mechanism vs framework vs scheme" |  | mechanism vs framework vs scheme" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial |
| suggestions" |  | suggestions" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of |
| extension point considerations" |  | extension point considerations" |
|  |  | D.5. Since draft-ietf-httpbis-p7-auth-23 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/473>: "Forwarding |
|  |  | Proxy-*" |
| Index |  | Index |
| 4 |  | 4 |
| 401 Unauthorized (status code) 7 |  | 401 Unauthorized (status code) 7 |
| 407 Proxy Authentication Required (status code) 7 |  | 407 Proxy Authentication Required (status code) 7 |
| A |  | A |
| Authorization header field 8 |  | Authorization header field 8 |
| C |  | C |
| Canonical Root URI 6 |  | Canonical Root URI 6 |
| G |  | G |
| Grammar |  | Grammar |
| auth-param 5 |  | auth-param 5 |
| auth-scheme 5 |  | auth-scheme 5 |
| Authorization 8 |  | Authorization 8 |
| challenge 5 |  | challenge 5 |
| credentials 6 |  | credentials 6 |
| Proxy-Authenticate 8 |  | Proxy-Authenticate 8 |
| Proxy-Authorization 8 |  | Proxy-Authorization 9 |
| token68 5 |  | token68 5 |
| WWW-Authenticate 9 |  | WWW-Authenticate 9 |
| P |  | P |
| Protection Space 6 |  | Protection Space 6 |
| Proxy-Authenticate header field 8 |  | Proxy-Authenticate header field 8 |
| Proxy-Authorization header field 8 |  | Proxy-Authorization header field 8 |
| R |  | R |
| Realm 6 |  | Realm 6 |
End of changes. 24 change blocks.
| 50 lines changed or deleted |  | 63 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/