| draft-ietf-httpbis-p7-auth-19.txt |  | draft-ietf-httpbis-p7-auth-20.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) Y. Lafon, Ed. |  | Obsoletes: 2616 (if approved) Y. Lafon, Ed. |
| Updates: 2617 (if approved) W3C |  | Updates: 2617 (if approved) W3C |
| Intended status: Standards Track J. Reschke, Ed. |  | Intended status: Standards Track J. Reschke, Ed. |
| Expires: September 13, 2012 greenbytes |  | Expires: January 17, 2013 greenbytes |
| March 12, 2012 |  | July 16, 2012 |
| HTTP/1.1, part 7: Authentication |  | HTTP/1.1, part 7: Authentication |
| draft-ietf-httpbis-p7-auth-19 |  | draft-ietf-httpbis-p7-auth-20 |
| 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. This document defines the HTTP Authentication framework. |
| information initiative since 1990. This document is Part 7 of the |  |  |
| seven-part specification that defines the protocol referred to as |  |  |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. |  |  |
| Part 7 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 should take place on the HTTPBIS working |  | Discussion of this draft takes place on the HTTPBIS working group |
| 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 C.20. |  | The changes in this draft are summarized in Appendix D.1. |
| 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 September 13, 2012. |  | This Internet-Draft will expire on January 17, 2013. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2012 IETF Trust and the persons identified as the |  | Copyright (c) 2012 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 2, line 40 |  | skipping to change at page 3, line 9 |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| 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. Conformance and Error Handling . . . . . . . . . . . . . . 4 |  | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 |
| 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 |  | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 |
| 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 |  |  |
| 2. Access Authentication Framework . . . . . . . . . . . . . . . 5 |  | 2. Access Authentication Framework . . . . . . . . . . . . . . . 5 |
| 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5 |  | 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5 |
| 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7 |  | 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7 |
| 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 |  | 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 8 |
| 2.3.1. Considerations for New Authentication Schemes . . . . 8 |  | 2.3.1. Considerations for New Authentication Schemes . . . . 8 |
| 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 |  | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 |
| 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 |  | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 |
| 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 |  | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 10 |
| 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10 |  | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10 |
| 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 |  | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 |
| 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 11 |  | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 11 |
| 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 11 |  | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 11 |
| 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 |  | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 12 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 |
| 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 12 |  | 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12 |
| 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 |  | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 13 |
| 5.3. Header Field Registration . . . . . . . . . . . . . . . . 13 |  | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 13 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 |
| 6.1. Authentication Credentials and Idle Clients . . . . . . . 13 |  | 6.1. Authentication Credentials and Idle Clients . . . . . . . 13 |
|  |  | 6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 14 |
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 |  | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 |  | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 |
| 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 |  | 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 |
| Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 |  | Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16 |
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 |  | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 16 |
| Appendix C. Change Log (to be removed by RFC Editor before |  | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 17 |
| publication) . . . . . . . . . . . . . . . . . . . . 16 |  | Appendix D. Change Log (to be removed by RFC Editor before |
| C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 16 |  | publication) . . . . . . . . . . . . . . . . . . . . 17 |
| C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 16 |  | D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 17 |
| C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 17 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |
| C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 17 |  |  |
| C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 17 |  |  |
| C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 17 |  |  |
| C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 17 |  |  |
| C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 18 |  |  |
| C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 18 |  |  |
| C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 18 |  |  |
| C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 18 |  |  |
| C.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 18 |  |  |
| C.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 18 |  |  |
| C.14. Since draft-ietf-httpbis-p7-auth-12 . . . . . . . . . . . 19 |  |  |
| C.15. Since draft-ietf-httpbis-p7-auth-13 . . . . . . . . . . . 19 |  |  |
| C.16. Since draft-ietf-httpbis-p7-auth-14 . . . . . . . . . . . 19 |  |  |
| C.17. Since draft-ietf-httpbis-p7-auth-15 . . . . . . . . . . . 19 |  |  |
| C.18. Since draft-ietf-httpbis-p7-auth-16 . . . . . . . . . . . 19 |  |  |
| C.19. Since draft-ietf-httpbis-p7-auth-17 . . . . . . . . . . . 20 |  |  |
| C.20. Since draft-ietf-httpbis-p7-auth-18 . . . . . . . . . . . 20 |  |  |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  |  |
| 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, plus |  | includes the relevant parts of RFC 2616 with only minor changes |
| the general framework for HTTP authentication, as previously defined |  | ([RFC2616]), plus the general framework for HTTP authentication, as |
| in "HTTP Authentication: Basic and Digest Access Authentication" |  | previously defined in "HTTP Authentication: Basic and Digest Access |
| ([RFC2617]). |  | Authentication" ([RFC2617]). |
| HTTP provides several OPTIONAL challenge-response authentication |  | HTTP provides several OPTIONAL challenge-response authentication |
| mechanisms which can be used by a server to challenge a client |  | mechanisms 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 |
| "basic" and "digest" authentication schemes continue to be specified |  | "basic" and "digest" authentication schemes continue to be specified |
| in RFC 2617. |  | in RFC 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]. |
| This document defines conformance criteria for several roles in HTTP |  | This specification targets conformance criteria according to the role |
| communication, including Senders, Recipients, Clients, Servers, User- |  | of a participant in HTTP communication. Hence, HTTP requirements are |
| Agents, Origin Servers, Intermediaries, Proxies and Gateways. See |  | placed on senders, recipients, clients, servers, user agents, |
| Section 2 of [Part1] for definitions of these terms. |  | intermediaries, origin servers, proxies, gateways, or caches, |
|  |  | depending on what behavior is being constrained by the requirement. |
|  |  | See Section 2 of [Part1] for definitions of these terms. |
|  |  | The verb "generate" is used instead of "send" where a requirement |
|  |  | differentiates between creating a protocol element and merely |
|  |  | forwarding a received element downstream. |
| An implementation is considered conformant if it complies with all of |  | An implementation is considered conformant if it complies with all of |
| the requirements associated with its role(s). Note that SHOULD-level |  | the requirements associated with the roles it partakes in HTTP. Note |
| requirements are relevant here, unless one of the documented |  | that SHOULD-level requirements are relevant here, unless one of the |
| exceptions is applicable. |  | documented exceptions is applicable. |
| This document also uses ABNF to define valid protocol elements |  | This document also uses ABNF to define valid protocol elements |
| (Section 1.2). In addition to the prose requirements placed upon |  | (Section 1.2). In addition to the prose requirements placed upon |
| them, Senders MUST NOT generate protocol elements that are invalid. |  | them, senders MUST NOT generate protocol elements that do not match |
|  |  | the grammar defined by the ABNF rules for those protocol elements |
|  |  | that are applicable to the sender's role. If a received protocol |
|  |  | element is processed, the recipient MUST be able to parse any value |
|  |  | that would match the ABNF rules for that protocol element, excluding |
|  |  | only those rules not applicable to the recipient's role. |
| Unless noted otherwise, Recipients MAY take steps to recover a usable |  | Unless noted otherwise, a recipient MAY attempt to recover a usable |
| protocol element from an invalid construct. However, HTTP does not |  | protocol element from an invalid construct. HTTP does not define |
| define specific error handling mechanisms, except in cases where it |  | specific error handling mechanisms except when they have a direct |
| has direct impact on security. This is because different uses of the |  | impact on security, since different applications of the protocol |
| protocol require different error handling strategies; for example, a |  | require different error handling strategies. For example, a Web |
| Web browser may wish to transparently recover from a response where |  | browser might wish to transparently recover from a response where the |
| the Location header field doesn't parse according to the ABNF, |  | Location header field doesn't parse according to the ABNF, whereas a |
| whereby in a systems control protocol using HTTP, this type of error |  | systems control client might consider any form of error recovery to |
| recovery could lead to dangerous consequences. |  | be dangerous. |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the Augmented Backus-Naur Form (ABNF) |  | This specification uses the Augmented Backus-Naur Form (ABNF) |
| notation of [RFC5234] with the list rule extension defined in Section |  | notation of [RFC5234] with the list rule extension defined in Section |
| 1.2 of [Part1]. Appendix B shows the collected ABNF with the list |  | 1.2 of [Part1]. Appendix B describes rules imported from other |
| rule expanded. |  | documents. Appendix C shows the collected ABNF with the list rule |
|  |  | expanded. |
| The following core rules are included by reference, as defined in |  |  |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), 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 8-bit |  |  |
| sequence of data), SP (space), and VCHAR (any visible US-ASCII |  |  |
| character). |  |  |
| 1.2.1. Core Rules |  |  |
| The core rules below are defined in [Part1]: |  |  |
| BWS = <BWS, defined in [Part1], Section 3.2.1> |  |  |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  |  |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |  |  |
| token = <token, defined in [Part1], Section 3.2.4> |  |  |
| 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 mechanism |
| 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 an extensible, |
| case-insensitive token to identify the authentication scheme, |  | case-insensitive token to identify the authentication scheme, |
| followed by additional information necessary for achieving |  | followed by additional information necessary for achieving |
| skipping to change at page 6, line 24 |  | skipping to change at page 6, line 20 |
| challenge = auth-scheme [ 1*SP ( b64token / #auth-param ) ] |  | challenge = auth-scheme [ 1*SP ( b64token / #auth-param ) ] |
| Note: User agents will need to take special care in parsing the |  | Note: User agents will need to take special care in parsing the |
| WWW-Authenticate and Proxy-Authenticate header field values |  | WWW-Authenticate and Proxy-Authenticate header field values |
| because they can contain more than one challenge, or if more than |  | because they can contain more than one challenge, or if more than |
| one of each is provided, since the contents of a challenge can |  | one of each is provided, since the contents of a challenge can |
| itself contain a comma-separated list of authentication |  | itself contain a comma-separated list of authentication |
| parameters. |  | parameters. |
| Note: Many browsers fail to parse challenges containing unknown |  | Note: Many clients fail to parse challenges containing unknown |
| schemes. A workaround for this problem is to list well-supported |  | schemes. A workaround for this problem is to list well-supported |
| schemes (such as "basic") first. |  | schemes (such as "basic") first. |
| A user agent that wishes to authenticate itself with an origin server |  | A user agent that wishes to authenticate itself with an origin server |
| -- usually, but not necessarily, after receiving a 401 (Unauthorized) |  | -- usually, but not necessarily, after receiving a 401 (Unauthorized) |
| -- MAY 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) -- MAY 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 consist of credentials containing the authentication |  | value contain the client's credentials for the realm of the resource |
| information of the client for the realm of the resource being |  | being requested, based upon a challenge received from the server |
| requested. The user agent MUST choose to use one of the challenges |  | (possibly at some point in the past). When creating their values, |
| with the strongest auth-scheme it understands and request credentials |  | the user agent ought to do so by selecting the challenge with what it |
| from the user based upon that challenge. |  | considers to be the most secure auth-scheme that it understands, |
|  |  | obtaining credentials from the user as appropriate. |
| credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ] |  | credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ] |
| If the origin server does not wish to accept the credentials sent |  | Upon a request for a protected resource that omits credentials, |
| with a request, it SHOULD return a 401 (Unauthorized) response. The |  | contains invalid credentials (e.g., a bad password) or partial |
| response MUST include a WWW-Authenticate header field containing at |  | credentials (e.g., when the authentication scheme requires more than |
| least one (possibly new) challenge applicable to the requested |  | one round trip), an origin server SHOULD return a 401 (Unauthorized) |
| resource. |  | response. Such responses 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 |  | Likewise, upon a request that requires authentication by proxies that |
| SHOULD return a 407 (Proxy Authentication Required). The response |  | omit credentials or contain invalid or partial credentials, a proxy |
| MUST include a Proxy-Authenticate header field containing a (possibly |  | SHOULD return a 407 (Proxy Authentication Required) response. Such |
| new) challenge applicable to the proxy for the requested resource. |  | responses MUST include a Proxy-Authenticate header field containing a |
|  |  | (possibly new) challenge applicable to the proxy. |
|  |  | A server receiving credentials that are valid, but not adequate to |
|  |  | gain access, ought to respond with the 403 (Forbidden) status code |
|  |  | (Section 4.6.3 of [Part2]). |
| The HTTP protocol does not restrict applications to this simple |  | The HTTP protocol does not restrict applications to this simple |
| challenge-response mechanism for access authentication. Additional |  | challenge-response mechanism for access authentication. Additional |
| mechanisms MAY be used, such as encryption at the transport level or |  | mechanisms MAY be used, such as encryption at the transport level or |
| via message encapsulation, and with additional header fields |  | via message encapsulation, and with additional header fields |
| specifying authentication information. However, such additional |  | specifying authentication information. However, such additional |
| mechanisms are not defined by this specification. |  | mechanisms are not defined by this specification. |
| Proxies MUST forward the WWW-Authenticate and Authorization headers |  | Proxies MUST forward the WWW-Authenticate and Authorization header |
| unmodified and follow the rules found in Section 4.1. |  | fields unmodified and follow the rules found in Section 4.1. |
| 2.2. Protection Space (Realm) |  | 2.2. Protection Space (Realm) |
| The authentication parameter realm is reserved for use by |  | The authentication parameter realm is reserved for use by |
| authentication schemes that wish to indicate the scope of protection. |  | authentication schemes that wish to indicate the scope of protection. |
| A protection space is defined by the canonical root URI (the scheme |  | A protection space is defined by the canonical root URI (the scheme |
| and authority components of the effective request URI; see Section |  | and authority components of the effective request URI; see Section |
| 5.5 of [Part1]) of the server being accessed, in combination with the |  | 5.5 of [Part1]) of the server being accessed, in combination with the |
| realm value if present. These realms allow the protected resources |  | realm value if present. These realms allow the protected resources |
| skipping to change at page 8, line 31 |  | skipping to change at page 8, line 36 |
| There are certain aspects of the HTTP Authentication Framework that |  | There are certain aspects of the HTTP Authentication Framework that |
| put constraints on how new authentication schemes can work: |  | put constraints on how new authentication schemes can work: |
| o HTTP authentication is presumed to be stateless: all of the |  | o HTTP authentication is presumed to be stateless: all of the |
| information necessary to authenticate a request MUST be provided |  | information necessary to authenticate a request MUST be provided |
| in the request, rather than be dependent on the server remembering |  | in the request, rather than be dependent on the server remembering |
| prior requests. Authentication based on, or bound to, the |  | prior requests. Authentication based on, or bound to, the |
| underlying connection is outside the scope of this specification |  | underlying connection is outside the scope of this specification |
| and inherently flawed unless steps are taken to ensure that the |  | and inherently flawed unless steps are taken to ensure that the |
| connection cannot be used by any party other than the |  | connection cannot be used by any party other than the |
| authenticated user (see Section 2.3 of [Part1]). |  | authenticated user (see Section 2.4 of [Part1]). |
| o The authentication parameter "realm" is reserved for defining |  | o The authentication parameter "realm" is reserved for defining |
| Protection Spaces as defined in Section 2.2. New schemes MUST NOT |  | Protection Spaces as defined in Section 2.2. New schemes MUST NOT |
| use it in a way incompatible with that definition. |  | use it in a way incompatible with that definition. |
| o The "b64token" notation was introduced for compatibility with |  | o The "b64token" notation was introduced for compatibility with |
| existing authentication schemes and can only be used once per |  | existing authentication schemes and can only be used once per |
| challenge/credentials. New schemes thus ought to use the "auth- |  | challenge/credentials. New schemes thus ought to use the "auth- |
| param" syntax instead, because otherwise future extensions will be |  | param" syntax instead, because otherwise future extensions will be |
| impossible. |  | impossible. |
| o The parsing of challenges and credentials is defined by this |  | o The parsing of challenges and credentials is defined by this |
| specification, and cannot be modified by new authentication |  | specification, and cannot be modified by new authentication |
| schemes. When the auth-param syntax is used, all parameters ought |  | schemes. When the auth-param syntax is used, all parameters ought |
| to support both token and quoted-string syntax, and syntactical |  | to support both token and quoted-string syntax, and syntactical |
| constraints ought to be defined on the field value after parsing |  | constraints ought to be defined on the field value after parsing |
| (i.e., quoted-string processing). This is necessary so that |  | (i.e., quoted-string processing). This is necessary so that |
| recipients can use a generic parser that applies to all |  | recipients can use a generic parser that applies to all |
| authentication schemes. |  | authentication schemes. |
| Note: the fact that the value syntax for the "realm" parameter is |  | Note: The fact that the value syntax for the "realm" parameter is |
| restricted to quoted-string was a bad design choice not to be |  | restricted to quoted-string was a bad design choice not to be |
| repeated for new parameters. |  | repeated for new parameters. |
| o Definitions of new schemes ought to define the treatment of |  | o Definitions of new schemes ought to define the treatment of |
| unknown extension parameters. In general, a "must-ignore" rule is |  | unknown extension parameters. In general, a "must-ignore" rule is |
| preferable over "must-understand", because otherwise it will be |  | preferable over "must-understand", because otherwise it will be |
| hard to introduce new parameters in the presence of legacy |  | hard to introduce new parameters in the presence of legacy |
| recipients. Furthermore, it's good to describe the policy for |  | recipients. Furthermore, it's good to describe the policy for |
| defining new parameters (such as "update the specification", or |  | defining new parameters (such as "update the specification", or |
| "use this registry"). |  | "use this registry"). |
| skipping to change at page 9, line 25 |  | skipping to change at page 9, line 30 |
| o Authentication schemes need to document whether they are usable in |  | o Authentication schemes need to document whether they are usable in |
| origin-server authentication (i.e., using WWW-Authenticate), |  | origin-server authentication (i.e., using WWW-Authenticate), |
| and/or proxy authentication (i.e., using Proxy-Authenticate). |  | and/or proxy authentication (i.e., using Proxy-Authenticate). |
| o The credentials carried in an Authorization header field are |  | o The credentials carried in an Authorization header field are |
| specific to the User Agent, and therefore have the same effect on |  | specific to the User Agent, and therefore have the same effect on |
| HTTP caches as the "private" Cache-Control response directive, |  | HTTP caches as the "private" Cache-Control response directive, |
| within the scope of the request they appear in. |  | within the scope of the request they appear in. |
| Therefore, new authentication schemes which choose not to carry |  | Therefore, new authentication schemes which choose not to carry |
| credentials in the Authorization header (e.g., using a newly |  | credentials in the Authorization header field (e.g., using a newly |
| defined header) will need to explicitly disallow caching, by |  | defined header field) will need to explicitly disallow caching, by |
| mandating the use of either Cache-Control request directives |  | mandating the use of either Cache-Control request directives |
| (e.g., "no-store") or response directives (e.g., "private"). |  | (e.g., "no-store") or response directives (e.g., "private"). |
| 3. Status Code Definitions |  | 3. Status Code Definitions |
| 3.1. 401 Unauthorized |  | 3.1. 401 Unauthorized |
| The request requires user authentication. The response MUST include |  | The request requires user authentication. The response MUST include |
| a WWW-Authenticate header field (Section 4.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 |
| skipping to change at page 11, line 7 |  | skipping to change at page 11, line 12 |
| 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 header |  | MUST first revalidate it with the origin server, using the header |
| fields from the new request to allow the origin server to |  | fields from the new request to allow the origin server to |
| authenticate the new request. |  | 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. |
| 4.2. Proxy-Authenticate |  | 4.2. Proxy-Authenticate |
| The "Proxy-Authenticate" header field consists of a challenge that |  | The "Proxy-Authenticate" header field consists of at least one |
| indicates the authentication scheme and parameters applicable to the |  | challenge that indicates the authentication scheme(s) and parameters |
| proxy for this effective request URI (Section 5.5 of [Part1]). It |  | applicable to the proxy for this effective request URI (Section 5.5 |
| MUST be included as part of a 407 (Proxy Authentication Required) |  | of [Part1]). It MUST be included as part of a 407 (Proxy |
| response. |  | Authentication Required) response. |
| Proxy-Authenticate = 1#challenge |  | Proxy-Authenticate = 1#challenge |
| Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |  | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |
| only to the current connection and SHOULD NOT be passed on to |  | only to the current connection, and intermediaries SHOULD NOT forward |
| downstream clients. However, an intermediate proxy might need to |  | it to downstream clients. However, an intermediate proxy might need |
| obtain its own credentials by requesting them from the downstream |  | to obtain its own credentials by requesting them from the downstream |
| client, which in some circumstances will appear as if the proxy is |  | client, which in some circumstances will appear as if the proxy is |
| forwarding the Proxy-Authenticate header field. |  | forwarding the Proxy-Authenticate header field. |
| Note that the parsing considerations for WWW-Authenticate apply to |  | Note that the parsing considerations for WWW-Authenticate apply to |
| this header field as well; see Section 4.4 for details. |  | this header field as well; see Section 4.4 for details. |
| 4.3. Proxy-Authorization |  | 4.3. Proxy-Authorization |
| The "Proxy-Authorization" header field allows the client to identify |  | The "Proxy-Authorization" header field allows the client to identify |
| itself (or its user) to a proxy which requires authentication. Its |  | itself (or its user) to a proxy which requires authentication. Its |
| skipping to change at page 12, line 32 |  | skipping to change at page 12, line 42 |
| Note: The challenge grammar production uses the list syntax as |  | Note: The challenge grammar production uses the list syntax as |
| 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. Authenticaton Scheme Registry |  | 5.1. Authentication Scheme Registry |
| The registration procedure for HTTP Authentication Schemes is defined |  | The registration procedure for HTTP Authentication Schemes is defined |
| by Section 2.3 of this document. |  | by Section 2.3 of this document. |
| The HTTP Method Authentication Scheme shall be created 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.2. Status Code Registration |  | 5.2. Status Code Registration |
| The HTTP Status Code Registry located at |  | The HTTP Status Code Registry located at |
| skipping to change at page 14, line 8 |  | skipping to change at page 14, line 22 |
| 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.2. Protection Spaces |
|  |  | Authentication schemes that solely rely on the "realm" mechanism for |
|  |  | establishing a protection space will expose credentials to all |
|  |  | resources on a server. Clients that have successfully made |
|  |  | authenticated requests with a resource can use the same |
|  |  | authentication credentials for other resources on the same server. |
|  |  | This makes it possible for a different resource to harvest |
|  |  | authentication credentials for other resources. |
|  |  | This is of particular concern when a server hosts resources for |
|  |  | multiple parties under the same canonical root URI (Section 2.2). |
|  |  | Possible mitigation strategies include restricting direct access to |
|  |  | authentication credentials (i.e., not making the content of the |
|  |  | Authorization request header field available), and separating |
|  |  | protection spaces by using a different host name 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. |
| See Section 9 of [Part1] for the Acknowledgments related to this |  | See Section 9 of [Part1] for the Acknowledgments related to this |
| skipping to change at page 14, line 21 |  | skipping to change at page 15, 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., Lafon, Y., Ed., and J. Reschke, Ed., |  | [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
| "HTTP/1.1, part 1: URIs, Connections, and Message |  | "HTTP/1.1, part 1: Message Routing and Syntax"", |
| Parsing", draft-ietf-httpbis-p1-messaging-19 (work in |  | draft-ietf-httpbis-p1-messaging-20 (work in progress), |
| progress), March 2012. |  | July 2012. |
|  |  | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
|  |  | "HTTP/1.1, part 2: Semantics and Payloads", |
|  |  | draft-ietf-httpbis-p2-semantics-20 (work in progress), |
|  |  | July 2012. |
| [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |  | [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |  | and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", |
| draft-ietf-httpbis-p6-cache-19 (work in progress), |  | draft-ietf-httpbis-p6-cache-20 (work in progress), |
| March 2012. |  | July 2012. |
| [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 |
| [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |  | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
| skipping to change at page 15, line 28 |  | skipping to change at page 16, line 15 |
| Appendix A. Changes from RFCs 2616 and 2617 |  | Appendix A. Changes from RFCs 2616 and 2617 |
| The "realm" parameter isn't required anymore in general; |  | The "realm" parameter isn't required anymore in general; |
| consequently, the ABNF allows challenges without any auth parameters. |  | consequently, the ABNF allows challenges without any auth parameters. |
| (Section 2) |  | (Section 2) |
| The "b64token" alternative to auth-param lists has been added for |  | The "b64token" alternative to auth-param lists has been added for |
| consistency with legacy authentication schemes such as "Basic". |  | consistency with legacy authentication schemes such as "Basic". |
| (Section 2) |  | (Section 2) |
|  |  | Introduce Authentication Scheme Registry. (Section 2.3) |
| Change ABNF productions for header fields to only define the field |  | Change ABNF productions for header fields to only define the field |
| value. (Section 4) |  | value. (Section 4) |
| Appendix B. Collected ABNF |  | Appendix B. Imported ABNF |
|  |  | The following core rules are included by reference, as defined in |
|  |  | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
|  |  | 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 |
|  |  | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII |
|  |  | character). |
|  |  | The rules below are defined in [Part1]: |
|  |  | BWS = <BWS, defined in [Part1], Section 3.2.1> |
|  |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
|  |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |
|  |  | token = <token, defined in [Part1], Section 3.2.4> |
|  |  | Appendix C. Collected ABNF |
| Authorization = credentials |  | Authorization = credentials |
| BWS = <BWS, defined in [Part1], Section 3.2.1> |  | BWS = <BWS, defined in [Part1], Section 3.2.1> |
| OWS = <OWS, defined in [Part1], Section 3.2.1> |  | OWS = <OWS, defined in [Part1], Section 3.2.1> |
| 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 16, line 35 |  | skipping to change at page 17, line 35 |
| challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *( |  | challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *( |
| OWS "," [ OWS auth-param ] ) ] ) ] |  | OWS "," [ OWS auth-param ] ) ] ) ] |
| credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) |  | credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) |
| *( OWS "," [ OWS auth-param ] ) ] ) ] |  | *( OWS "," [ OWS auth-param ] ) ] ) ] |
| quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |
| token = <token, defined in [Part1], Section 3.2.4> |  | token = <token, defined in [Part1], Section 3.2.4> |
| ABNF diagnostics: |  | Appendix D. Change Log (to be removed by RFC Editor before publication) |
| ; Authorization defined but not used |  |  |
| ; Proxy-Authenticate defined but not used |  |  |
| ; Proxy-Authorization defined but not used |  |  |
| ; WWW-Authenticate defined but not used |  |  |
| Appendix C. Change Log (to be removed by RFC Editor before publication) |  |  |
| C.1. Since RFC 2616 |  |  |
| Extracted relevant partitions from [RFC2616]. |  |  |
| C.2. Since draft-ietf-httpbis-p7-auth-00 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |  |  |
| Informative references" |  |  |
| C.3. Since draft-ietf-httpbis-p7-auth-01 |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Explicitly import BNF rules for "challenge" and "credentials" from |  |  |
| RFC2617. |  |  |
| o Add explicit references to BNF syntax and rules imported from |  |  |
| other parts of the specification. |  |  |
| C.4. Since draft-ietf-httpbis-p7-auth-02 |  |  |
| Ongoing work on IANA Message Header Field Registration |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |  |  |
| o Reference RFC 3984, and update header field registrations for |  |  |
| header fields defined in this document. |  |  |
| C.5. Since draft-ietf-httpbis-p7-auth-03 |  |  |
| None. |  |  |
| C.6. Since draft-ietf-httpbis-p7-auth-04 |  |  |
| Ongoing work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Use "/" instead of "|" for alternatives. |  |  |
| o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |  |  |
| whitespace ("OWS") and required whitespace ("RWS"). |  |  |
| o Rewrite ABNFs to spell out whitespace rules, factor out header |  |  |
| field value format definitions. |  |  |
| C.7. Since draft-ietf-httpbis-p7-auth-05 |  |  |
| Final work on ABNF conversion |  |  |
| (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |  |  |
| o Add appendix containing collected and expanded ABNF, reorganize |  |  |
| ABNF introduction. |  |  |
| C.8. Since draft-ietf-httpbis-p7-auth-06 |  |  |
| None. |  |  |
| C.9. Since draft-ietf-httpbis-p7-auth-07 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA |  |  |
| registrations for optional status codes" |  |  |
| C.10. Since draft-ietf-httpbis-p7-auth-08 |  |  |
| No significant changes. |  |  |
| C.11. Since draft-ietf-httpbis-p7-auth-09 |  |  |
| Partly resolved issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |  |  |
| requested resource's URI" |  |  |
| C.12. Since draft-ietf-httpbis-p7-auth-10 |  |  |
| None. |  |  |
| C.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/224>: "Header |  |  |
| Classification" |  |  |
| 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" |  |  |
| C.14. Since draft-ietf-httpbis-p7-auth-12 |  |  |
| None. |  |  |
| C.15. Since draft-ietf-httpbis-p7-auth-13 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |  |  |
| ABNFs for header fields" |  |  |
| C.16. Since draft-ietf-httpbis-p7-auth-14 |  |  |
| None. |  |  |
| C.17. Since draft-ietf-httpbis-p7-auth-15 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/78>: "Relationship |  |  |
| between 401, Authorization and WWW-Authenticate" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/177>: "Realm |  |  |
| required on challenges" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param |  |  |
| syntax" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/257>: |  |  |
| "Considerations for new authentications schemes" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/287>: "LWS in auth- |  |  |
| param ABNF" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/309>: "credentials |  |  |
| ABNF missing SP (still using implied LWS?)" |  |  |
| C.18. Since draft-ietf-httpbis-p7-auth-16 |  |  |
| Closed issues: |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |  |  |
| HTTP's error-handling philosophy" |  |  |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/320>: "add advice on |  | Changes up to the first Working Group Last Call draft are summarized |
| defining auth scheme parameters" |  | in <http://trac.tools.ietf.org/html/ |
|  |  | draft-ietf-httpbis-p7-auth-19#appendix-C>. |
| C.19. Since draft-ietf-httpbis-p7-auth-17 |  | D.1. Since draft-ietf-httpbis-p7-auth-19 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/314>: "allow |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/348>: "Realms and |
| unquoted realm parameters" |  | scope" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/321>: "Repeating |  |  |
| auth-params" |  |  |
| C.20. Since draft-ietf-httpbis-p7-auth-18 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/349>: "Strength" |
| Closed issues: |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/357>: |
|  |  | "Authentication exchanges" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/334>: "recipient |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |
| behavior for new auth parameters" |  | requirements for recipients" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/342>: "WWW- |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |
| Authenticate ABNF slightly ambiguous" |  | introduction of new IANA registries as normative changes" |
| Index |  | Index |
| 4 |  | 4 |
| 401 Unauthorized (status code) 9 |  | 401 Unauthorized (status code) 9 |
| 407 Proxy Authentication Required (status code) 9 |  | 407 Proxy Authentication Required (status code) 10 |
| A |  | A |
| auth-param 5 |  | auth-param 5 |
| auth-scheme 5 |  | auth-scheme 5 |
| Authorization header field 10 |  | Authorization header field 10 |
| B |  | B |
| b64token 5 |  | b64token 5 |
| C |  | C |
|  |  | Canonical Root URI 7 |
| challenge 6 |  | challenge 6 |
| credentials 6 |  | credentials 6 |
| G |  | G |
| Grammar |  | Grammar |
| auth-param 5 |  | auth-param 5 |
| auth-scheme 5 |  | auth-scheme 5 |
| Authorization 10 |  | Authorization 10 |
| b64token 5 |  | b64token 5 |
| challenge 6 |  | challenge 6 |
| credentials 6 |  | credentials 6 |
| Proxy-Authenticate 11 |  | Proxy-Authenticate 11 |
| Proxy-Authorization 11 |  | Proxy-Authorization 11 |
| WWW-Authenticate 12 |  | WWW-Authenticate 12 |
| H |  | H |
| Header Fields |  | Header Fields |
| Authorization 10 |  | Authorization 10 |
| Proxy-Authenticate 11 |  | Proxy-Authenticate 11 |
| Proxy-Authorization 11 |  | Proxy-Authorization 11 |
| WWW-Authenticate 11 |  | WWW-Authenticate 12 |
| P |  | P |
| Protection Space 7 |  | Protection Space 7 |
| Proxy-Authenticate header field 11 |  | Proxy-Authenticate header field 11 |
| Proxy-Authorization header field 11 |  | Proxy-Authorization header field 11 |
| R |  | R |
| Realm 7 |  | Realm 7 |
| S |  | S |
| Status Codes |  | Status Codes |
| 401 Unauthorized 9 |  | 401 Unauthorized 9 |
| 407 Proxy Authentication Required 9 |  | 407 Proxy Authentication Required 10 |
| W |  | W |
| WWW-Authenticate header field 11 |  | WWW-Authenticate header field 12 |
| 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 |
| skipping to change at page 22, line 4 |  | skipping to change at page 19, line 36 |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| EMail: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| Phone: +49 251 2807760 |  |  |
| Fax: +49 251 2807761 |  |  |
| EMail: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 53 change blocks.
| 300 lines changed or deleted |  | 166 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/