< draft-ietf-httpbis-p7-auth-21.txt   draft-ietf-httpbis-p7-auth-22.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 October 4, 2012 Intended status: Standards Track February 23, 2013
Expires: April 7, 2013 Expires: August 27, 2013
Hypertext Transfer Protocol (HTTP/1.1): Authentication Hypertext Transfer Protocol (HTTP/1.1): Authentication
draft-ietf-httpbis-p7-auth-21 draft-ietf-httpbis-p7-auth-22
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.2. The changes in this draft are summarized in Appendix D.3.
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 April 7, 2013. This Internet-Draft will expire on August 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 22 skipping to change at page 3, line 22
2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6
2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7
2.3.1. Considerations for New Authentication Schemes . . . . 7 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 . . . . . . . . . . . . 9 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9
4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10
4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10
4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 11
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11
5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 5.3. Header Field Registration . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Authentication Credentials and Idle Clients . . . . . . . 13 6.1. Authentication Credentials and Idle Clients . . . . . . . 12
6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13 6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . 14
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 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) . . . . . . . . . . . . . . . . . . . . 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
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
mechanisms which can be used by a server to challenge a client mechanisms that can be used by a server to challenge a client request
request and by a client to provide authentication information. The and by a client to provide authentication information. The "basic"
"basic" and "digest" authentication schemes continue to be specified and "digest" authentication schemes continue to be specified in RFC
in RFC 2617. 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].
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].
skipping to change at page 6, line 15 skipping to change at page 6, line 15
(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 ( token68 / #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 send a 401 (Unauthorized)
response. Such responses MUST include a WWW-Authenticate header response that contains a WWW-Authenticate header field with at least
field containing at least one (possibly new) challenge applicable to 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 send a 407 (Proxy Authentication Required) response that
responses MUST include a Proxy-Authenticate header field containing a contains a Proxy-Authenticate header field with a (possibly new)
(possibly new) challenge applicable to the proxy. 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 7.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 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 7, line 4 skipping to change at page 6, line 51
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,
which can have additional semantics specific to the authentication that can have additional semantics specific to the authentication
scheme. Note that there can be multiple challenges with the same scheme. Note that there can be multiple challenges with the same
auth-scheme but different realms. 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 same credentials MAY be reused for all other requests within that
protection space for a period of time determined by the 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
otherwise defined by the authentication scheme, a single protection otherwise defined by the authentication scheme, a single protection
space cannot extend outside the scope of its server. space cannot extend outside the scope of its server.
skipping to change at page 8, line 46 skipping to change at page 8, line 45
o Authentication schemes need to document whether they are usable in o Authentication schemes need to document whether they are usable in
origin-server authentication (i.e., using WWW-Authenticate), origin-server authentication (i.e., using WWW-Authenticate),
and/or proxy authentication (i.e., using Proxy-Authenticate). and/or proxy authentication (i.e., using Proxy-Authenticate).
o The credentials carried in an Authorization header field are o The credentials carried in an Authorization header field are
specific to the User Agent, and therefore have the same effect on specific to the User Agent, and therefore have the same effect on
HTTP caches as the "private" Cache-Control response directive, HTTP caches as the "private" Cache-Control response directive,
within the scope of the request they appear in. within the scope of the request they appear in.
Therefore, new authentication schemes which choose not to carry Therefore, new authentication schemes 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") or response directives (e.g., "private"). (e.g., "no-store") or response directives (e.g., "private").
3. Status Code Definitions 3. Status Code Definitions
3.1. 401 Unauthorized 3.1. 401 Unauthorized
The request requires user authentication. The response MUST include The 401 (Unauthorized) status code indicates that the request has not
a WWW-Authenticate header field (Section 4.4) containing a challenge been applied because it lacks valid authentication credentials for
applicable to the target resource. The client MAY repeat the request the target resource. The origin server MUST send a WWW-Authenticate
with a suitable Authorization header field (Section 4.1). If the header field (Section 4.4) containing at least one challenge
request already included Authorization credentials, then the 401 applicable to the target resource. If the request included
response indicates that authorization has been refused for those authentication credentials, then the 401 response indicates that
credentials. If the 401 response contains the same challenge as the authorization has been refused for those credentials. The client MAY
prior response, and the user agent has already attempted repeat the request with a new or replaced Authorization header field
authentication at least once, then the user SHOULD be presented the (Section 4.1). If the 401 response contains the same challenge as
representation that was given in the response, since that the prior response, and the user agent has already attempted
representation might include relevant diagnostic information. authentication at least once, then the user agent SHOULD present the
enclosed representation to the user, since it usually contains
relevant diagnostic information.
3.2. 407 Proxy Authentication Required 3.2. 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that the The 407 (Proxy Authentication Required) status code is similar to 401
client ought to first authenticate itself with the proxy. The proxy (Unauthorized), but indicates that the client needs to authenticate
MUST return a Proxy-Authenticate header field (Section 4.2) itself in order to use a proxy. The proxy MUST send a Proxy-
containing a challenge applicable to the proxy for the target Authenticate header field (Section 4.2) containing a challenge
resource. The client MAY repeat the request with a suitable Proxy- applicable to that proxy for the target resource. The client MAY
Authorization header field (Section 4.3). repeat the request with a new or replaced Proxy-Authorization header
field (Section 4.3).
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 a server -- usually, but not necessarily, after receiving itself with a server -- usually, but not necessarily, after receiving
skipping to change at page 9, line 51 skipping to change at page 10, line 5
resource being requested. 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 SHOULD be valid for all other requests within this realm
(assuming that the authentication scheme itself does not require (assuming that the authentication scheme itself does not require
otherwise, such as credentials that vary according to a challenge otherwise, such as credentials that vary according to a challenge
value or using synchronized clocks). value or using synchronized clocks).
When a shared cache (see Section 1.2 of [Part6]) receives a request See Section 3.2 of [Part6] for details of and requirements pertaining
containing an Authorization field, it MUST NOT return the to handling of the Authorization field by HTTP caches.
corresponding response as a reply to any other request, unless one of
the following specific exceptions holds:
1. If the response includes the "s-maxage" cache-control directive,
the cache MAY use that response in replying to a subsequent
request. But (if the specified maximum age has passed) a proxy
cache MUST first revalidate it with the origin server, using the
header fields from the new request to allow the origin server to
authenticate the new request. (This is the defined behavior for
s-maxage.) If the response includes "s-maxage=0", the proxy MUST
always revalidate it before re-using it.
2. If the response includes the "must-revalidate" cache-control
directive, the cache MAY use that response in replying to a
subsequent request. But if the response is stale, all caches
MUST first revalidate it with the origin server, using the header
fields from the new request to allow the origin server to
authenticate the new request.
3. If the response includes the "public" cache-control directive, it
MAY be returned in reply to any subsequent request.
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
skipping to change at page 10, line 49 skipping to change at page 10, line 31
to obtain its own credentials by requesting them from the downstream to obtain its own credentials by requesting them from the downstream
client, which in some circumstances will appear as if the proxy is client, which in some circumstances will appear as if the proxy is
forwarding the Proxy-Authenticate header field. forwarding the Proxy-Authenticate header field.
Note that the parsing considerations for WWW-Authenticate apply to Note that the parsing considerations for WWW-Authenticate apply to
this header field as well; see Section 4.4 for details. this header field as well; see Section 4.4 for details.
4.3. Proxy-Authorization 4.3. Proxy-Authorization
The "Proxy-Authorization" header field allows the client to identify The "Proxy-Authorization" header field allows the client to identify
itself (or its user) to a proxy which requires authentication. Its itself (or its user) to a proxy that requires authentication. Its
value consists of credentials containing the authentication value consists of credentials containing the authentication
information of the user agent for the proxy and/or realm of the information of the user agent for the proxy and/or realm of the
resource being requested. resource 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 outbound proxy that demanded authentication using
the Proxy-Authenticate field. When multiple proxies are used in a the Proxy-Authenticate field. When multiple proxies are used in a
chain, the Proxy-Authorization header field is consumed by the first chain, the Proxy-Authorization header field is consumed by the first
skipping to change at page 12, line 32 skipping to change at page 12, line 16
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------+-------------+ +-------+-------------------------------+-------------+
| 401 | Unauthorized | Section 3.1 | | 401 | Unauthorized | Section 3.1 |
| 407 | Proxy Authentication Required | Section 3.2 | | 407 | Proxy Authentication Required | Section 3.2 |
+-------+-------------------------------+-------------+ +-------+-------------------------------+-------------+
5.3. Header Field Registration 5.3. Header Field Registration
The Message Header Field Registry located at <http://www.iana.org/ The Message Header Field Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> shall be assignments/message-headers/message-header-index.html> shall be
updated with the permanent registrations below (see [RFC3864]): updated with the permanent registrations below (see [BCP90]):
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
| Authorization | http | standard | Section 4.1 | | Authorization | http | standard | Section 4.1 |
| Proxy-Authenticate | http | standard | Section 4.2 | | Proxy-Authenticate | http | standard | Section 4.2 |
| Proxy-Authorization | http | standard | Section 4.3 | | Proxy-Authorization | http | standard | Section 4.3 |
| WWW-Authenticate | http | standard | Section 4.4 | | WWW-Authenticate | http | standard | Section 4.4 |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
6. Security Considerations 6. Security Considerations
This section is meant to inform application developers, information This section is meant to inform developers, information providers,
providers, and users of the security limitations in HTTP/1.1 as and users of known security concerns specific to HTTP/1.1
described by this document. The discussion does not include authentication. More general security considerations are addressed
definitive solutions to the problems revealed, though it does make in HTTP messaging [Part1] and semantics [Part2].
some suggestions for reducing security risks.
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/1.1 does not provide a method for a
server to direct clients to discard these cached credentials. This server to direct clients to discard these cached credentials. This
is a significant defect that requires further extensions to HTTP. is a significant defect that requires further extensions to HTTP.
Circumstances under which credential caching can interfere with the Circumstances under which credential caching can interfere with the
application's security model include but are not limited to: application's security model include but are not limited to:
o Clients which have been idle for an extended period following o Clients that have been idle for an extended period, following
which the server might wish to cause the client to reprompt the which the server might wish to cause the client to re-prompt the
user for credentials. user for credentials.
o Applications which 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- This is currently under separate study. There are a number of work-
arounds to parts of this problem, and we encourage the use of arounds to parts of this problem, and we encourage the use of
password protection in screen savers, idle time-outs, and other password protection in screen savers, idle time-outs, and other
methods which mitigate the security problems inherent in this methods that mitigate the security problems inherent in this problem.
problem. In particular, user agents which cache credentials are In particular, user agents that cache credentials are encouraged to
encouraged to provide a readily accessible mechanism for discarding provide a readily accessible mechanism for discarding cached
cached credentials under user control. 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 a server. Clients that have successfully made resources on a 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 server. authentication credentials for other resources on the same server.
This makes it possible for a different resource to harvest 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 14, line 18 skipping to change at page 13, line 49
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. 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-21 (work in progress), draft-ietf-httpbis-p1-messaging-22 (work in progress),
October 2012. February 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-21 (work in progress), draft-ietf-httpbis-p2-semantics-22 (work in progress),
October 2012. February 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-21 (work in progress), draft-ietf-httpbis-p6-cache-22 (work in progress),
October 2012. February 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
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[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 framework for HTTP Authentication is now defined by this
document, rather than RFC 2617.
The "realm" parameter is no longer always required on challenges;
consequently, the ABNF allows challenges without any auth parameters. consequently, the ABNF allows challenges without any auth parameters.
(Section 2) (Section 2)
The "token68" 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) This specification introduces the Authentication Scheme Registry,
along with considerations for new authentication schemes.
(Section 2.3)
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]:
BWS = <BWS, defined in [Part1], Section 3.2.1> BWS = <BWS, defined in [Part1], Section 3.2.3>
OWS = <OWS, defined in [Part1], Section 3.2.1> OWS = <OWS, defined in [Part1], Section 3.2.3>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
token = <token, defined in [Part1], Section 3.2.4> token = <token, defined in [Part1], Section 3.2.6>
Appendix C. Collected ABNF Appendix C. Collected ABNF
Authorization = credentials Authorization = credentials
BWS = <BWS, defined in [Part1], Section 3.2.1> BWS = <BWS, defined in [Part1], Section 3.2.3>
OWS = <OWS, defined in [Part1], Section 3.2.1> OWS = <OWS, defined in [Part1], Section 3.2.3>
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
challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *( challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
OWS "," [ OWS auth-param ] ) ] ) ] OWS "," [ OWS auth-param ] ) ] ) ]
credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / 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.6>
token = <token, defined in [Part1], Section 3.2.4> token = <token, defined in [Part1], Section 3.2.6>
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) 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
skipping to change at page 17, line 23 skipping to change at page 17, line 23
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename
b64token for clarity" b64token for clarity"
Other changes: Other changes:
o Conformance criteria and considerations regarding error handling o Conformance criteria and considerations regarding error handling
are now defined in Part 1. are now defined in Part 1.
D.3. Since draft-ietf-httpbis-p7-auth-21
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>:
"Authentication and caching - max-age"
Index Index
4 4
401 Unauthorized (status code) 9 401 Unauthorized (status code) 9
407 Proxy Authentication Required (status code) 9 407 Proxy Authentication Required (status code) 9
A A
Authorization header field 9 Authorization header field 9
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 9 Authorization 9
challenge 5 challenge 5
credentials 6 credentials 6
Proxy-Authenticate 10 Proxy-Authenticate 10
Proxy-Authorization 11 Proxy-Authorization 10
token68 5 token68 5
WWW-Authenticate 11 WWW-Authenticate 11
P P
Protection Space 6 Protection Space 6
Proxy-Authenticate header field 10 Proxy-Authenticate header field 10
Proxy-Authorization header field 10 Proxy-Authorization header field 10
R R
Realm 6 Realm 6
W W
WWW-Authenticate header field 11 WWW-Authenticate header field 10
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
 End of changes. 40 change blocks. 
104 lines changed or deleted 97 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/
X-Generator: pyht 0.35