| draft-ietf-httpbis-p7-auth-11.txt |  | draft-ietf-httpbis-p7-auth-12.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Updates: 2617 (if approved) Alcatel-Lucent |  | Updates: 2617 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: February 5, 2011 HP |  | Expires: April 28, 2011 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| August 4, 2010 |  | October 25, 2010 |
| HTTP/1.1, part 7: Authentication |  | HTTP/1.1, part 7: Authentication |
| draft-ietf-httpbis-p7-auth-11 |  | draft-ietf-httpbis-p7-auth-12 |
| 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. HTTP has been in use by the World Wide Web global |  | systems. HTTP has been in use by the World Wide Web global |
| information initiative since 1990. This document is Part 7 of the |  | information initiative since 1990. This document is Part 7 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines |
| HTTP Authentication. |  | HTTP Authentication. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | at <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 B.12. |  | The changes in this draft are summarized in Appendix B.13. |
| 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 February 5, 2011. |  | This Internet-Draft will expire on April 28, 2011. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 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 |
| skipping to change at page 3, line 10 |  | skipping to change at page 3, line 10 |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |  | it for publication as an RFC or to translate it into languages other |
| than English. |  | than English. |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |  | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 4 |
| 1.2.2. ABNF Rules defined in other Parts of the |  | 2. Access Authentication Framework . . . . . . . . . . . . . . . 5 |
| Specification . . . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Authentication Scheme Registry . . . . . . . . . . . . . . 7 |
| 2. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 |
| 2.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 5 |  | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7 |
| 2.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5 |  | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 8 |
| 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 |  | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 |
| 3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 6 |  | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 |
| 3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 |  | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 9 |
| 3.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 7 |  | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 9 |
| 3.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 |  | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 10 |
| 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 |
| 4.1. Status Code Registration . . . . . . . . . . . . . . . . . 8 |  | 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 10 |
| 4.2. Header Field Registration . . . . . . . . . . . . . . . . 8 |  | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 10 |
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 |  | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 10 |
| 5.1. Authentication Credentials and Idle Clients . . . . . . . 9 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 |
| 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 6.1. Authentication Credentials and Idle Clients . . . . . . . 11 |
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |
| 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 |
| Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 10 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 |
|  |  | Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 13 |
| Appendix B. Change Log (to be removed by RFC Editor before |  | Appendix B. Change Log (to be removed by RFC Editor before |
| publication) . . . . . . . . . . . . . . . . . . . . 11 |  | publication) . . . . . . . . . . . . . . . . . . . . 14 |
| B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 11 |  | B.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 14 |
| B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 11 |  | B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 14 |
| B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 11 |  | B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 14 |
| B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 11 |  | B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 14 |
| B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 11 |  | B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 14 |
| B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 11 |  | B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 14 |
| B.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 12 |  | B.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 15 |
| B.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 12 |  | B.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 15 |
| B.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 12 |  | B.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 15 |
| B.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 12 |  | B.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 15 |
| B.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 12 |  | B.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 15 |
| B.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 12 |  | B.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 15 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 |  | B.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 15 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 access control and authentication. |  | This document defines HTTP/1.1 access control and authentication. It |
| Right now it includes the extracted relevant sections of RFC 2616 |  | includes the relevant parts of RFC 2616 with only minor changes, plus |
| with only minor changes. The intention is to move the general |  | the general framework for HTTP authentication, as previously defined |
| framework for HTTP authentication here, as currently specified in |  | in "HTTP Authentication: Basic and Digest Access Authentication" |
| [RFC2617], and allow the individual authentication mechanisms to be |  | ([RFC2617]). |
| defined elsewhere. This introduction will be rewritten when that |  |  |
| occurs. |  |  |
| 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 which can be used by a server to challenge a client |
| request and by a client to provide authentication information. The |  | request and by a client to provide authentication information. The |
| general framework for access authentication, and the specification of |  | "basic" and "digest" authentication schemes continue to be specified |
| "basic" and "digest" authentication, are specified in "HTTP |  | in RFC 2617. |
| Authentication: Basic and Digest Access Authentication" [RFC2617]. |  |  |
| This specification adopts the definitions of "challenge" and |  |  |
| "credentials" from that specification. |  |  |
| 1.1. Requirements |  | 1.1. Requirements |
| 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]. |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the "MUST" or "REQUIRED" level requirements for the protocols it |  | of the "MUST" or "REQUIRED" level requirements for the protocols it |
| implements. An implementation that satisfies all the "MUST" or |  | implements. An implementation that satisfies all the "MUST" or |
| skipping to change at page 5, line 9 |  | skipping to change at page 5, line 5 |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| sequence of data), SP (space), VCHAR (any visible USASCII character), |  | sequence of data), SP (space), VCHAR (any visible USASCII character), |
| and WSP (whitespace). |  | and WSP (whitespace). |
| 1.2.1. Core Rules |  | 1.2.1. Core Rules |
| The core rules below are defined in Section 1.2.2 of [Part1]: |  | The core rules below are defined in Section 1.2.2 of [Part1]: |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
|  |  | token = <token, defined in [Part1], Section 1.2.2> |
|  |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| 1.2.2. ABNF Rules defined in other Parts of the Specification |  | 2. Access Authentication Framework |
| The ABNF rules below are defined in other specifications: |  | HTTP provides a simple challenge-response authentication mechanism |
|  |  | that can be used by a server to challenge a client request and by a |
|  |  | client to provide authentication information. It uses an extensible, |
|  |  | case-insensitive token to identify the authentication scheme, |
|  |  | followed by a comma-separated list of attribute-value pairs which |
|  |  | carry the parameters necessary for achieving authentication via that |
|  |  | scheme. |
| challenge = <challenge, defined in [RFC2617], Section 1.2> |  | auth-scheme = token |
| credentials = <credentials, defined in [RFC2617], Section 1.2> |  | auth-param = token "=" ( token / quoted-string ) |
| 2. Status Code Definitions |  | The 401 (Unauthorized) response message is used by an origin server |
|  |  | to challenge the authorization of a user agent. This response MUST |
|  |  | include a WWW-Authenticate header field containing at least one |
|  |  | challenge applicable to the requested resource. The 407 (Proxy |
|  |  | Authentication Required) response message is used by a proxy to |
|  |  | challenge the authorization of a client and MUST include a Proxy- |
|  |  | Authenticate header field containing at least one challenge |
|  |  | applicable to the proxy for the requested resource. |
| 2.1. 401 Unauthorized |  | challenge = auth-scheme 1*SP 1#auth-param |
|  |  | Note: User agents will need to take special care in parsing the |
|  |  | WWW-Authenticate or Proxy-Authenticate header field value if it |
|  |  | contains more than one challenge, or if more than one WWW- |
|  |  | Authenticate header field is provided, since the contents of a |
|  |  | challenge can itself contain a comma-separated list of |
|  |  | authentication parameters. |
|  |  | Note: Many browsers fail to parse challenges containing unknown |
|  |  | schemes. A workaround for this problem is to list well-supported |
|  |  | schemes (such as "basic") first. |
|  |  | The authentication parameter realm is defined for all authentication |
|  |  | schemes: |
|  |  | realm = "realm" "=" realm-value |
|  |  | realm-value = quoted-string |
|  |  | The realm directive (case-insensitive) is required for all |
|  |  | authentication schemes that issue a challenge. The realm value |
|  |  | (case-sensitive), in combination with the canonical root URI (the |
|  |  | scheme and authority components of the effective request URI; see |
|  |  | Section 4.3 of [Part1]) of the server being accessed, defines the |
|  |  | protection space. These realms allow the protected resources on a |
|  |  | server to be partitioned into a set of protection spaces, each with |
|  |  | its own authentication scheme and/or authorization database. The |
|  |  | realm value is a string, generally assigned by the origin server, |
|  |  | which can have additional semantics specific to the authentication |
|  |  | scheme. Note that there can be multiple challenges with the same |
|  |  | auth-scheme but different realms. |
|  |  | A user agent that wishes to authenticate itself with an origin server |
|  |  | -- usually, but not necessarily, after receiving a 401 (Unauthorized) |
|  |  | -- MAY do so by including an Authorization header field with the |
|  |  | request. A client that wishes to authenticate itself with a proxy -- |
|  |  | usually, but not necessarily, after receiving a 407 (Proxy |
|  |  | Authentication Required) -- MAY do so by including a Proxy- |
|  |  | Authorization header field with the request. Both the Authorization |
|  |  | field value and the Proxy-Authorization field value consist of |
|  |  | credentials containing the authentication information of the client |
|  |  | for the realm of the resource being requested. The user agent MUST |
|  |  | choose to use one of the challenges with the strongest auth-scheme it |
|  |  | understands and request credentials from the user based upon that |
|  |  | challenge. |
|  |  | credentials = auth-scheme ( token |
|  |  | / quoted-string |
|  |  | / #auth-param ) |
|  |  | The protection space determines the domain over which credentials can |
|  |  | be automatically applied. If a prior request has been authorized, |
|  |  | the same credentials MAY be reused for all other requests within that |
|  |  | protection space for a period of time determined by the |
|  |  | authentication scheme, parameters, and/or user preference. Unless |
|  |  | otherwise defined by the authentication scheme, a single protection |
|  |  | space cannot extend outside the scope of its server. |
|  |  | If the origin server does not wish to accept the credentials sent |
|  |  | with a request, it SHOULD return a 401 (Unauthorized) response. The |
|  |  | response MUST include a WWW-Authenticate header field containing at |
|  |  | least one (possibly new) challenge applicable to the requested |
|  |  | resource. If a proxy does not accept the credentials sent with a |
|  |  | request, it SHOULD return a 407 (Proxy Authentication Required). The |
|  |  | response MUST include a Proxy-Authenticate header field containing a |
|  |  | (possibly new) challenge applicable to the proxy for the requested |
|  |  | resource. |
|  |  | The HTTP protocol does not restrict applications to this simple |
|  |  | challenge-response mechanism for access authentication. Additional |
|  |  | mechanisms MAY be used, such as encryption at the transport level or |
|  |  | via message encapsulation, and with additional header fields |
|  |  | specifying authentication information. However, these additional |
|  |  | mechanisms are not defined by this specification. |
|  |  | Proxies MUST be completely transparent regarding user agent |
|  |  | authentication by origin servers. That is, they MUST forward the |
|  |  | WWW-Authenticate and Authorization headers untouched, and follow the |
|  |  | rules found in Section 4.1. Both the Proxy-Authenticate and the |
|  |  | Proxy-Authorization header fields are hop-by-hop headers (see Section |
|  |  | 7.1.3.1 of [Part1]). |
|  |  | 2.1. 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 |
|  |  | Values to be added to this name space are subject to IETF review |
|  |  | ([RFC5226], Section 4.1). |
|  |  | The registry itself is maintained at |
|  |  | <http://www.iana.org/assignments/http-authschemes>. |
|  |  | 3. Status Code Definitions |
|  |  | 3.1. 401 Unauthorized |
| The request requires user authentication. The response MUST include |  | The request requires user authentication. The response MUST include |
| a WWW-Authenticate header field (Section 3.4) containing a challenge |  | a WWW-Authenticate header field (Section 4.4) containing a challenge |
| applicable to the target resource. The client MAY repeat the request |  | applicable to the target resource. The client MAY repeat the request |
| with a suitable Authorization header field (Section 3.1). If the |  | with a suitable Authorization header field (Section 4.1). If the |
| request already included Authorization credentials, then the 401 |  | request already included Authorization credentials, then the 401 |
| response indicates that authorization has been refused for those |  | response indicates that authorization has been refused for those |
| credentials. If the 401 response contains the same challenge as the |  | credentials. If the 401 response contains the same challenge as the |
| prior response, and the user agent has already attempted |  | prior response, and the user agent has already attempted |
| authentication at least once, then the user SHOULD be presented the |  | authentication at least once, then the user SHOULD be presented the |
| representation that was given in the response, since that |  | representation that was given in the response, since that |
| representation might include relevant diagnostic information. HTTP |  | representation might include relevant diagnostic information. |
| access authentication is explained in "HTTP Authentication: Basic and |  |  |
| Digest Access Authentication" [RFC2617]. |  |  |
| 2.2. 407 Proxy Authentication Required |  | 3.2. 407 Proxy Authentication Required |
| This code is similar to 401 (Unauthorized), but indicates that the |  | This code is similar to 401 (Unauthorized), but indicates that the |
| client must first authenticate itself with the proxy. The proxy MUST |  | client ought to first authenticate itself with the proxy. The proxy |
| return a Proxy-Authenticate header field (Section 3.2) containing a |  | MUST return a Proxy-Authenticate header field (Section 4.2) |
| challenge applicable to the proxy for the target resource. The |  | containing a challenge applicable to the proxy for the target |
| client MAY repeat the request with a suitable Proxy-Authorization |  | resource. The client MAY repeat the request with a suitable Proxy- |
| header field (Section 3.3). HTTP access authentication is explained |  | Authorization header field (Section 4.3). |
| in "HTTP Authentication: Basic and Digest Access Authentication" |  |  |
| [RFC2617]. |  |  |
| 3. 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. |
| 3.1. Authorization |  | 4.1. Authorization |
| The "Authorization" request-header field allows a user agent to |  | The "Authorization" request-header field allows a user agent to |
| authenticate itself with a server -- usually, but not necessarily, |  | authenticate itself with a server -- usually, but not necessarily, |
| after receiving a 401 (Unauthorized) response. Its value consists of |  | after receiving a 401 (Unauthorized) response. Its value consists of |
| credentials containing information of the user agent for the realm of |  | credentials containing information of the user agent for the realm of |
| the resource being requested. |  | the resource being requested. |
| Authorization = "Authorization" ":" OWS Authorization-v |  | Authorization = "Authorization" ":" OWS Authorization-v |
| Authorization-v = credentials |  | Authorization-v = credentials |
| HTTP access authentication is described in "HTTP Authentication: |  | If a request is authenticated and a realm specified, the same |
| Basic and Digest Access Authentication" [RFC2617]. If a request is |  | credentials SHOULD be valid for all other requests within this realm |
| authenticated and a realm specified, the same credentials SHOULD be |  | (assuming that the authentication scheme itself does not require |
| valid for all other requests within this realm (assuming that the |  | otherwise, such as credentials that vary according to a challenge |
| authentication scheme itself does not require otherwise, such as |  | value or using synchronized clocks). |
| credentials that vary according to a challenge value or using |  |  |
| synchronized clocks). |  |  |
| When a shared cache (see Section 1.2 of [Part6]) receives a request |  | When a shared cache (see Section 1.2 of [Part6]) receives a request |
| containing an Authorization field, it MUST NOT return the |  | containing an Authorization field, it MUST NOT return the |
| corresponding response as a reply to any other request, unless one of |  | corresponding response as a reply to any other request, unless one of |
| the following specific exceptions holds: |  | the following specific exceptions holds: |
| 1. If the response includes the "s-maxage" cache-control directive, |  | 1. If the response includes the "s-maxage" cache-control directive, |
| the cache MAY use that response in replying to a subsequent |  | the cache MAY use that response in replying to a subsequent |
| request. But (if the specified maximum age has passed) a proxy |  | request. But (if the specified maximum age has passed) a proxy |
| cache MUST first revalidate it with the origin server, using the |  | cache MUST first revalidate it with the origin server, using the |
| request-headers from the new request to allow the origin server |  | request-header fields from the new request to allow the origin |
| to authenticate the new request. (This is the defined behavior |  | server to authenticate the new request. (This is the defined |
| for s-maxage.) If the response includes "s-maxage=0", the proxy |  | behavior for s-maxage.) If the response includes "s-maxage=0", |
| MUST always revalidate it before re-using it. |  | the proxy MUST always revalidate it before re-using it. |
| 2. If the response includes the "must-revalidate" cache-control |  | 2. If the response includes the "must-revalidate" cache-control |
| directive, the cache MAY use that response in replying to a |  | directive, the cache MAY use that response in replying to a |
| subsequent request. But if the response is stale, all caches |  | subsequent request. But if the response is stale, all caches |
| MUST first revalidate it with the origin server, using the |  | MUST first revalidate it with the origin server, using the |
| request-headers from the new request to allow the origin server |  | request-header fields from the new request to allow the origin |
| to authenticate the new request. |  | server to authenticate the new request. |
| 3. If the response includes the "public" cache-control directive, it |  | 3. If the response includes the "public" cache-control directive, it |
| MAY be returned in reply to any subsequent request. |  | MAY be returned in reply to any subsequent request. |
| 3.2. Proxy-Authenticate |  | 4.2. Proxy-Authenticate |
| The "Proxy-Authenticate" response-header field consists of a |  | The "Proxy-Authenticate" response-header field consists of a |
| challenge that indicates the authentication scheme and parameters |  | challenge that indicates the authentication scheme and parameters |
| applicable to the proxy for this effective request URI (Section 4.3 |  | applicable to the proxy for this effective request URI (Section 4.3 |
| 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 = "Proxy-Authenticate" ":" OWS |  | Proxy-Authenticate = "Proxy-Authenticate" ":" OWS |
| Proxy-Authenticate-v |  | Proxy-Authenticate-v |
| Proxy-Authenticate-v = 1#challenge |  | Proxy-Authenticate-v = 1#challenge |
| The HTTP access authentication process is described in "HTTP |  |  |
| Authentication: Basic and Digest Access Authentication" [RFC2617]. |  |  |
| Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |  | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |
| only to the current connection and SHOULD NOT be passed on to |  | only to the current connection and SHOULD NOT be passed on to |
| downstream clients. However, an intermediate proxy might need to |  | downstream clients. However, an intermediate proxy might need to |
| obtain its own credentials by requesting them from the downstream |  | 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. |
| 3.3. Proxy-Authorization |  | 4.3. Proxy-Authorization |
| The "Proxy-Authorization" request-header field allows the client to |  | The "Proxy-Authorization" request-header field allows the client to |
| identify itself (or its user) to a proxy which requires |  | identify itself (or its user) to a proxy which requires |
| authentication. Its value consists of credentials containing the |  | authentication. Its value consists of credentials containing the |
| authentication information of the user agent for the proxy and/or |  | authentication information of the user agent for the proxy and/or |
| realm of the resource being requested. |  | realm of the resource being requested. |
| Proxy-Authorization = "Proxy-Authorization" ":" OWS |  | Proxy-Authorization = "Proxy-Authorization" ":" OWS |
| Proxy-Authorization-v |  | Proxy-Authorization-v |
| Proxy-Authorization-v = credentials |  | Proxy-Authorization-v = credentials |
| The HTTP access authentication process is described in "HTTP |  |  |
| Authentication: Basic and Digest Access Authentication" [RFC2617]. |  |  |
| 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 |
| authenticate a given request. |  | authenticate a given request. |
| 3.4. WWW-Authenticate |  | 4.4. WWW-Authenticate |
| The "WWW-Authenticate" response-header field consists of at least one |  | The "WWW-Authenticate" response-header field consists of at least one |
| challenge that indicates the authentication scheme(s) and parameters |  | challenge that indicates the authentication scheme(s) and parameters |
| applicable to the effective request URI (Section 4.3 of [Part1]). It |  | applicable to the effective request URI (Section 4.3 of [Part1]). It |
| MUST be included in 401 (Unauthorized) response messages. |  | MUST be included in 401 (Unauthorized) response messages. |
| WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v |  | WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v |
| WWW-Authenticate-v = 1#challenge |  | WWW-Authenticate-v = 1#challenge |
| The HTTP access authentication process is described in "HTTP |  |  |
| Authentication: Basic and Digest Access Authentication" [RFC2617]. |  |  |
| User agents are advised to take special care in parsing the WWW- |  | User agents are advised to take special care in parsing the WWW- |
| Authenticate field value as it might contain more than one challenge, |  | Authenticate field value as it might contain more than one challenge, |
| or if more than one WWW-Authenticate header field is provided, the |  | or if more than one WWW-Authenticate header field is provided, the |
| contents of a challenge itself can contain a comma-separated list of |  | contents of a challenge itself can contain a comma-separated list of |
| authentication parameters. |  | authentication parameters. |
| 4. IANA Considerations |  | 5. IANA Considerations |
| 4.1. Status Code Registration |  | 5.1. Authenticaton Scheme Registry |
|  |  | The registration procedure for HTTP Authentication Schemes is defined |
|  |  | by Section 2.1 of this document. |
|  |  | The HTTP Method Authentication Scheme shall be created at |
|  |  | <http://www.iana.org/assignments/http-authschemes>. |
|  |  | 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 2.1 | |  | | 401 | Unauthorized | Section 3.1 | |
| | 407 | Proxy Authentication Required | Section 2.2 | |  | | 407 | Proxy Authentication Required | Section 3.2 | |
| +-------+-------------------------------+-------------+ |  | +-------+-------------------------------+-------------+ |
| 4.2. 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 [RFC3864]): |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| | Header Field Name | Protocol | Status | Reference | |  | | Header Field Name | Protocol | Status | Reference | |
| +---------------------+----------+----------+-------------+ |  | +---------------------+----------+----------+-------------+ |
| | Authorization | http | standard | Section 3.1 | |  | | Authorization | http | standard | Section 4.1 | |
| | Proxy-Authenticate | http | standard | Section 3.2 | |  | | Proxy-Authenticate | http | standard | Section 4.2 | |
| | Proxy-Authorization | http | standard | Section 3.3 | |  | | Proxy-Authorization | http | standard | Section 4.3 | |
| | WWW-Authenticate | http | standard | Section 3.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". |
| 5. Security Considerations |  | 6. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 5.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 which 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 reprompt the |
| skipping to change at page 9, line 31 |  | skipping to change at page 12, line 5 |
| 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 which mitigate the security problems inherent in this |
| problem. In particular, user agents which cache credentials are |  | problem. In particular, user agents which cache credentials are |
| encouraged to provide a readily accessible mechanism for discarding |  | encouraged to provide a readily accessible mechanism for discarding |
| cached credentials under user control. |  | cached credentials under user control. |
| 6. Acknowledgments |  | 7. Acknowledgments |
| [[acks: TBD.]] |  | This specification takes over the definition of the HTTP |
|  |  | Authentication Framework, previously defined in RFC 2617. We thank |
|  |  | to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott |
|  |  | D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for |
|  |  | their work on that specification. |
| 7. References |  | [[acks: HTTPbis acknowledgements.]] |
| 7.1. Normative References |  | 8. References |
|  |  | 8.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-11 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-12 |
| (work in progress), August 2010. |  | (work in progress), October 2010. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-11 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-12 (work in |
| progress), August 2010. |  | progress), October 2010. |
| [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. |
| [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |  |  |
| Leach, P., Luotonen, A., and L. Stewart, "HTTP |  |  |
| Authentication: Basic and Digest Access Authentication", |  |  |
| RFC 2617, June 1999. |  |  |
| [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. |
| 7.2. Informative References |  | 8.2. Informative References |
| [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., |
|  |  | Leach, P., Luotonen, A., and L. Stewart, "HTTP |
|  |  | Authentication: Basic and Digest Access Authentication", |
|  |  | RFC 2617, June 1999. |
| [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |  | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
| Procedures for Message Header Fields", BCP 90, RFC 3864, |  | Procedures for Message Header Fields", BCP 90, RFC 3864, |
| September 2004. |  | September 2004. |
|  |  | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
|  |  | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
|  |  | May 2008. |
| Appendix A. Collected ABNF |  | Appendix A. Collected ABNF |
| Authorization = "Authorization:" OWS Authorization-v |  | Authorization = "Authorization:" OWS Authorization-v |
| Authorization-v = credentials |  | Authorization-v = credentials |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v |  | Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v |
| Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS |  | Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS |
| challenge ] ) |  | challenge ] ) |
| Proxy-Authorization = "Proxy-Authorization:" OWS |  | Proxy-Authorization = "Proxy-Authorization:" OWS |
| Proxy-Authorization-v |  | Proxy-Authorization-v |
| Proxy-Authorization-v = credentials |  | Proxy-Authorization-v = credentials |
| WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v |  | WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v |
| WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS |  | WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS |
| challenge ] ) |  | challenge ] ) |
| challenge = <challenge, defined in [RFC2617], Section 1.2> |  | auth-param = token "=" ( token / quoted-string ) |
| credentials = <credentials, defined in [RFC2617], Section 1.2> |  | auth-scheme = token |
|  |  | challenge = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS |
|  |  | auth-param ] ) |
|  |  | credentials = auth-scheme ( token / quoted-string / [ ( "," / |
|  |  | auth-param ) *( OWS "," [ OWS auth-param ] ) ] ) |
|  |  | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
|  |  | realm = "realm=" realm-value |
|  |  | realm-value = quoted-string |
|  |  | token = <token, defined in [Part1], Section 1.2.2> |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Authorization defined but not used |  | ; Authorization defined but not used |
| ; Proxy-Authenticate defined but not used |  | ; Proxy-Authenticate defined but not used |
| ; Proxy-Authorization defined but not used |  | ; Proxy-Authorization defined but not used |
| ; WWW-Authenticate defined but not used |  | ; WWW-Authenticate defined but not used |
|  |  | ; realm defined but not used |
| Appendix B. Change Log (to be removed by RFC Editor before publication) |  | Appendix B. Change Log (to be removed by RFC Editor before publication) |
| B.1. Since RFC2616 |  | B.1. Since RFC 2616 |
| Extracted relevant partitions from [RFC2616]. |  | Extracted relevant partitions from [RFC2616]. |
| B.2. Since draft-ietf-httpbis-p7-auth-00 |  | B.2. Since draft-ietf-httpbis-p7-auth-00 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |
| Informative references" |  | Informative references" |
| skipping to change at page 11, line 31 |  | skipping to change at page 14, line 31 |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Explicitly import BNF rules for "challenge" and "credentials" from |  | o Explicitly import BNF rules for "challenge" and "credentials" from |
| RFC2617. |  | RFC2617. |
| o Add explicit references to BNF syntax and rules imported from |  | o Add explicit references to BNF syntax and rules imported from |
| other parts of the specification. |  | other parts of the specification. |
| B.4. Since draft-ietf-httpbis-p7-auth-02 |  | B.4. Since draft-ietf-httpbis-p7-auth-02 |
| Ongoing work on IANA Message Header Registration |  | Ongoing work on IANA Message Header Field Registration |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
| o Reference RFC 3984, and update header registrations for headers |  | o Reference RFC 3984, and update header field registrations for |
| defined in this document. |  | header fields defined in this document. |
| B.5. Since draft-ietf-httpbis-p7-auth-03 |  | B.5. Since draft-ietf-httpbis-p7-auth-03 |
| B.6. Since draft-ietf-httpbis-p7-auth-04 |  | B.6. Since draft-ietf-httpbis-p7-auth-04 |
| Ongoing work on ABNF conversion |  | Ongoing work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Use "/" instead of "|" for alternatives. |  | o Use "/" instead of "|" for alternatives. |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
| whitespace ("OWS") and required whitespace ("RWS"). |  | whitespace ("OWS") and required whitespace ("RWS"). |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  | o Rewrite ABNFs to spell out whitespace rules, factor out header |
| value format definitions. |  | field value format definitions. |
| B.7. Since draft-ietf-httpbis-p7-auth-05 |  | B.7. Since draft-ietf-httpbis-p7-auth-05 |
| Final work on ABNF conversion |  | Final work on ABNF conversion |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
| o Add appendix containing collected and expanded ABNF, reorganize |  | o Add appendix containing collected and expanded ABNF, reorganize |
| ABNF introduction. |  | ABNF introduction. |
| B.8. Since draft-ietf-httpbis-p7-auth-06 |  | B.8. Since draft-ietf-httpbis-p7-auth-06 |
| skipping to change at page 12, line 39 |  | skipping to change at page 15, line 39 |
| Partly resolved issues: |  | Partly resolved issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
| requested resource's URI" |  | requested resource's URI" |
| B.12. Since draft-ietf-httpbis-p7-auth-10 |  | B.12. Since draft-ietf-httpbis-p7-auth-10 |
| None yet. |  | None yet. |
|  |  | B.13. Since draft-ietf-httpbis-p7-auth-11 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/130>: "introduction |
|  |  | to part 7 is work-in-progress" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param |
|  |  | syntax" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/237>: "absorbing the |
|  |  | auth framework from 2617" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/141>: "should we |
|  |  | have an auth scheme registry" |
| Index |  | Index |
| 4 |  | 4 |
| 401 Unauthorized (status code) 5 |  | 401 Unauthorized (status code) 7 |
| 407 Proxy Authentication Required (status code) 5 |  | 407 Proxy Authentication Required (status code) 8 |
| A |  | A |
| Authorization header 6 |  | auth-param 5 |
|  |  | auth-scheme 5 |
|  |  | Authorization header 8 |
|  |  | C |
|  |  | challenge 5 |
|  |  | credentials 6 |
| G |  | G |
| Grammar |  | Grammar |
| Authorization 6 |  | Authorization 8 |
| Authorization-v 6 |  | Authorization-v 8 |
| challenge 5 |  | Proxy-Authenticate 9 |
| credentials 5 |  | Proxy-Authenticate-v 9 |
| Proxy-Authenticate 7 |  | Proxy-Authorization 9 |
| Proxy-Authenticate-v 7 |  | Proxy-Authorization-v 9 |
| Proxy-Authorization 7 |  | WWW-Authenticate 10 |
| Proxy-Authorization-v 7 |  | WWW-Authenticate-v 10 |
| WWW-Authenticate 7 |  |  |
| WWW-Authenticate-v 7 |  |  |
| H |  | H |
| Headers |  | Headers |
| Authorization 6 |  | Authorization 8 |
| Proxy-Authenticate 6 |  | Proxy-Authenticate 9 |
| Proxy-Authorization 7 |  | Proxy-Authorization 9 |
| WWW-Authenticate 7 |  | WWW-Authenticate 10 |
| P |  | P |
| Proxy-Authenticate header 6 |  | Proxy-Authenticate header 9 |
| Proxy-Authorization header 7 |  | Proxy-Authorization header 9 |
|  |  | R |
|  |  | realm 5 |
|  |  | realm-value 5 |
| S |  | S |
| Status Codes |  | Status Codes |
| 401 Unauthorized 5 |  | 401 Unauthorized 7 |
| 407 Proxy Authentication Required 5 |  | 407 Proxy Authentication Required 8 |
| W |  | W |
| WWW-Authenticate header 7 |  | WWW-Authenticate header 10 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
End of changes. 62 change blocks.
| 150 lines changed or deleted |  | 308 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/