| draft-ietf-httpbis-p7-auth-21.txt |  | draft-ietf-httpbis-p7-auth-22.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 October 4, 2012 |  | Intended status: Standards Track February 23, 2013 |
| Expires: April 7, 2013 |  | Expires: August 27, 2013 |
| Hypertext Transfer Protocol (HTTP/1.1): Authentication |  | Hypertext Transfer Protocol (HTTP/1.1): Authentication |
| draft-ietf-httpbis-p7-auth-21 |  | draft-ietf-httpbis-p7-auth-22 |
| 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.2. |  | The changes in this draft are summarized in Appendix D.3. |
| 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 April 7, 2013. |  | This Internet-Draft will expire on August 27, 2013. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 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 |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| skipping to change at page 3, line 22 |  | skipping to change at page 3, line 22 |
| 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 |  | 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 |
| 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 |  | 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 |
| 2.3.1. Considerations for New Authentication Schemes . . . . 7 |  | 2.3.1. Considerations for New Authentication Schemes . . . . 7 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 |
| 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 |  | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 |
| 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 |  | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 |
| 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 |  | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 |
| 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 |  | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 |
| 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 |  | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 |
| 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 |  | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 |
| 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 |  | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 10 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 |
| 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12 |  | 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 11 |
| 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 |  | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11 |
| 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 |  | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 |
| 6.1. Authentication Credentials and Idle Clients . . . . . . . 13 |  | 6.1. Authentication Credentials and Idle Clients . . . . . . . 12 |
| 6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13 |  | 6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 |
| 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 . . . . . . . . . . . 14 |
| Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 |  | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 |
| 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 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 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 |
| mechanisms which can be used by a server to challenge a client |  | mechanisms that can be used by a server to challenge a client request |
| request and by a client to provide authentication information. The |  | and by a client to provide authentication information. The "basic" |
| "basic" and "digest" authentication schemes continue to be specified |  | and "digest" authentication schemes continue to be specified in RFC |
| in RFC 2617. |  | 2617. |
| 1.1. Conformance and Error Handling |  | 1.1. Conformance and Error Handling |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "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]. |
| skipping to change at page 6, line 15 |  | skipping to change at page 6, line 15 |
| (possibly at some point in the past). When creating their values, |  | (possibly at some point in the past). When creating their values, |
| the user agent ought to do so by selecting the challenge with what it |  | the user agent ought to do so by selecting the challenge with what it |
| considers to be the most secure auth-scheme that it understands, |  | considers to be the most secure auth-scheme that it understands, |
| obtaining credentials from the user as appropriate. |  | obtaining credentials from the user as appropriate. |
| credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] |  | credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] |
| Upon a request for a protected resource that omits credentials, |  | Upon a request for a protected resource that omits credentials, |
| contains invalid credentials (e.g., a bad password) or partial |  | contains invalid credentials (e.g., a bad password) or partial |
| credentials (e.g., when the authentication scheme requires more than |  | credentials (e.g., when the authentication scheme requires more than |
| one round trip), an origin server SHOULD return a 401 (Unauthorized) |  | one round trip), an origin server SHOULD send a 401 (Unauthorized) |
| response. Such responses MUST include a WWW-Authenticate header |  | response that contains a WWW-Authenticate header field with at least |
| field containing at least one (possibly new) challenge applicable to |  | one (possibly new) challenge applicable to the requested resource. |
| the requested resource. |  |  |
| Likewise, upon a request that requires authentication by proxies that |  | Likewise, upon a request that requires authentication by proxies that |
| omit credentials or contain invalid or partial credentials, a proxy |  | omit credentials or contain invalid or partial credentials, a proxy |
| SHOULD return a 407 (Proxy Authentication Required) response. Such |  | SHOULD send a 407 (Proxy Authentication Required) response that |
| responses MUST include a Proxy-Authenticate header field containing a |  | contains a Proxy-Authenticate header field with a (possibly new) |
| (possibly new) challenge applicable to the proxy. |  | challenge applicable to the proxy. |
| A server receiving credentials that are valid, but not adequate to |  | A server receiving credentials that are valid, but not adequate to |
| gain access, ought to respond with the 403 (Forbidden) status code |  | gain access, ought to respond with the 403 (Forbidden) status code |
| (Section 7.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 mechanism for access authentication. Additional |  | challenge-response mechanism 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 |  | Proxies 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. |
| skipping to change at page 7, line 4 |  | skipping to change at page 6, line 51 |
| 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, |
| which can have additional semantics specific to the authentication |  | that can have additional semantics specific to the authentication |
| scheme. Note that there can be multiple challenges with the same |  | scheme. Note that there can be multiple challenges with the same |
| auth-scheme but different realms. |  | 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 same credentials MAY be reused for all other requests within that |
| protection space for a period of time determined by the |  | 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 |
| otherwise defined by the authentication scheme, a single protection |  | otherwise defined by the authentication scheme, a single protection |
| space cannot extend outside the scope of its server. |  | space cannot extend outside the scope of its server. |
| skipping to change at page 8, line 46 |  | skipping to change at page 8, line 45 |
| 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, |
| within the scope of the request they appear in. |  | within the scope of the request they appear in. |
| Therefore, new authentication schemes which 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") or response directives (e.g., "private"). |  | (e.g., "no-store") or response directives (e.g., "private"). |
| 3. Status Code Definitions |  | 3. Status Code Definitions |
| 3.1. 401 Unauthorized |  | 3.1. 401 Unauthorized |
| The request requires user authentication. The response MUST include |  | The 401 (Unauthorized) status code indicates that the request has not |
| a WWW-Authenticate header field (Section 4.4) containing a challenge |  | been applied because it lacks valid authentication credentials for |
| applicable to the target resource. The client MAY repeat the request |  | the target resource. The origin server MUST send a WWW-Authenticate |
| with a suitable Authorization header field (Section 4.1). If the |  | header field (Section 4.4) containing at least one challenge |
| request already included Authorization credentials, then the 401 |  | applicable to the target resource. If the request included |
| response indicates that authorization has been refused for those |  | authentication credentials, then the 401 response indicates that |
| credentials. If the 401 response contains the same challenge as the |  | authorization has been refused for those credentials. The client MAY |
| prior response, and the user agent has already attempted |  | repeat the request with a new or replaced Authorization header field |
| authentication at least once, then the user SHOULD be presented the |  | (Section 4.1). If the 401 response contains the same challenge as |
| representation that was given in the response, since that |  | the prior response, and the user agent has already attempted |
| representation might include relevant diagnostic information. |  | authentication at least once, then the user agent SHOULD present the |
|  |  | enclosed representation to the user, since it usually contains |
|  |  | relevant diagnostic information. |
| 3.2. 407 Proxy Authentication Required |  | 3.2. 407 Proxy Authentication Required |
| This code is similar to 401 (Unauthorized), but indicates that the |  | The 407 (Proxy Authentication Required) status code is similar to 401 |
| client ought to first authenticate itself with the proxy. The proxy |  | (Unauthorized), but indicates that the client needs to authenticate |
| MUST return a Proxy-Authenticate header field (Section 4.2) |  | itself in order to use a proxy. The proxy MUST send a Proxy- |
| containing a challenge applicable to the proxy for the target |  | Authenticate header field (Section 4.2) containing a challenge |
| resource. The client MAY repeat the request with a suitable Proxy- |  | applicable to that proxy for the target resource. The client MAY |
| Authorization header field (Section 4.3). |  | repeat the request with a new or replaced Proxy-Authorization header |
|  |  | field (Section 4.3). |
| 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 a server -- usually, but not necessarily, after receiving |  | itself with a server -- usually, but not necessarily, after receiving |
| skipping to change at page 9, line 51 |  | skipping to change at page 10, line 5 |
| resource being requested. |  | 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 SHOULD be valid for all other requests within this realm |
| (assuming that the authentication scheme itself does not require |  | (assuming that the authentication scheme itself does not require |
| otherwise, such as credentials that vary according to a challenge |  | otherwise, such as credentials that vary according to a challenge |
| value or using synchronized clocks). |  | value or using synchronized clocks). |
| When a shared cache (see Section 1.2 of [Part6]) receives a request |  | See Section 3.2 of [Part6] for details of and requirements pertaining |
| containing an Authorization field, it MUST NOT return the |  | to handling of the Authorization field by HTTP caches. |
| corresponding response as a reply to any other request, unless one of |  |  |
| the following specific exceptions holds: |  |  |
| 1. If the response includes the "s-maxage" cache-control directive, |  |  |
| the cache MAY use that response in replying to a subsequent |  |  |
| request. But (if the specified maximum age has passed) a proxy |  |  |
| cache MUST first revalidate it with the origin server, using the |  |  |
| header fields from the new request to allow the origin server to |  |  |
| authenticate the new request. (This is the defined behavior for |  |  |
| s-maxage.) If the response includes "s-maxage=0", the proxy MUST |  |  |
| always revalidate it before re-using it. |  |  |
| 2. If the response includes the "must-revalidate" cache-control |  |  |
| directive, the cache MAY use that response in replying to a |  |  |
| subsequent request. But if the response is stale, all caches |  |  |
| MUST first revalidate it with the origin server, using the header |  |  |
| fields from the new request to allow the origin server to |  |  |
| authenticate the new request. |  |  |
| 3. If the response includes the "public" cache-control directive, it |  |  |
| MAY be returned in reply to any subsequent request. |  |  |
| 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 |
| skipping to change at page 10, line 49 |  | skipping to change at page 10, line 31 |
| to obtain its own credentials by requesting them from the downstream |  | to obtain its own credentials by requesting them from the downstream |
| client, which in some circumstances will appear as if the proxy is |  | client, which in some circumstances will appear as if the proxy is |
| forwarding the Proxy-Authenticate header field. |  | forwarding the Proxy-Authenticate header field. |
| 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 which 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 user agent for the proxy and/or realm of the |  | information of the user agent for the proxy and/or realm of the |
| resource being requested. |  | resource 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 outbound proxy that demanded authentication using |
| the Proxy-Authenticate field. When multiple proxies are used in a |  | the Proxy-Authenticate field. When multiple proxies are used in a |
| chain, the Proxy-Authorization header field is consumed by the first |  | chain, the Proxy-Authorization header field is consumed by the first |
| skipping to change at page 12, line 32 |  | skipping to change at page 12, line 16 |
| | Value | Description | Reference | |  | | Value | Description | Reference | |
| +-------+-------------------------------+-------------+ |  | +-------+-------------------------------+-------------+ |
| | 401 | Unauthorized | Section 3.1 | |  | | 401 | Unauthorized | Section 3.1 | |
| | 407 | Proxy Authentication Required | Section 3.2 | |  | | 407 | Proxy Authentication Required | Section 3.2 | |
| +-------+-------------------------------+-------------+ |  | +-------+-------------------------------+-------------+ |
| 5.3. Header Field Registration |  | 5.3. Header Field Registration |
| The Message Header Field Registry located at <http://www.iana.org/ |  | The Message Header Field Registry located at <http://www.iana.org/ |
| assignments/message-headers/message-header-index.html> shall be |  | assignments/message-headers/message-header-index.html> shall be |
| updated with the permanent registrations below (see [RFC3864]): |  | updated with the permanent registrations below (see [BCP90]): |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| | Authorization | http | standard | Section 4.1 | |  | | Authorization | http | standard | Section 4.1 | |
| | Proxy-Authenticate | http | standard | Section 4.2 | |  | | Proxy-Authenticate | http | standard | Section 4.2 | |
| | Proxy-Authorization | http | standard | Section 4.3 | |  | | Proxy-Authorization | http | standard | Section 4.3 | |
| | WWW-Authenticate | http | standard | Section 4.4 | |  | | WWW-Authenticate | http | standard | Section 4.4 | |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| The change controller is: "IETF (iesg@ietf.org) - Internet |  | The change controller is: "IETF (iesg@ietf.org) - Internet |
| Engineering Task Force". |  | Engineering Task Force". |
| 6. Security Considerations |  | 6. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform developers, information providers, |
| providers, and users of the security limitations in HTTP/1.1 as |  | and users of known security concerns specific to HTTP/1.1 |
| described by this document. The discussion does not include |  | authentication. More general security considerations are addressed |
| definitive solutions to the problems revealed, though it does make |  | in HTTP messaging [Part1] and semantics [Part2]. |
| some suggestions for reducing security risks. |  |  |
| 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/1.1 does not provide a method for a |
| server to direct clients to discard these cached credentials. This |  | server to direct clients to discard these cached credentials. This |
| is a significant defect that requires further extensions to HTTP. |  | is a significant defect that requires further extensions to HTTP. |
| 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 which 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 reprompt the |  | which the server might wish to cause the client to re-prompt the |
| user for credentials. |  | user for credentials. |
| o Applications which 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- |  | This is currently under separate study. There are a number of work- |
| arounds to parts of this problem, and we encourage the use of |  | arounds to parts of this problem, and we encourage the use of |
| password protection in screen savers, idle time-outs, and other |  | password protection in screen savers, idle time-outs, and other |
| methods which mitigate the security problems inherent in this |  | methods that mitigate the security problems inherent in this problem. |
| problem. In particular, user agents which cache credentials are |  | In particular, user agents that cache credentials are encouraged to |
| encouraged to provide a readily accessible mechanism for discarding |  | provide a readily accessible mechanism for discarding cached |
| cached credentials under user control. |  | 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 a server. Clients that have successfully made |  | resources on a 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 server. |  | authentication credentials for other resources on the same server. |
| This makes it possible for a different resource to harvest |  | 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 14, line 18 |  | skipping to change at page 13, line 49 |
| See Section 9 of [Part1] for the Acknowledgments related to this |  | See Section 9 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-21 (work in progress), |  | draft-ietf-httpbis-p1-messaging-22 (work in progress), |
| October 2012. |  | February 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-21 (work in progress), |  | draft-ietf-httpbis-p2-semantics-22 (work in progress), |
| October 2012. |  | February 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-21 (work in progress), |  | draft-ietf-httpbis-p6-cache-22 (work in progress), |
| October 2012. |  | February 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 |
|  |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
|  |  | September 2004. |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |  | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |  | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
| [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |  | [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |
| Leach, P., Luotonen, A., and L. Stewart, "HTTP |  | Leach, P., Luotonen, A., and L. Stewart, "HTTP |
| Authentication: Basic and Digest Access Authentication", |  | Authentication: Basic and Digest Access Authentication", |
| RFC 2617, June 1999. |  | RFC 2617, June 1999. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  |  |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  |  |
| September 2004. |  |  |
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Resource Identifier (URI): Generic Syntax", STD 66, |  | Resource Identifier (URI): Generic Syntax", STD 66, |
| RFC 3986, January 2005. |  | RFC 3986, January 2005. |
| [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data |  | [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data |
| Encodings", RFC 4648, October 2006. |  | Encodings", RFC 4648, October 2006. |
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
| May 2008. |  | May 2008. |
| Appendix A. Changes from RFCs 2616 and 2617 |  | Appendix A. Changes from RFCs 2616 and 2617 |
| The "realm" parameter isn't required anymore in general; |  | The framework for HTTP Authentication is now defined by this |
|  |  | document, rather than RFC 2617. |
|  |  | The "realm" parameter is no longer always required on challenges; |
| consequently, the ABNF allows challenges without any auth parameters. |  | consequently, the ABNF allows challenges without any auth parameters. |
| (Section 2) |  | (Section 2) |
| The "token68" alternative to auth-param lists has been added for |  | The "token68" alternative to auth-param lists has been added for |
| consistency with legacy authentication schemes such as "Basic". |  | consistency with legacy authentication schemes such as "Basic". |
| (Section 2) |  | (Section 2) |
| Introduce Authentication Scheme Registry. (Section 2.3) |  | This specification introduces the Authentication Scheme Registry, |
|  |  | along with considerations for new authentication schemes. |
|  |  | (Section 2.3) |
| Appendix B. Imported ABNF |  | Appendix B. Imported ABNF |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
| CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |  | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |
| quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any |  | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any |
| 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |  | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |
| character). |  | character). |
| The rules below are defined in [Part1]: |  | The rules below are defined in [Part1]: |
| BWS = <BWS, defined in [Part1], Section 3.2.1> |  | BWS = <BWS, defined in [Part1], Section 3.2.3> |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.6> |
| Appendix C. Collected ABNF |  | Appendix C. Collected ABNF |
| Authorization = credentials |  | Authorization = credentials |
| BWS = <BWS, defined in [Part1], Section 3.2.1> |  | BWS = <BWS, defined in [Part1], Section 3.2.3> |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS |  | Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS |
| challenge ] ) |  | challenge ] ) |
| Proxy-Authorization = credentials |  | Proxy-Authorization = credentials |
| WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge |  | WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge |
| ] ) |  | ] ) |
| auth-param = token BWS "=" BWS ( token / quoted-string ) |  | auth-param = token BWS "=" BWS ( token / quoted-string ) |
| auth-scheme = token |  | auth-scheme = token |
| challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *( |  | challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *( |
| OWS "," [ OWS auth-param ] ) ] ) ] |  | OWS "," [ OWS auth-param ] ) ] ) ] |
| credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) |  | credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) |
| *( OWS "," [ OWS auth-param ] ) ] ) ] |  | *( OWS "," [ OWS auth-param ] ) ] ) ] |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.6> |
| token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) |  | token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) |
| *"=" |  | *"=" |
| Appendix D. Change Log (to be removed by RFC Editor before publication) |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| Changes up to the first Working Group Last Call draft are summarized |  | Changes up to the first Working Group Last Call draft are summarized |
| in <http://trac.tools.ietf.org/html/ |  | in <http://trac.tools.ietf.org/html/ |
| draft-ietf-httpbis-p7-auth-19#appendix-C>. |  | draft-ietf-httpbis-p7-auth-19#appendix-C>. |
| D.1. Since draft-ietf-httpbis-p7-auth-19 |  | D.1. Since draft-ietf-httpbis-p7-auth-19 |
| skipping to change at page 17, line 23 |  | skipping to change at page 17, line 23 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename |
| b64token for clarity" |  | b64token for clarity" |
| Other changes: |  | Other changes: |
| o Conformance criteria and considerations regarding error handling |  | o Conformance criteria and considerations regarding error handling |
| are now defined in Part 1. |  | are now defined in Part 1. |
|  |  | D.3. Since draft-ietf-httpbis-p7-auth-21 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>: |
|  |  | "Authentication and caching - max-age" |
| Index |  | Index |
| 4 |  | 4 |
| 401 Unauthorized (status code) 9 |  | 401 Unauthorized (status code) 9 |
| 407 Proxy Authentication Required (status code) 9 |  | 407 Proxy Authentication Required (status code) 9 |
| A |  | A |
| Authorization header field 9 |  | Authorization header field 9 |
| 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 9 |  | Authorization 9 |
| challenge 5 |  | challenge 5 |
| credentials 6 |  | credentials 6 |
| Proxy-Authenticate 10 |  | Proxy-Authenticate 10 |
| Proxy-Authorization 11 |  | Proxy-Authorization 10 |
| token68 5 |  | token68 5 |
| WWW-Authenticate 11 |  | WWW-Authenticate 11 |
| P |  | P |
| Protection Space 6 |  | Protection Space 6 |
| Proxy-Authenticate header field 10 |  | Proxy-Authenticate header field 10 |
| Proxy-Authorization header field 10 |  | Proxy-Authorization header field 10 |
| R |  | R |
| Realm 6 |  | Realm 6 |
| W |  | W |
| WWW-Authenticate header field 11 |  | WWW-Authenticate header field 10 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Adobe Systems Incorporated |  | Adobe Systems Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| EMail: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
End of changes. 40 change blocks.
| 104 lines changed or deleted |  | 97 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/