< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/