draft-ietf-httpbis-p7-auth-22.txt   draft-ietf-httpbis-p7-auth-23.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 February 23, 2013 Intended status: Standards Track July 15, 2013
Expires: August 27, 2013 Expires: January 16, 2014
Hypertext Transfer Protocol (HTTP/1.1): Authentication Hypertext Transfer Protocol (HTTP/1.1): Authentication
draft-ietf-httpbis-p7-auth-22 draft-ietf-httpbis-p7-auth-23
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.3. The changes in this draft are summarized in Appendix D.4.
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 August 27, 2013. This Internet-Draft will expire on January 16, 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 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2. Access Authentication Framework . . . . . . . . . . . . . . . 4 2. Access Authentication Framework . . . . . . . . . . . . . . . 4
2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4 2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4
2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6
2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
2.3.1. Considerations for New Authentication Schemes . . . . 7 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7
3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 8
4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 8
4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9
4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 10 5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 11 5.1.2. Considerations for New Authentication Schemes . . . . 10
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11 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 . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14 Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 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
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 that can be used by a server to challenge a client request schemes that can be used by a server to challenge a client request
and by a client to provide authentication information. The "basic" and by a client to provide authentication information. The "basic"
and "digest" authentication schemes continue to be specified in RFC and "digest" authentication schemes continue to be specified 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].
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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
2.1. Challenge and Response 2.1. Challenge and Response
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication 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 an extensible, client to provide authentication information. It uses a case-
case-insensitive token to identify the authentication scheme, insensitive token as a means to identify the authentication scheme,
followed by additional information necessary for achieving followed by additional information necessary for achieving
authentication via that scheme. The latter can either be a comma- authentication via that scheme. The latter can either be a comma-
separated list of parameters or a single sequence of characters separated list of parameters or a single sequence of characters
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
skipping to change at page 6, line 4 skipping to change at page 6, line 4
-- can do so by including an Authorization header field with the -- can do so by including an Authorization header field with the
request. request.
A client that wishes to authenticate itself with a proxy -- usually, A client that wishes to authenticate itself with a proxy -- usually,
but not necessarily, after receiving a 407 (Proxy Authentication but not necessarily, after receiving a 407 (Proxy Authentication
Required) -- can do so by including a Proxy-Authorization header Required) -- can do so by including a Proxy-Authorization header
field with the request. field with the request.
Both the Authorization field value and the Proxy-Authorization field Both the Authorization field value and the Proxy-Authorization field
value 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 in a response
(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
skipping to change at page 6, line 30 skipping to change at page 6, line 30
omit credentials or contain invalid or partial credentials, a proxy omit credentials or contain invalid or partial credentials, a proxy
SHOULD send a 407 (Proxy Authentication Required) response that SHOULD send a 407 (Proxy Authentication Required) response that
contains a Proxy-Authenticate header field with a (possibly new) contains a Proxy-Authenticate header field with a (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 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 mechanism 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 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.
2.2. Protection Space (Realm) 2.2. Protection Space (Realm)
skipping to change at page 7, line 4 skipping to change at page 7, line 4
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 that can have additional semantics specific to the authentication
scheme. Note that there can be multiple challenges with the same scheme. Note that a response can have multiple challenges with the
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 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 specifically allowed by the authentication scheme, a single
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 use the quoted-string For historical reasons, senders 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.
2.3. Authentication Scheme Registry
The HTTP Authentication Scheme Registry defines the name space for
the authentication schemes in challenges and credentials.
Registrations MUST include the following fields:
o Authentication Scheme Name
o Pointer to specification text
o Notes (optional)
Values to be added to this name space require IETF Review (see
[RFC5226], Section 4.1).
The registry itself is maintained at
<http://www.iana.org/assignments/http-authschemes>.
2.3.1. Considerations for New Authentication Schemes
There are certain aspects of the HTTP Authentication Framework that
put constraints on how new authentication schemes can work:
o HTTP authentication is presumed to be stateless: all of the
information necessary to authenticate a request MUST be provided
in the request, rather than be dependent on the server remembering
prior requests. Authentication based on, or bound to, the
underlying connection is outside the scope of this specification
and inherently flawed unless steps are taken to ensure that the
connection cannot be used by any party other than the
authenticated user (see Section 2.3 of [Part1]).
o The authentication parameter "realm" is reserved for defining
Protection Spaces as defined in Section 2.2. New schemes MUST NOT
use it in a way incompatible with that definition.
o The "token68" notation was introduced for compatibility with
existing authentication schemes and can only be used once per
challenge/credentials. New schemes thus ought to use the "auth-
param" syntax instead, because otherwise future extensions will be
impossible.
o The parsing of challenges and credentials is defined by this
specification, and cannot be modified by new authentication
schemes. When the auth-param syntax is used, all parameters ought
to support both token and quoted-string syntax, and syntactical
constraints ought to be defined on the field value after parsing
(i.e., quoted-string processing). This is necessary so that
recipients can use a generic parser that applies to all
authentication schemes.
Note: The fact that the value syntax for the "realm" parameter is
restricted to quoted-string was a bad design choice not to be
repeated for new parameters.
o Definitions of new schemes ought to define the treatment of
unknown extension parameters. In general, a "must-ignore" rule is
preferable over "must-understand", because otherwise it will be
hard to introduce new parameters in the presence of legacy
recipients. Furthermore, it's good to describe the policy for
defining new parameters (such as "update the specification", or
"use this registry").
o Authentication schemes need to document whether they are usable in
origin-server authentication (i.e., using WWW-Authenticate),
and/or proxy authentication (i.e., using Proxy-Authenticate).
o The credentials carried in an Authorization header field are
specific to the User Agent, and therefore have the same effect on
HTTP caches as the "private" Cache-Control response directive,
within the scope of the request they appear in.
Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly
defined header field) will need to explicitly disallow caching, by
mandating the use of either Cache-Control request directives
(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 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
the target resource. The origin server MUST send a WWW-Authenticate the target resource. The origin server MUST send a WWW-Authenticate
header field (Section 4.4) containing at least one challenge header field (Section 4.4) containing at least one challenge
applicable to the target resource. If the request included applicable to the target resource. If the request included
authentication credentials, then the 401 response indicates that authentication credentials, then the 401 response indicates that
authorization has been refused for those credentials. The client MAY authorization has been refused for those credentials. The user agent
repeat the request with a new or replaced Authorization header field MAY repeat the request with a new or replaced Authorization header
(Section 4.1). If the 401 response contains the same challenge as field (Section 4.1). If the 401 response contains the same challenge
the prior response, and the user agent has already attempted as the prior response, and the user agent has already attempted
authentication at least once, then the user agent SHOULD present the authentication at least once, then the user agent SHOULD present the
enclosed representation to the user, since it usually contains enclosed representation to the user, since it usually contains
relevant diagnostic information. relevant diagnostic information.
3.2. 407 Proxy Authentication Required 3.2. 407 Proxy Authentication Required
The 407 (Proxy Authentication Required) status code is similar to 401 The 407 (Proxy Authentication Required) status code is similar to 401
(Unauthorized), but indicates that the client needs to authenticate (Unauthorized), but indicates that the client needs to authenticate
itself in order to use a proxy. The proxy MUST send a Proxy- itself in order to use a proxy. The proxy MUST send a Proxy-
Authenticate header field (Section 4.2) containing a challenge Authenticate header field (Section 4.2) containing a challenge
skipping to change at page 9, line 41 skipping to change at page 8, line 8
field (Section 4.3). 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 an origin server -- usually, but not necessarily, after
a 401 (Unauthorized) response. Its value consists of credentials receiving a 401 (Unauthorized) response. Its value consists of
containing information of the user agent for the realm of the credentials containing information of the user agent for the realm of
resource being requested. 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 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).
See Section 3.2 of [Part6] for details of and requirements pertaining See Section 3.2 of [Part6] for details of and requirements pertaining
skipping to change at page 10, line 33 skipping to change at page 8, line 49
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 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 user agent for the proxy and/or realm of the information of the client for the proxy and/or realm of the resource
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 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
outbound proxy that was expecting to receive credentials. A proxy outbound proxy that was expecting to receive credentials. A proxy
MAY relay the credentials from the client request to the next proxy MAY relay the credentials from the client request to the next proxy
if that is the mechanism by which the proxies cooperatively if that is the mechanism by which the proxies cooperatively
skipping to change at page 11, line 38 skipping to change at page 10, line 9
well. Therefore, a sequence of comma, whitespace, and comma can well. Therefore, a sequence of comma, whitespace, and comma can
be considered both as applying to the preceding challenge, or to be considered both as applying to the preceding challenge, or to
be an empty entry in the list of challenges. In practice, this be an empty entry in the list of challenges. In practice, this
ambiguity does not affect the semantics of the header field value ambiguity does not affect the semantics of the header field value
and thus is harmless. and thus is harmless.
5. IANA Considerations 5. IANA Considerations
5.1. Authentication Scheme Registry 5.1. Authentication Scheme Registry
The registration procedure for HTTP Authentication Schemes is defined The HTTP Authentication Scheme Registry defines the name space for
by Section 2.3 of this document. the authentication schemes in challenges and credentials. It will be
created and maintained at
The HTTP Method Authentication Scheme shall be created at
<http://www.iana.org/assignments/http-authschemes>. <http://www.iana.org/assignments/http-authschemes>.
5.1.1. Procedure
Registrations MUST include the following fields:
o Authentication Scheme Name
o Pointer to specification text
o Notes (optional)
Values to be added to this name space require IETF Review (see
[RFC5226], Section 4.1).
5.1.2. Considerations for New Authentication Schemes
There are certain aspects of the HTTP Authentication Framework that
put constraints on how new authentication schemes can work:
o HTTP authentication is presumed to be stateless: all of the
information necessary to authenticate a request MUST be provided
in the request, rather than be dependent on the server remembering
prior requests. Authentication based on, or bound to, the
underlying connection is outside the scope of this specification
and inherently flawed unless steps are taken to ensure that the
connection cannot be used by any party other than the
authenticated user (see Section 2.3 of [Part1]).
o The authentication parameter "realm" is reserved for defining
Protection Spaces as defined in Section 2.2. New schemes MUST NOT
use it in a way incompatible with that definition.
o The "token68" notation was introduced for compatibility with
existing authentication schemes and can only be used once per
challenge or credential. New schemes thus ought to use the "auth-
param" syntax instead, because otherwise future extensions will be
impossible.
o The parsing of challenges and credentials is defined by this
specification, and cannot be modified by new authentication
schemes. When the auth-param syntax is used, all parameters ought
to support both token and quoted-string syntax, and syntactical
constraints ought to be defined on the field value after parsing
(i.e., quoted-string processing). This is necessary so that
recipients can use a generic parser that applies to all
authentication schemes.
Note: The fact that the value syntax for the "realm" parameter is
restricted to quoted-string was a bad design choice not to be
repeated for new parameters.
o Definitions of new schemes ought to define the treatment of
unknown extension parameters. In general, a "must-ignore" rule is
preferable over "must-understand", because otherwise it will be
hard to introduce new parameters in the presence of legacy
recipients. Furthermore, it's good to describe the policy for
defining new parameters (such as "update the specification", or
"use this registry").
o Authentication schemes need to document whether they are usable in
origin-server authentication (i.e., using WWW-Authenticate),
and/or proxy authentication (i.e., using Proxy-Authenticate).
o The credentials carried in an Authorization header field are
specific to the User Agent, and therefore have the same effect on
HTTP caches as the "private" Cache-Control response directive
(Section 7.2.2.6 of [Part6]), within the scope of the request they
appear in.
Therefore, new authentication schemes that choose not to carry
credentials in the Authorization header field (e.g., using a newly
defined header field) will need to explicitly disallow caching, by
mandating the use of either Cache-Control request directives
(e.g., "no-store", Section 7.2.1.5 of [Part6]) or response
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 |
+-------+-------------------------------+-------------+ +-------+-------------------------------+-------------+
| 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/ HTTP header fields are registered within the Message Header Field
assignments/message-headers/message-header-index.html> shall be Registry maintained at <http://www.iana.org/assignments/
updated with the permanent registrations below (see [BCP90]): message-headers/message-header-index.html>.
This document defines the following HTTP header fields, so their
associated registry entries shall be updated according to 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 |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
skipping to change at page 13, line 18 skipping to change at page 13, line 22
password protection in screen savers, idle time-outs, and other password protection in screen savers, idle time-outs, and other
methods that mitigate the security problems inherent in this problem. methods that mitigate the security problems inherent in this problem.
In particular, user agents that cache credentials are encouraged to In particular, user agents that cache credentials are encouraged to
provide a readily accessible mechanism for discarding cached provide a readily accessible mechanism for discarding 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 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 server. authentication credentials for other resources on the same origin
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.
This is of particular concern when a server hosts resources for This is of particular concern when an origin server hosts resources
multiple parties under the same canonical root URI (Section 2.2). for multiple parties under the same canonical root URI (Section 2.2).
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 (or port number) 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.
skipping to change at page 13, line 44 skipping to change at page 14, line 4
Authentication Framework, previously defined in RFC 2617. We thank Authentication Framework, previously defined in RFC 2617. We thank
John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
their work on that specification. See Section 6 of [RFC2617] for their work on that specification. See Section 6 of [RFC2617] for
further acknowledgements. further acknowledgements.
See Section 9 of [Part1] for the Acknowledgments related to this See Section 9 of [Part1] for the Acknowledgments related to this
document revision. document revision.
8. References 8. References
8.1. Normative References 8.1. Normative References
[Part1] Fielding, R., Ed. 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-22 (work in progress), draft-ietf-httpbis-p1-messaging-23 (work in progress),
February 2013. July 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-22 (work in progress), draft-ietf-httpbis-p2-semantics-23 (work in progress),
February 2013. July 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-22 (work in progress), draft-ietf-httpbis-p6-cache-23 (work in progress),
February 2013. July 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 15, line 13 skipping to change at page 15, line 20
The "realm" parameter is no longer always required on challenges; 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)
This specification introduces the Authentication Scheme Registry, This specification introduces the Authentication Scheme Registry,
along with considerations for new authentication schemes. along with considerations for new authentication schemes.
(Section 2.3) (Section 5.1)
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.3> BWS = <BWS, defined in [Part1], Section 3.2.3>
OWS = <OWS, defined in [Part1], Section 3.2.3> OWS = <OWS, defined in [Part1], Section 3.2.3>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
token = <token, defined in [Part1], Section 3.2.6> token = <token, defined in [Part1], Section 3.2.6>
Appendix C. Collected ABNF Appendix C. Collected ABNF
In the collected ABNF below, list rules are expanded as per Section
1.2 of [Part1].
Authorization = credentials Authorization = credentials
BWS = <BWS, defined in [Part1], Section 3.2.3> BWS = <BWS, defined in [Part1], Section 3.2.3>
OWS = <OWS, defined in [Part1], Section 3.2.3> 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
skipping to change at page 17, line 30 skipping to change at page 17, line 27
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 D.3. Since draft-ietf-httpbis-p7-auth-21
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>:
"Authentication and caching - max-age" "Authentication and caching - max-age"
D.4. Since draft-ietf-httpbis-p7-auth-22
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
expansion in ABNF appendices"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology:
mechanism vs framework vs scheme"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial
suggestions"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of
extension point considerations"
Index Index
4 4
401 Unauthorized (status code) 9 401 Unauthorized (status code) 7
407 Proxy Authentication Required (status code) 9 407 Proxy Authentication Required (status code) 7
A A
Authorization header field 9 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 9 Authorization 8
challenge 5 challenge 5
credentials 6 credentials 6
Proxy-Authenticate 10 Proxy-Authenticate 8
Proxy-Authorization 10 Proxy-Authorization 8
token68 5 token68 5
WWW-Authenticate 11 WWW-Authenticate 9
P P
Protection Space 6 Protection Space 6
Proxy-Authenticate header field 10 Proxy-Authenticate header field 8
Proxy-Authorization header field 10 Proxy-Authorization header field 8
R R
Realm 6 Realm 6
W W
WWW-Authenticate header field 10 WWW-Authenticate header field 9
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. 42 change blocks. 
152 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/