draft-ietf-httpbis-p7-auth-20.txt | draft-ietf-httpbis-p7-auth-21.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) J. Reschke, Ed. | |||
Updates: 2617 (if approved) W3C | Updates: 2617 (if approved) greenbytes | |||
Intended status: Standards Track J. Reschke, Ed. | Intended status: Standards Track October 4, 2012 | |||
Expires: January 17, 2013 greenbytes | Expires: April 7, 2013 | |||
July 16, 2012 | ||||
HTTP/1.1, part 7: Authentication | Hypertext Transfer Protocol (HTTP/1.1): Authentication | |||
draft-ietf-httpbis-p7-auth-20 | draft-ietf-httpbis-p7-auth-21 | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. This document defines the HTTP Authentication framework. | systems. This document defines the HTTP Authentication framework. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft takes place on the HTTPBIS working group | Discussion of this draft takes place on the HTTPBIS working group | |||
mailing list (ietf-http-wg@w3.org), which is archived at | mailing list (ietf-http-wg@w3.org), which is archived at | |||
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. | |||
The current issues list is at | The current issues list is at | |||
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix D.1. | The changes in this draft are summarized in Appendix D.2. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on January 17, 2013. | This Internet-Draft will expire on April 7, 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
skipping to change at page 3, line 9 | 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 . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Access Authentication Framework . . . . . . . . . . . . . . . 5 | 2. Access Authentication Framework . . . . . . . . . . . . . . . 4 | |||
2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5 | 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4 | |||
2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7 | 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 | |||
2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 8 | 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 | |||
2.3.1. Considerations for New Authentication Schemes . . . . 8 | 2.3.1. Considerations for New Authentication Schemes . . . . 7 | |||
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 | |||
3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 10 | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 | |||
4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10 | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 | |||
4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 11 | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 | |||
4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 11 | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 | |||
4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 12 | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12 | 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12 | |||
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 13 | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 | |||
5.3. Header Field Registration . . . . . . . . . . . . . . . . 13 | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
6.1. Authentication Credentials and Idle Clients . . . . . . . 13 | 6.1. Authentication Credentials and Idle Clients . . . . . . . 13 | |||
6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 14 | 6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16 | Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 | |||
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 16 | Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 17 | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 | |||
Appendix D. Change Log (to be removed by RFC Editor before | Appendix D. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 17 | publication) . . . . . . . . . . . . . . . . . . . . 16 | |||
D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 17 | D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
1. Introduction | 1. Introduction | |||
This document defines HTTP/1.1 access control and authentication. It | This document defines HTTP/1.1 access control and authentication. It | |||
includes the relevant parts of RFC 2616 with only minor changes | includes the relevant parts of RFC 2616 with only minor changes | |||
([RFC2616]), plus the general framework for HTTP authentication, as | ([RFC2616]), plus the general framework for HTTP authentication, as | |||
previously defined in "HTTP Authentication: Basic and Digest Access | previously defined in "HTTP Authentication: Basic and Digest Access | |||
Authentication" ([RFC2617]). | Authentication" ([RFC2617]). | |||
HTTP provides several OPTIONAL challenge-response authentication | HTTP provides several OPTIONAL challenge-response authentication | |||
skipping to change at page 4, line 25 | skipping to change at page 4, line 25 | |||
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 specification targets conformance criteria according to the role | Conformance criteria and considerations regarding error handling are | |||
of a participant in HTTP communication. Hence, HTTP requirements are | defined in Section 2.5 of [Part1]. | |||
placed on senders, recipients, clients, servers, user agents, | ||||
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 | ||||
the requirements associated with the roles it partakes in HTTP. Note | ||||
that SHOULD-level requirements are relevant here, unless one of the | ||||
documented exceptions is applicable. | ||||
This document also uses ABNF to define valid protocol elements | ||||
(Section 1.2). In addition to the prose requirements placed upon | ||||
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, a recipient MAY attempt to recover a usable | ||||
protocol element from an invalid construct. HTTP does not define | ||||
specific error handling mechanisms except when they have a direct | ||||
impact on security, since different applications of the protocol | ||||
require different error handling strategies. For example, a Web | ||||
browser might wish to transparently recover from a response where the | ||||
Location header field doesn't parse according to the ABNF, whereas a | ||||
systems control client might consider any form of error recovery to | ||||
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 describes rules imported from other | 1.2 of [Part1]. Appendix B describes rules imported from other | |||
documents. Appendix C shows the collected ABNF with the list rule | documents. Appendix C shows the collected ABNF with the list rule | |||
expanded. | expanded. | |||
2. Access Authentication Framework | 2. Access Authentication Framework | |||
skipping to change at page 5, line 40 | skipping to change at page 5, line 9 | |||
capable of holding base64-encoded information. | capable of holding base64-encoded information. | |||
Parameters are name-value pairs where the name is matched case- | Parameters are name-value pairs where the name is matched case- | |||
insensitively, and each parameter name MUST only occur once per | insensitively, and each parameter name MUST only occur once per | |||
challenge. | challenge. | |||
auth-scheme = token | auth-scheme = token | |||
auth-param = token BWS "=" BWS ( token / quoted-string ) | auth-param = token BWS "=" BWS ( token / quoted-string ) | |||
b64token = 1*( ALPHA / DIGIT / | token68 = 1*( ALPHA / DIGIT / | |||
"-" / "." / "_" / "~" / "+" / "/" ) *"=" | "-" / "." / "_" / "~" / "+" / "/" ) *"=" | |||
The "b64token" syntax allows the 66 unreserved URI characters | The "token68" syntax allows the 66 unreserved URI characters | |||
([RFC3986]), plus a few others, so that it can hold a base64, | ([RFC3986]), plus a few others, so that it can hold a base64, | |||
base64url (URL and filename safe alphabet), base32, or base16 (hex) | base64url (URL and filename safe alphabet), base32, or base16 (hex) | |||
encoding, with or without padding, but excluding whitespace | encoding, with or without padding, but excluding whitespace | |||
([RFC4648]). | ([RFC4648]). | |||
The 401 (Unauthorized) response message is used by an origin server | The 401 (Unauthorized) response message is used by an origin server | |||
to challenge the authorization of a user agent. This response MUST | to challenge the authorization of a user agent. This response MUST | |||
include a WWW-Authenticate header field containing at least one | include a WWW-Authenticate header field containing at least one | |||
challenge applicable to the requested resource. | challenge applicable to the requested resource. | |||
The 407 (Proxy Authentication Required) response message is used by a | The 407 (Proxy Authentication Required) response message is used by a | |||
proxy to challenge the authorization of a client and MUST include a | proxy to challenge the authorization of a client and MUST include a | |||
Proxy-Authenticate header field containing at least one challenge | Proxy-Authenticate header field containing at least one challenge | |||
applicable to the proxy for the requested resource. | applicable to the proxy for the requested resource. | |||
challenge = auth-scheme [ 1*SP ( b64token / #auth-param ) ] | challenge = auth-scheme [ 1*SP ( token68 / #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 clients 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 | |||
skipping to change at page 6, line 42 | skipping to change at page 6, line 10 | |||
field with the request. | field with the request. | |||
Both the Authorization field value and the Proxy-Authorization field | Both the Authorization field value and the Proxy-Authorization field | |||
value contain the client's credentials for the realm of the resource | value contain the client's credentials for the realm of the resource | |||
being requested, based upon a challenge received from the server | being requested, based upon a challenge received from the server | |||
(possibly at some point in the past). When creating their values, | (possibly at some point in the past). When creating their values, | |||
the user agent ought to do so by selecting the challenge with what it | the user agent ought to do so by selecting the challenge with what it | |||
considers to be the most secure auth-scheme that it understands, | considers to be the most secure auth-scheme that it understands, | |||
obtaining credentials from the user as appropriate. | obtaining credentials from the user as appropriate. | |||
credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ] | credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] | |||
Upon a request for a protected resource that omits credentials, | Upon a request for a protected resource that omits credentials, | |||
contains invalid credentials (e.g., a bad password) or partial | contains invalid credentials (e.g., a bad password) or partial | |||
credentials (e.g., when the authentication scheme requires more than | credentials (e.g., when the authentication scheme requires more than | |||
one round trip), an origin server SHOULD return a 401 (Unauthorized) | one round trip), an origin server SHOULD return a 401 (Unauthorized) | |||
response. Such responses MUST include a WWW-Authenticate header | response. Such responses MUST include a WWW-Authenticate header | |||
field containing at least one (possibly new) challenge applicable to | field containing at least one (possibly new) challenge applicable to | |||
the requested resource. | the requested resource. | |||
Likewise, upon a request that requires authentication by proxies that | Likewise, upon a request that requires authentication by proxies that | |||
omit credentials or contain invalid or partial credentials, a proxy | omit credentials or contain invalid or partial credentials, a proxy | |||
SHOULD return a 407 (Proxy Authentication Required) response. Such | SHOULD return a 407 (Proxy Authentication Required) response. Such | |||
responses MUST include a Proxy-Authenticate header field containing a | responses MUST include a Proxy-Authenticate header field containing a | |||
(possibly new) challenge applicable to the proxy. | (possibly new) challenge applicable to the proxy. | |||
A server receiving credentials that are valid, but not adequate to | A server receiving credentials that are valid, but not adequate to | |||
gain access, ought to respond with the 403 (Forbidden) status code | gain access, ought to respond with the 403 (Forbidden) status code | |||
(Section 4.6.3 of [Part2]). | (Section 7.5.3 of [Part2]). | |||
The HTTP protocol does not restrict applications to this simple | The HTTP protocol does not restrict applications to this simple | |||
challenge-response mechanism for access authentication. Additional | challenge-response mechanism for access authentication. Additional | |||
mechanisms MAY be used, such as encryption at the transport level or | mechanisms MAY be used, such as encryption at the transport level or | |||
via message encapsulation, and with additional header fields | via message encapsulation, and with additional header fields | |||
specifying authentication information. However, such additional | specifying authentication information. However, such additional | |||
mechanisms are not defined by this specification. | mechanisms are not defined by this specification. | |||
Proxies MUST forward the WWW-Authenticate and Authorization header | Proxies MUST forward the WWW-Authenticate and Authorization header | |||
fields unmodified and follow the rules found in Section 4.1. | fields unmodified and follow the rules found in Section 4.1. | |||
skipping to change at page 8, line 36 | skipping to change at page 8, line 4 | |||
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.4 of [Part1]). | authenticated user (see Section 2.3 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 "token68" 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 | |||
skipping to change at page 14, line 44 | skipping to change at page 14, line 4 | |||
Possible mitigation strategies include restricting direct access to | Possible mitigation strategies include restricting direct access to | |||
authentication credentials (i.e., not making the content of the | authentication credentials (i.e., not making the content of the | |||
Authorization request header field available), and separating | Authorization request header field available), and separating | |||
protection spaces by using a different host name for each party. | protection spaces by using a different host name 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 | |||
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. and J. Reschke, Ed., "Hypertext Transfer | |||
"HTTP/1.1, part 1: Message Routing and Syntax"", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
draft-ietf-httpbis-p1-messaging-20 (work in progress), | draft-ietf-httpbis-p1-messaging-21 (work in progress), | |||
July 2012. | October 2012. | |||
[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
"HTTP/1.1, part 2: Semantics and Payloads", | Protocol (HTTP/1.1): Semantics and Content", | |||
draft-ietf-httpbis-p2-semantics-20 (work in progress), | draft-ietf-httpbis-p2-semantics-21 (work in progress), | |||
July 2012. | October 2012. | |||
[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | |||
draft-ietf-httpbis-p6-cache-20 (work in progress), | draft-ietf-httpbis-p6-cache-21 (work in progress), | |||
July 2012. | October 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 16, line 11 | skipping to change at page 15, line 20 | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
Appendix A. Changes from RFCs 2616 and 2617 | Appendix A. Changes from RFCs 2616 and 2617 | |||
The "realm" parameter isn't required anymore in general; | The "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 "token68" alternative to auth-param lists has been added for | |||
consistency with legacy authentication schemes such as "Basic". | consistency with legacy authentication schemes such as "Basic". | |||
(Section 2) | (Section 2) | |||
Introduce Authentication Scheme Registry. (Section 2.3) | Introduce Authentication Scheme Registry. (Section 2.3) | |||
Change ABNF productions for header fields to only define the field | ||||
value. (Section 4) | ||||
Appendix B. Imported ABNF | Appendix B. Imported ABNF | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), | |||
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double | |||
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any | |||
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII | 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII | |||
character). | character). | |||
The rules below are defined in [Part1]: | The rules below are defined in [Part1]: | |||
skipping to change at page 17, line 23 | skipping to change at page 16, line 23 | |||
Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS | Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS | |||
challenge ] ) | challenge ] ) | |||
Proxy-Authorization = credentials | Proxy-Authorization = credentials | |||
WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge | WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge | |||
] ) | ] ) | |||
auth-param = token BWS "=" BWS ( token / quoted-string ) | auth-param = token BWS "=" BWS ( token / quoted-string ) | |||
auth-scheme = token | auth-scheme = token | |||
b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) | challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / 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 ( token68 / [ ( "," / auth-param ) | |||
*( OWS "," [ OWS auth-param ] ) ] ) ] | *( OWS "," [ OWS auth-param ] ) ] ) ] | |||
quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> | quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> | |||
token = <token, defined in [Part1], Section 3.2.4> | token = <token, defined in [Part1], Section 3.2.4> | |||
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) | ||||
*"=" | ||||
Appendix D. Change Log (to be removed by RFC Editor before publication) | Appendix D. Change Log (to be removed by RFC Editor before publication) | |||
Changes up to the first Working Group Last Call draft are summarized | Changes up to the first Working Group Last Call draft are summarized | |||
in <http://trac.tools.ietf.org/html/ | in <http://trac.tools.ietf.org/html/ | |||
draft-ietf-httpbis-p7-auth-19#appendix-C>. | draft-ietf-httpbis-p7-auth-19#appendix-C>. | |||
D.1. Since draft-ietf-httpbis-p7-auth-19 | D.1. Since draft-ietf-httpbis-p7-auth-19 | |||
Closed issues: | Closed issues: | |||
skipping to change at page 18, line 11 | skipping to change at page 17, line 11 | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/357>: | o <http://tools.ietf.org/wg/httpbis/trac/ticket/357>: | |||
"Authentication exchanges" | "Authentication exchanges" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF | o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF | |||
requirements for recipients" | requirements for recipients" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note | o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note | |||
introduction of new IANA registries as normative changes" | introduction of new IANA registries as normative changes" | |||
D.2. Since draft-ietf-httpbis-p7-auth-20 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename | ||||
b64token for clarity" | ||||
Other changes: | ||||
o Conformance criteria and considerations regarding error handling | ||||
are now defined in Part 1. | ||||
Index | Index | |||
4 | 4 | |||
401 Unauthorized (status code) 9 | 401 Unauthorized (status code) 9 | |||
407 Proxy Authentication Required (status code) 10 | 407 Proxy Authentication Required (status code) 9 | |||
A | A | |||
auth-param 5 | Authorization header field 9 | |||
auth-scheme 5 | ||||
Authorization header field 10 | ||||
B | ||||
b64token 5 | ||||
C | C | |||
Canonical Root URI 7 | Canonical Root URI 6 | |||
challenge 6 | ||||
credentials 6 | ||||
G | G | |||
Grammar | Grammar | |||
auth-param 5 | auth-param 5 | |||
auth-scheme 5 | auth-scheme 5 | |||
Authorization 10 | Authorization 9 | |||
b64token 5 | challenge 5 | |||
challenge 6 | ||||
credentials 6 | credentials 6 | |||
Proxy-Authenticate 11 | Proxy-Authenticate 10 | |||
Proxy-Authorization 11 | ||||
WWW-Authenticate 12 | ||||
H | ||||
Header Fields | ||||
Authorization 10 | ||||
Proxy-Authenticate 11 | ||||
Proxy-Authorization 11 | Proxy-Authorization 11 | |||
WWW-Authenticate 12 | token68 5 | |||
WWW-Authenticate 11 | ||||
P | P | |||
Protection Space 7 | Protection Space 6 | |||
Proxy-Authenticate header field 11 | Proxy-Authenticate header field 10 | |||
Proxy-Authorization header field 11 | Proxy-Authorization header field 10 | |||
R | R | |||
Realm 7 | Realm 6 | |||
S | ||||
Status Codes | ||||
401 Unauthorized 9 | ||||
407 Proxy Authentication Required 10 | ||||
W | W | |||
WWW-Authenticate header field 12 | WWW-Authenticate header field 11 | |||
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 | |||
URI: http://roy.gbiv.com/ | URI: http://roy.gbiv.com/ | |||
Yves Lafon (editor) | ||||
World Wide Web Consortium | ||||
W3C / ERCIM | ||||
2004, rte des Lucioles | ||||
Sophia-Antipolis, AM 06902 | ||||
France | ||||
EMail: ylafon@w3.org | ||||
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 | |||
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. 39 change blocks. | ||||
140 lines changed or deleted | 88 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |