| draft-ietf-httpbis-p7-auth-22.txt |  | draft-ietf-httpbis-p7-auth-23.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 February 23, 2013 |  | Intended status: Standards Track July 15, 2013 |
| Expires: August 27, 2013 |  | Expires: January 16, 2014 |
| Hypertext Transfer Protocol (HTTP/1.1): Authentication |  | Hypertext Transfer Protocol (HTTP/1.1): Authentication |
| draft-ietf-httpbis-p7-auth-22 |  | draft-ietf-httpbis-p7-auth-23 |
| 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.3. |  | The changes in this draft are summarized in Appendix D.4. |
| 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 August 27, 2013. |  | This Internet-Draft will expire on January 16, 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 13 |  | skipping to change at page 3, line 13 |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 2. Access Authentication Framework . . . . . . . . . . . . . . . 4 |  | 2. Access Authentication Framework . . . . . . . . . . . . . . . 4 |
| 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4 |  | 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4 |
| 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 |  | 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 |
| 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 |
| 2.3.1. Considerations for New Authentication Schemes . . . . 7 |  | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 |  | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7 |
| 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 |  | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7 |
| 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 |  | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 |
| 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 |  | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 8 |
| 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 |  | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 8 |
| 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 |  | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9 |
| 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 |
| 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 10 |  | 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 |  | 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10 |
| 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 11 |  | 5.1.2. Considerations for New Authentication Schemes . . . . 10 |
| 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11 |  | 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 . . . . . . . 12 |  | 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 |
| Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14 |  | Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 |
| Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 |  | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 |
| Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 |  | 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 |
| 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 that can be used by a server to challenge a client request |  | schemes that can be used by a server to challenge a client request |
| and by a client to provide authentication information. The "basic" |  | and by a client to provide authentication information. The "basic" |
| and "digest" authentication schemes continue to be specified in RFC |  | and "digest" authentication schemes continue to be specified 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]. |
| skipping to change at page 4, line 40 |  | skipping to change at page 4, line 40 |
| 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 |  | 1.2 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 mechanism |  | 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 an extensible, |  | client to provide authentication information. It uses a case- |
| case-insensitive token to identify the authentication scheme, |  | insensitive token as a means to identify the authentication scheme, |
| followed by additional information necessary for achieving |  | followed by additional information necessary for achieving |
| authentication via that scheme. The latter can either be a comma- |  | authentication via that scheme. The latter can either be a comma- |
| separated list of parameters or a single sequence of characters |  | separated list of parameters or a single sequence of characters |
| capable of holding base64-encoded information. |  | capable of holding base64-encoded information. |
| Parameters are name-value pairs where the name is matched case- |  | Parameters are name-value pairs where the name is matched case- |
| insensitively, and each parameter name MUST only occur once per |  | insensitively, and each parameter name MUST only occur once per |
| challenge. |  | challenge. |
| auth-scheme = token |  | auth-scheme = token |
| skipping to change at page 6, line 4 |  | skipping to change at page 6, line 4 |
| -- can do so by including an Authorization header field with the |  | -- can do so by including an Authorization header field with the |
| request. |  | request. |
| A client that wishes to authenticate itself with a proxy -- usually, |  | A client that wishes to authenticate itself with a proxy -- usually, |
| but not necessarily, after receiving a 407 (Proxy Authentication |  | but not necessarily, after receiving a 407 (Proxy Authentication |
| Required) -- can do so by including a Proxy-Authorization header |  | Required) -- can do so by including a Proxy-Authorization header |
| field with the request. |  | field with the request. |
| Both the Authorization field value and the Proxy-Authorization field |  | Both the Authorization field value and the Proxy-Authorization field |
| value contain the client's credentials for the realm of the resource |  | value contain the client's credentials for the realm of the resource |
| being requested, based upon a challenge received from the server |  | being requested, based upon a challenge received in a response |
| (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 |
| skipping to change at page 6, line 30 |  | skipping to change at page 6, line 30 |
| omit credentials or contain invalid or partial credentials, a proxy |  | omit credentials or contain invalid or partial credentials, a proxy |
| SHOULD send a 407 (Proxy Authentication Required) response that |  | SHOULD send a 407 (Proxy Authentication Required) response that |
| contains a Proxy-Authenticate header field with a (possibly new) |  | contains a Proxy-Authenticate header field with a (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 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 mechanism 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 |  | 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. |
| 2.2. Protection Space (Realm) |  | 2.2. Protection Space (Realm) |
| skipping to change at page 7, line 4 |  | skipping to change at page 7, line 4 |
| 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 |  | that can have additional semantics specific to the authentication |
| scheme. Note that there can be multiple challenges with the same |  | scheme. Note that a response can have multiple challenges with the |
| 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 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 |  | specifically allowed by the authentication scheme, a single |
| 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 use the quoted-string |  | For historical reasons, senders 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. |
| 2.3. Authentication Scheme Registry |  |  |
| The HTTP Authentication Scheme Registry defines the name space for |  |  |
| the authentication schemes in challenges and credentials. |  |  |
| Registrations MUST include the following fields: |  |  |
| o Authentication Scheme Name |  |  |
| o Pointer to specification text |  |  |
| o Notes (optional) |  |  |
| Values to be added to this name space require IETF Review (see |  |  |
| [RFC5226], Section 4.1). |  |  |
| The registry itself is maintained at |  |  |
| <http://www.iana.org/assignments/http-authschemes>. |  |  |
| 2.3.1. Considerations for New Authentication Schemes |  |  |
| There are certain aspects of the HTTP Authentication Framework that |  |  |
| put constraints on how new authentication schemes can work: |  |  |
| o HTTP authentication is presumed to be stateless: all of the |  |  |
| information necessary to authenticate a request MUST be provided |  |  |
| in the request, rather than be dependent on the server remembering |  |  |
| prior requests. Authentication based on, or bound to, the |  |  |
| underlying connection is outside the scope of this specification |  |  |
| and inherently flawed unless steps are taken to ensure that the |  |  |
| connection cannot be used by any party other than the |  |  |
| authenticated user (see Section 2.3 of [Part1]). |  |  |
| o The authentication parameter "realm" is reserved for defining |  |  |
| Protection Spaces as defined in Section 2.2. New schemes MUST NOT |  |  |
| use it in a way incompatible with that definition. |  |  |
| o The "token68" notation was introduced for compatibility with |  |  |
| existing authentication schemes and can only be used once per |  |  |
| challenge/credentials. New schemes thus ought to use the "auth- |  |  |
| param" syntax instead, because otherwise future extensions will be |  |  |
| impossible. |  |  |
| o The parsing of challenges and credentials is defined by this |  |  |
| specification, and cannot be modified by new authentication |  |  |
| schemes. When the auth-param syntax is used, all parameters ought |  |  |
| to support both token and quoted-string syntax, and syntactical |  |  |
| constraints ought to be defined on the field value after parsing |  |  |
| (i.e., quoted-string processing). This is necessary so that |  |  |
| recipients can use a generic parser that applies to all |  |  |
| authentication schemes. |  |  |
| Note: The fact that the value syntax for the "realm" parameter is |  |  |
| restricted to quoted-string was a bad design choice not to be |  |  |
| repeated for new parameters. |  |  |
| o Definitions of new schemes ought to define the treatment of |  |  |
| unknown extension parameters. In general, a "must-ignore" rule is |  |  |
| preferable over "must-understand", because otherwise it will be |  |  |
| hard to introduce new parameters in the presence of legacy |  |  |
| recipients. Furthermore, it's good to describe the policy for |  |  |
| defining new parameters (such as "update the specification", or |  |  |
| "use this registry"). |  |  |
| o Authentication schemes need to document whether they are usable in |  |  |
| origin-server authentication (i.e., using WWW-Authenticate), |  |  |
| and/or proxy authentication (i.e., using Proxy-Authenticate). |  |  |
| o The credentials carried in an Authorization header field are |  |  |
| specific to the User Agent, and therefore have the same effect on |  |  |
| HTTP caches as the "private" Cache-Control response directive, |  |  |
| within the scope of the request they appear in. |  |  |
| Therefore, new authentication schemes that choose not to carry |  |  |
| credentials in the Authorization header field (e.g., using a newly |  |  |
| defined header field) will need to explicitly disallow caching, by |  |  |
| mandating the use of either Cache-Control request directives |  |  |
| (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 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 |
| the target resource. The origin server MUST send a WWW-Authenticate |  | the target resource. The origin server MUST send a WWW-Authenticate |
| header field (Section 4.4) containing at least one challenge |  | header field (Section 4.4) containing at least one challenge |
| applicable to the target resource. If the request included |  | applicable to the target resource. If the request included |
| authentication credentials, then the 401 response indicates that |  | authentication credentials, then the 401 response indicates that |
| authorization has been refused for those credentials. The client MAY |  | authorization has been refused for those credentials. The user agent |
| repeat the request with a new or replaced Authorization header field |  | MAY repeat the request with a new or replaced Authorization header |
| (Section 4.1). If the 401 response contains the same challenge as |  | field (Section 4.1). If the 401 response contains the same challenge |
| the prior response, and the user agent has already attempted |  | as the prior response, and the user agent has already attempted |
| authentication at least once, then the user agent SHOULD present the |  | authentication at least once, then the user agent SHOULD present the |
| enclosed representation to the user, since it usually contains |  | enclosed representation to the user, since it usually contains |
| relevant diagnostic information. |  | relevant diagnostic information. |
| 3.2. 407 Proxy Authentication Required |  | 3.2. 407 Proxy Authentication Required |
| The 407 (Proxy Authentication Required) status code is similar to 401 |  | The 407 (Proxy Authentication Required) status code is similar to 401 |
| (Unauthorized), but indicates that the client needs to authenticate |  | (Unauthorized), but indicates that the client needs to authenticate |
| itself in order to use a proxy. The proxy MUST send a Proxy- |  | itself in order to use a proxy. The proxy MUST send a Proxy- |
| Authenticate header field (Section 4.2) containing a challenge |  | Authenticate header field (Section 4.2) containing a challenge |
| skipping to change at page 9, line 41 |  | skipping to change at page 8, line 8 |
| field (Section 4.3). |  | 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 an origin server -- usually, but not necessarily, after |
| a 401 (Unauthorized) response. Its value consists of credentials |  | receiving a 401 (Unauthorized) response. Its value consists of |
| containing information of the user agent for the realm of the |  | credentials containing information of the user agent for the realm of |
| resource being requested. |  | 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 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). |
| See Section 3.2 of [Part6] for details of and requirements pertaining |  | See Section 3.2 of [Part6] for details of and requirements pertaining |
| skipping to change at page 10, line 33 |  | skipping to change at page 8, line 49 |
| 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 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 user agent for the proxy and/or realm of the |  | information of the client for the proxy and/or realm of the resource |
| 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 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 |
| outbound proxy that was expecting to receive credentials. A proxy |  | outbound proxy that was expecting to receive credentials. A proxy |
| MAY relay the credentials from the client request to the next proxy |  | MAY relay the credentials from the client request to the next proxy |
| if that is the mechanism by which the proxies cooperatively |  | if that is the mechanism by which the proxies cooperatively |
| skipping to change at page 11, line 38 |  | skipping to change at page 10, line 9 |
| well. Therefore, a sequence of comma, whitespace, and comma can |  | well. Therefore, a sequence of comma, whitespace, and comma can |
| be considered both as applying to the preceding challenge, or to |  | be considered both as applying to the preceding challenge, or to |
| be an empty entry in the list of challenges. In practice, this |  | be an empty entry in the list of challenges. In practice, this |
| ambiguity does not affect the semantics of the header field value |  | ambiguity does not affect the semantics of the header field value |
| and thus is harmless. |  | and thus is harmless. |
| 5. IANA Considerations |  | 5. IANA Considerations |
| 5.1. Authentication Scheme Registry |  | 5.1. Authentication Scheme Registry |
| The registration procedure for HTTP Authentication Schemes is defined |  | The HTTP Authentication Scheme Registry defines the name space for |
| by Section 2.3 of this document. |  | the authentication schemes in challenges and credentials. It will be |
|  |  | created and maintained at |
| The HTTP Method Authentication Scheme shall be created at |  |  |
| <http://www.iana.org/assignments/http-authschemes>. |  | <http://www.iana.org/assignments/http-authschemes>. |
|  |  | 5.1.1. Procedure |
|  |  | Registrations MUST include the following fields: |
|  |  | o Authentication Scheme Name |
|  |  | o Pointer to specification text |
|  |  | o Notes (optional) |
|  |  | Values to be added to this name space require IETF Review (see |
|  |  | [RFC5226], Section 4.1). |
|  |  | 5.1.2. Considerations for New Authentication Schemes |
|  |  | There are certain aspects of the HTTP Authentication Framework that |
|  |  | put constraints on how new authentication schemes can work: |
|  |  | o HTTP authentication is presumed to be stateless: all of the |
|  |  | information necessary to authenticate a request MUST be provided |
|  |  | in the request, rather than be dependent on the server remembering |
|  |  | prior requests. Authentication based on, or bound to, the |
|  |  | underlying connection is outside the scope of this specification |
|  |  | and inherently flawed unless steps are taken to ensure that the |
|  |  | connection cannot be used by any party other than the |
|  |  | authenticated user (see Section 2.3 of [Part1]). |
|  |  | o The authentication parameter "realm" is reserved for defining |
|  |  | Protection Spaces as defined in Section 2.2. New schemes MUST NOT |
|  |  | use it in a way incompatible with that definition. |
|  |  | o The "token68" notation was introduced for compatibility with |
|  |  | existing authentication schemes and can only be used once per |
|  |  | challenge or credential. New schemes thus ought to use the "auth- |
|  |  | param" syntax instead, because otherwise future extensions will be |
|  |  | impossible. |
|  |  | o The parsing of challenges and credentials is defined by this |
|  |  | specification, and cannot be modified by new authentication |
|  |  | schemes. When the auth-param syntax is used, all parameters ought |
|  |  | to support both token and quoted-string syntax, and syntactical |
|  |  | constraints ought to be defined on the field value after parsing |
|  |  | (i.e., quoted-string processing). This is necessary so that |
|  |  | recipients can use a generic parser that applies to all |
|  |  | authentication schemes. |
|  |  | Note: The fact that the value syntax for the "realm" parameter is |
|  |  | restricted to quoted-string was a bad design choice not to be |
|  |  | repeated for new parameters. |
|  |  | o Definitions of new schemes ought to define the treatment of |
|  |  | unknown extension parameters. In general, a "must-ignore" rule is |
|  |  | preferable over "must-understand", because otherwise it will be |
|  |  | hard to introduce new parameters in the presence of legacy |
|  |  | recipients. Furthermore, it's good to describe the policy for |
|  |  | defining new parameters (such as "update the specification", or |
|  |  | "use this registry"). |
|  |  | o Authentication schemes need to document whether they are usable in |
|  |  | origin-server authentication (i.e., using WWW-Authenticate), |
|  |  | and/or proxy authentication (i.e., using Proxy-Authenticate). |
|  |  | o The credentials carried in an Authorization header field are |
|  |  | specific to the User Agent, and therefore have the same effect on |
|  |  | HTTP caches as the "private" Cache-Control response directive |
|  |  | (Section 7.2.2.6 of [Part6]), within the scope of the request they |
|  |  | appear in. |
|  |  | Therefore, new authentication schemes that choose not to carry |
|  |  | credentials in the Authorization header field (e.g., using a newly |
|  |  | defined header field) will need to explicitly disallow caching, by |
|  |  | mandating the use of either Cache-Control request directives |
|  |  | (e.g., "no-store", Section 7.2.1.5 of [Part6]) or response |
|  |  | 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 | |
| +-------+-------------------------------+-------------+ |  | +-------+-------------------------------+-------------+ |
| | 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/ |  | HTTP header fields are registered within the Message Header Field |
| assignments/message-headers/message-header-index.html> shall be |  | Registry maintained at <http://www.iana.org/assignments/ |
| updated with the permanent registrations below (see [BCP90]): |  | message-headers/message-header-index.html>. |
|  |  | This document defines the following HTTP header fields, so their |
|  |  | associated registry entries shall be updated according to 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 | |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| skipping to change at page 13, line 18 |  | skipping to change at page 13, line 22 |
| password protection in screen savers, idle time-outs, and other |  | password protection in screen savers, idle time-outs, and other |
| methods that mitigate the security problems inherent in this problem. |  | methods that mitigate the security problems inherent in this problem. |
| In particular, user agents that cache credentials are encouraged to |  | In particular, user agents that cache credentials are encouraged to |
| provide a readily accessible mechanism for discarding cached |  | provide a readily accessible mechanism for discarding 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 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 server. |  | authentication credentials for other resources on the same origin |
| 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. |
| This is of particular concern when a server hosts resources for |  | This is of particular concern when an origin server hosts resources |
| multiple parties under the same canonical root URI (Section 2.2). |  | for multiple parties under the same canonical root URI (Section 2.2). |
| Possible mitigation strategies include restricting direct access to |  | Possible mitigation strategies include restricting direct access to |
| authentication credentials (i.e., not making the content of the |  | authentication credentials (i.e., not making the content of the |
| Authorization request header field available), and separating |  | Authorization request header field available), and separating |
| protection spaces by using a different host name for each party. |  | protection spaces by using a different host name (or port number) for |
|  |  | each party. |
| 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. |
| skipping to change at page 13, line 44 |  | skipping to change at page 14, line 4 |
| 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 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-22 (work in progress), |  | draft-ietf-httpbis-p1-messaging-23 (work in progress), |
| February 2013. |  | July 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-22 (work in progress), |  | draft-ietf-httpbis-p2-semantics-23 (work in progress), |
| February 2013. |  | July 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-22 (work in progress), |  | draft-ietf-httpbis-p6-cache-23 (work in progress), |
| February 2013. |  | July 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 15, line 13 |  | skipping to change at page 15, line 20 |
| The "realm" parameter is no longer always required on challenges; |  | 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) |
| This specification introduces the Authentication Scheme Registry, |  | This specification introduces the Authentication Scheme Registry, |
| along with considerations for new authentication schemes. |  | along with considerations for new authentication schemes. |
| (Section 2.3) |  | (Section 5.1) |
| 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.3> |  | BWS = <BWS, defined in [Part1], Section 3.2.3> |
| OWS = <OWS, defined in [Part1], Section 3.2.3> |  | OWS = <OWS, defined in [Part1], Section 3.2.3> |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> |
| token = <token, defined in [Part1], Section 3.2.6> |  | token = <token, defined in [Part1], Section 3.2.6> |
| Appendix C. Collected ABNF |  | Appendix C. Collected ABNF |
|  |  | In the collected ABNF below, list rules are expanded as per Section |
|  |  | 1.2 of [Part1]. |
| Authorization = credentials |  | Authorization = credentials |
| BWS = <BWS, defined in [Part1], Section 3.2.3> |  | BWS = <BWS, defined in [Part1], Section 3.2.3> |
| OWS = <OWS, defined in [Part1], Section 3.2.3> |  | 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 |
| skipping to change at page 17, line 30 |  | skipping to change at page 17, line 27 |
| 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 |  | D.3. Since draft-ietf-httpbis-p7-auth-21 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>: |
| "Authentication and caching - max-age" |  | "Authentication and caching - max-age" |
|  |  | D.4. Since draft-ietf-httpbis-p7-auth-22 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list |
|  |  | expansion in ABNF appendices" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology: |
|  |  | mechanism vs framework vs scheme" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial |
|  |  | suggestions" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of |
|  |  | extension point considerations" |
| Index |  | Index |
| 4 |  | 4 |
| 401 Unauthorized (status code) 9 |  | 401 Unauthorized (status code) 7 |
| 407 Proxy Authentication Required (status code) 9 |  | 407 Proxy Authentication Required (status code) 7 |
| A |  | A |
| Authorization header field 9 |  | 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 9 |  | Authorization 8 |
| challenge 5 |  | challenge 5 |
| credentials 6 |  | credentials 6 |
| Proxy-Authenticate 10 |  | Proxy-Authenticate 8 |
| Proxy-Authorization 10 |  | Proxy-Authorization 8 |
| token68 5 |  | token68 5 |
| WWW-Authenticate 11 |  | WWW-Authenticate 9 |
| P |  | P |
| Protection Space 6 |  | Protection Space 6 |
| Proxy-Authenticate header field 10 |  | Proxy-Authenticate header field 8 |
| Proxy-Authorization header field 10 |  | Proxy-Authorization header field 8 |
| R |  | R |
| Realm 6 |  | Realm 6 |
| W |  | W |
| WWW-Authenticate header field 10 |  | WWW-Authenticate header field 9 |
| 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. 42 change blocks.
| 152 lines changed or deleted |  | 171 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/