draft-ietf-httpbis-p7-auth-23.txt   draft-ietf-httpbis-p7-auth-24.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 (if approved) J. Reschke, Ed.
Updates: 2617 (if approved) greenbytes Updates: 2617 (if approved) greenbytes
Intended status: Standards Track July 15, 2013 Intended status: Standards Track September 25, 2013
Expires: January 16, 2014 Expires: March 29, 2014
Hypertext Transfer Protocol (HTTP/1.1): Authentication Hypertext Transfer Protocol (HTTP/1.1): Authentication
draft-ietf-httpbis-p7-auth-23 draft-ietf-httpbis-p7-auth-24
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.4. The changes in this draft are summarized in Appendix D.5.
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 16, 2014. This Internet-Draft will expire on March 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 43 skipping to change at page 3, line 43
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15 Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 16 publication) . . . . . . . . . . . . . . . . . . . . 16
D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16 D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16
D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17 D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17
D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17 D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17
D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17 D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 D.5. Since draft-ietf-httpbis-p7-auth-23 . . . . . . . . . . . 17
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
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 32 skipping to change at page 4, line 32
"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].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5 of [Part1]. defined in Section 2.5 of [Part1].
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 7 of [Part1]. Appendix B describes rules imported from other
documents. Appendix C shows the collected ABNF with the list rule documents. Appendix C shows the collected ABNF with the list rule
expanded. expanded.
2. Access Authentication Framework 2. Access Authentication Framework
2.1. Challenge and Response 2.1. Challenge and Response
HTTP provides a simple challenge-response authentication framework HTTP provides a simple challenge-response authentication framework
that can be used by a server to challenge a client request and by a that can be used by a server to challenge a client request and by a
client to provide authentication information. It uses a case- client to provide authentication information. It uses a case-
skipping to change at page 6, line 36 skipping to change at page 6, line 36
gain access, ought to respond with the 403 (Forbidden) status code gain access, ought to respond with the 403 (Forbidden) status code
(Section 6.5.3 of [Part2]). (Section 6.5.3 of [Part2]).
The HTTP protocol does not restrict applications to this simple The HTTP protocol does not restrict applications to this simple
challenge-response framework for access authentication. Additional challenge-response framework for access authentication. Additional
mechanisms MAY be used, such as encryption at the transport level or mechanisms MAY be used, such as encryption at the transport level or
via message encapsulation, and with additional header fields via message encapsulation, and with additional header fields
specifying authentication information. However, such additional specifying authentication information. However, such additional
mechanisms are not defined by this specification. mechanisms are not defined by this specification.
Proxies MUST forward the WWW-Authenticate and Authorization header A proxy MUST forward the WWW-Authenticate and Authorization header
fields unmodified and follow the rules found in Section 4.1. fields unmodified and follow the rules found in Section 4.1.
2.2. Protection Space (Realm) 2.2. Protection Space (Realm)
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
on a server to be partitioned into a set of protection spaces, each on a server to be partitioned into a set of protection spaces, each
with its own authentication scheme and/or authorization database. with its own authentication scheme and/or authorization database.
The realm value is a string, generally assigned by the origin server, The realm value is a string, generally assigned by the origin server,
that can have additional semantics specific to the authentication which can have additional semantics specific to the authentication
scheme. Note that a response can have multiple challenges with the scheme. Note that a response can have multiple challenges with the
same auth-scheme but different realms. same auth-scheme but different realms.
The protection space determines the domain over which credentials can The protection space determines the domain over which credentials can
be automatically applied. If a prior request has been authorized, be automatically applied. If a prior request has been authorized,
the same credentials MAY be reused for all other requests within that the user agent MAY reuse the same credentials for all other requests
protection space for a period of time determined by the within that protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless authentication scheme, parameters, and/or user preference. Unless
specifically allowed by the authentication scheme, a single specifically allowed by the authentication scheme, a single
protection space cannot extend outside the scope of its server. protection space cannot extend outside the scope of its server.
For historical reasons, senders MUST only generate the quoted-string For historical reasons, a sender MUST only generate the quoted-string
syntax. Recipients might have to support both token and quoted- syntax. Recipients might have to support both token and quoted-
string syntax for maximum interoperability with existing clients that string syntax for maximum interoperability with existing clients that
have been accepting both notations for a long time. have been accepting both notations for a long time.
3. Status Code Definitions 3. Status Code Definitions
3.1. 401 Unauthorized 3.1. 401 Unauthorized
The 401 (Unauthorized) status code indicates that the request has not The 401 (Unauthorized) status code indicates that the request has not
been applied because it lacks valid authentication credentials for been applied because it lacks valid authentication credentials for
skipping to change at page 8, line 10 skipping to change at page 8, line 10
4. Header Field Definitions 4. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to authentication. fields related to authentication.
4.1. Authorization 4.1. Authorization
The "Authorization" header field allows a user agent to authenticate The "Authorization" header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after itself with an origin server -- usually, but not necessarily, after
receiving a 401 (Unauthorized) response. Its value consists of receiving a 401 (Unauthorized) response. Its value consists of
credentials containing information of the user agent for the realm of credentials containing the authentication information of the user
the resource being requested. agent for the realm of the resource being requested.
Authorization = credentials Authorization = credentials
If a request is authenticated and a realm specified, the same If a request is authenticated and a realm specified, the same
credentials SHOULD be valid for all other requests within this realm credentials are presumed to be valid for all other requests within
(assuming that the authentication scheme itself does not require this realm (assuming that the authentication scheme itself does not
otherwise, such as credentials that vary according to a challenge require otherwise, such as credentials that vary according to a
value or using synchronized clocks). challenge value or using synchronized clocks).
See Section 3.2 of [Part6] for details of and requirements pertaining See Section 3.2 of [Part6] for details of and requirements pertaining
to handling of the Authorization field by HTTP caches. to handling of the Authorization field by HTTP caches.
4.2. Proxy-Authenticate 4.2. Proxy-Authenticate
The "Proxy-Authenticate" header field consists of at least one The "Proxy-Authenticate" header field consists of at least one
challenge that indicates the authentication scheme(s) and parameters challenge that indicates the authentication scheme(s) and parameters
applicable to the proxy for this effective request URI (Section 5.5 applicable to the proxy for this effective request URI (Section 5.5
of [Part1]). It MUST be included as part of a 407 (Proxy of [Part1]). It MUST be included as part of a 407 (Proxy
Authentication Required) response. Authentication Required) response.
Proxy-Authenticate = 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 intermediaries SHOULD NOT forward only to the next outbound client on the response chain that chose to
it to downstream clients. However, an intermediate proxy might need direct its request to the responding proxy. If that recipient is
to obtain its own credentials by requesting them from the downstream also a proxy, it will generally consume the Proxy-Authenticate header
client, which in some circumstances will appear as if the proxy is field (and generate an appropriate Proxy-Authorization in a
forwarding the Proxy-Authenticate header field. subsequent request) rather than forward the header field to its own
outbound clients. However, if a recipient proxy needs to obtain its
own credentials by requesting them from a further outbound client, it
will generate its own 407 response, which might have the appearance
of forwarding the Proxy-Authenticate header field if both proxies use
the same challenge set.
Note that the parsing considerations for WWW-Authenticate apply to Note that the parsing considerations for WWW-Authenticate apply to
this header field as well; see Section 4.4 for details. this header field as well; see Section 4.4 for details.
4.3. Proxy-Authorization 4.3. Proxy-Authorization
The "Proxy-Authorization" header field allows the client to identify The "Proxy-Authorization" header field allows the client to identify
itself (or its user) to a proxy that requires authentication. Its itself (or its user) to a proxy that requires authentication. Its
value consists of credentials containing the authentication value consists of credentials containing the authentication
information of the client for the proxy and/or realm of the resource information of the client for the proxy and/or realm of the resource
being requested. being requested.
Proxy-Authorization = credentials Proxy-Authorization = credentials
Unlike Authorization, the Proxy-Authorization header field applies Unlike Authorization, the Proxy-Authorization header field applies
only to the next outbound proxy that demanded authentication using only to the next inbound proxy that demanded authentication using the
the Proxy-Authenticate field. When multiple proxies are used in a Proxy-Authenticate field. When multiple proxies are used in a chain,
chain, the Proxy-Authorization header field is consumed by the first the Proxy-Authorization header field is consumed by the first inbound
outbound proxy that was expecting to receive credentials. A proxy proxy that was expecting to receive credentials. A proxy MAY relay
MAY relay the credentials from the client request to the next proxy the credentials from the client request to the next proxy if that is
if that is the mechanism by which the proxies cooperatively the mechanism by which the proxies cooperatively authenticate a given
authenticate a given request. request.
4.4. WWW-Authenticate 4.4. WWW-Authenticate
The "WWW-Authenticate" header field consists of at least one The "WWW-Authenticate" header field consists of at least one
challenge that indicates the authentication scheme(s) and parameters challenge that indicates the authentication scheme(s) and parameters
applicable to the effective request URI (Section 5.5 of [Part1]). applicable to the effective request URI (Section 5.5 of [Part1]).
It MUST be included in 401 (Unauthorized) response messages and MAY It MUST be included in 401 (Unauthorized) response messages and MAY
be included in other response messages to indicate that supplying be included in other response messages to indicate that supplying
credentials (or different credentials) might affect the response. credentials (or different credentials) might affect the response.
skipping to change at page 11, line 30 skipping to change at page 11, line 33
defining new parameters (such as "update the specification", or defining new parameters (such as "update the specification", or
"use this registry"). "use this registry").
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
(Section 7.2.2.6 of [Part6]), within the scope of the request they (Section 5.2.2.6 of [Part6]), within the scope of the request they
appear in. appear in.
Therefore, new authentication schemes that choose not to carry Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly credentials in the Authorization header field (e.g., using a newly
defined header field) 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", Section 7.2.1.5 of [Part6]) or response (e.g., "no-store", Section 5.2.1.5 of [Part6]) or response
directives (e.g., "private"). directives (e.g., "private").
5.2. Status Code Registration 5.2. Status Code Registration
The HTTP Status Code Registry located at The HTTP Status Code Registry located at
<http://www.iana.org/assignments/http-status-codes> shall be updated <http://www.iana.org/assignments/http-status-codes> shall be updated
with the registrations below: with the registrations below:
+-------+-------------------------------+-------------+ +-------+-------------------------------+-------------+
| Value | Description | Reference | | Value | Description | Reference |
skipping to change at page 12, line 44 skipping to change at page 12, line 44
6. Security Considerations 6. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns specific to HTTP/1.1 and users of known security concerns specific to HTTP/1.1
authentication. More general security considerations are addressed authentication. More general security considerations are addressed
in HTTP messaging [Part1] and semantics [Part2]. in HTTP messaging [Part1] and semantics [Part2].
6.1. Authentication Credentials and Idle Clients 6.1. Authentication Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP/1.1 does not provide a method for a information indefinitely. HTTP does not provide a mechanism for the
server to direct clients to discard these cached credentials. This origin server to direct clients to discard these cached credentials,
is a significant defect that requires further extensions to HTTP. since the protocol has no awareness of how credentials are obtained
or managed by the user agent. The mechanisms for expiring or
revoking credentials can be specified as part of an authentication
scheme definition.
Circumstances under which credential caching can interfere with the Circumstances under which credential caching can interfere with the
application's security model include but are not limited to: application's security model include but are not limited to:
o Clients that have been idle for an extended period, following o Clients that have been idle for an extended period, following
which the server might wish to cause the client to re-prompt the which the server might wish to cause the client to re-prompt the
user for credentials. user for credentials.
o Applications that include a session termination indication (such o Applications that include a session termination indication (such
as a "logout" or "commit" button on a page) after which the server as a "logout" or "commit" button on a page) after which the server
side of the application "knows" that there is no further reason side of the application "knows" that there is no further reason
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- User agents that cache credentials are encouraged to provide a
arounds to parts of this problem, and we encourage the use of readily accessible mechanism for discarding cached credentials under
password protection in screen savers, idle time-outs, and other user control.
methods that mitigate the security problems inherent in this problem.
In particular, user agents that cache credentials are encouraged to
provide a readily accessible mechanism for discarding cached
credentials under user control.
6.2. Protection Spaces 6.2. Protection Spaces
Authentication schemes that solely rely on the "realm" mechanism for Authentication schemes that solely rely on the "realm" mechanism for
establishing a protection space will expose credentials to all establishing a protection space will expose credentials to all
resources on an origin server. Clients that have successfully made resources on an origin server. Clients that have successfully made
authenticated requests with a resource can use the same authenticated requests with a resource can use the same
authentication credentials for other resources on the same origin authentication credentials for other resources on the same origin
server. This makes it possible for a different resource to harvest server. This makes it possible for a different resource to harvest
authentication credentials for other resources. authentication credentials for other resources.
skipping to change at page 13, line 45 skipping to change at page 13, line 45
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 10 of [Part1] for the Acknowledgments related to this
document revision. document revision.
8. References 8. References
8.1. Normative References 8.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-23 (work in progress), draft-ietf-httpbis-p1-messaging-24 (work in progress),
July 2013. September 2013.
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-23 (work in progress), draft-ietf-httpbis-p2-semantics-24 (work in progress),
July 2013. September 2013.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-23 (work in progress), draft-ietf-httpbis-p6-cache-24 (work in progress),
July 2013. September 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
8.2. Informative References 8.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
skipping to change at page 17, line 43 skipping to change at page 17, line 43
o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology: o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology:
mechanism vs framework vs scheme" mechanism vs framework vs scheme"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial
suggestions" suggestions"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of
extension point considerations" extension point considerations"
D.5. Since draft-ietf-httpbis-p7-auth-23
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/473>: "Forwarding
Proxy-*"
Index Index
4 4
401 Unauthorized (status code) 7 401 Unauthorized (status code) 7
407 Proxy Authentication Required (status code) 7 407 Proxy Authentication Required (status code) 7
A A
Authorization header field 8 Authorization header field 8
C C
Canonical Root URI 6 Canonical Root URI 6
G G
Grammar Grammar
auth-param 5 auth-param 5
auth-scheme 5 auth-scheme 5
Authorization 8 Authorization 8
challenge 5 challenge 5
credentials 6 credentials 6
Proxy-Authenticate 8 Proxy-Authenticate 8
Proxy-Authorization 8 Proxy-Authorization 9
token68 5 token68 5
WWW-Authenticate 9 WWW-Authenticate 9
P P
Protection Space 6 Protection Space 6
Proxy-Authenticate header field 8 Proxy-Authenticate header field 8
Proxy-Authorization header field 8 Proxy-Authorization header field 8
R R
Realm 6 Realm 6
 End of changes. 24 change blocks. 
50 lines changed or deleted 63 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/