draft-ietf-httpbis-p7-auth-11.txt | draft-ietf-httpbis-p7-auth-12.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Day Software | Internet-Draft Day Software | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Updates: 2617 (if approved) Alcatel-Lucent | Updates: 2617 (if approved) Alcatel-Lucent | |||
Intended status: Standards Track J. Mogul | Intended status: Standards Track J. Mogul | |||
Expires: February 5, 2011 HP | Expires: April 28, 2011 HP | |||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe Systems | Adobe Systems | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
Y. Lafon, Ed. | Y. Lafon, Ed. | |||
W3C | W3C | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
August 4, 2010 | October 25, 2010 | |||
HTTP/1.1, part 7: Authentication | HTTP/1.1, part 7: Authentication | |||
draft-ietf-httpbis-p7-auth-11 | draft-ietf-httpbis-p7-auth-12 | |||
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. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document is Part 7 of the | information initiative since 1990. This document is Part 7 of the | |||
seven-part specification that defines the protocol referred to as | seven-part specification that defines the protocol referred to as | |||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines | |||
HTTP Authentication. | HTTP Authentication. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org). The current issues list is | group mailing list (ietf-http-wg@w3.org). The current issues list is | |||
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | at <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 B.12. | The changes in this draft are summarized in Appendix B.13. | |||
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 February 5, 2011. | This Internet-Draft will expire on April 28, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 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 | |||
skipping to change at page 3, line 10 | skipping to change at page 3, line 10 | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2.2. ABNF Rules defined in other Parts of the | 2. Access Authentication Framework . . . . . . . . . . . . . . . 5 | |||
Specification . . . . . . . . . . . . . . . . . . . . 5 | 2.1. Authentication Scheme Registry . . . . . . . . . . . . . . 7 | |||
2. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 | 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 | |||
2.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5 | 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 8 | |||
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 | 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 | |||
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 | 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 9 | |||
3.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 7 | 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 9 | |||
3.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 | 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 10 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.1. Status Code Registration . . . . . . . . . . . . . . . . . 8 | 5.1. Authenticaton Scheme Registry . . . . . . . . . . . . . . 10 | |||
4.2. Header Field Registration . . . . . . . . . . . . . . . . 8 | 5.2. Status Code Registration . . . . . . . . . . . . . . . . . 10 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 10 | |||
5.1. Authentication Credentials and Idle Clients . . . . . . . 9 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | 6.1. Authentication Credentials and Idle Clients . . . . . . . 11 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 | |||
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 10 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 | |||
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 13 | ||||
Appendix B. Change Log (to be removed by RFC Editor before | Appendix B. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 11 | publication) . . . . . . . . . . . . . . . . . . . . 14 | |||
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 11 | B.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 14 | |||
B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 11 | B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 14 | |||
B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 11 | B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 14 | |||
B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 11 | B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 14 | |||
B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 11 | B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 14 | |||
B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 11 | B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 14 | |||
B.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 12 | B.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 15 | |||
B.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 12 | B.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 15 | |||
B.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 12 | B.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 15 | |||
B.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 12 | B.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 15 | |||
B.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 12 | B.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 15 | |||
B.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 12 | B.12. Since draft-ietf-httpbis-p7-auth-10 . . . . . . . . . . . 15 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | B.13. Since draft-ietf-httpbis-p7-auth-11 . . . . . . . . . . . 15 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
1. Introduction | 1. Introduction | |||
This document defines HTTP/1.1 access control and authentication. | This document defines HTTP/1.1 access control and authentication. It | |||
Right now it includes the extracted relevant sections of RFC 2616 | includes the relevant parts of RFC 2616 with only minor changes, plus | |||
with only minor changes. The intention is to move the general | the general framework for HTTP authentication, as previously defined | |||
framework for HTTP authentication here, as currently specified in | in "HTTP Authentication: Basic and Digest Access Authentication" | |||
[RFC2617], and allow the individual authentication mechanisms to be | ([RFC2617]). | |||
defined elsewhere. This introduction will be rewritten when that | ||||
occurs. | ||||
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 which can be used by a server to challenge a client | |||
request and by a client to provide authentication information. The | request and by a client to provide authentication information. The | |||
general framework for access authentication, and the specification of | "basic" and "digest" authentication schemes continue to be specified | |||
"basic" and "digest" authentication, are specified in "HTTP | in RFC 2617. | |||
Authentication: Basic and Digest Access Authentication" [RFC2617]. | ||||
This specification adopts the definitions of "challenge" and | ||||
"credentials" from that specification. | ||||
1.1. Requirements | 1.1. Requirements | |||
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]. | |||
An implementation is not compliant if it fails to satisfy one or more | An implementation is not compliant if it fails to satisfy one or more | |||
of the "MUST" or "REQUIRED" level requirements for the protocols it | of the "MUST" or "REQUIRED" level requirements for the protocols it | |||
implements. An implementation that satisfies all the "MUST" or | implements. An implementation that satisfies all the "MUST" or | |||
skipping to change at page 5, line 9 | skipping to change at page 5, line 5 | |||
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | |||
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | |||
sequence of data), SP (space), VCHAR (any visible USASCII character), | sequence of data), SP (space), VCHAR (any visible USASCII character), | |||
and WSP (whitespace). | and WSP (whitespace). | |||
1.2.1. Core Rules | 1.2.1. Core Rules | |||
The core rules below are defined in Section 1.2.2 of [Part1]: | The core rules below are defined in Section 1.2.2 of [Part1]: | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | |||
token = <token, defined in [Part1], Section 1.2.2> | ||||
OWS = <OWS, defined in [Part1], Section 1.2.2> | ||||
1.2.2. ABNF Rules defined in other Parts of the Specification | 2. Access Authentication Framework | |||
The ABNF rules below are defined in other specifications: | HTTP provides a simple challenge-response authentication mechanism | |||
that can be used by a server to challenge a client request and by a | ||||
client to provide authentication information. It uses an extensible, | ||||
case-insensitive token to identify the authentication scheme, | ||||
followed by a comma-separated list of attribute-value pairs which | ||||
carry the parameters necessary for achieving authentication via that | ||||
scheme. | ||||
challenge = <challenge, defined in [RFC2617], Section 1.2> | auth-scheme = token | |||
credentials = <credentials, defined in [RFC2617], Section 1.2> | auth-param = token "=" ( token / quoted-string ) | |||
2. Status Code Definitions | The 401 (Unauthorized) response message is used by an origin server | |||
to challenge the authorization of a user agent. This response MUST | ||||
include a WWW-Authenticate header field containing at least one | ||||
challenge applicable to the requested resource. The 407 (Proxy | ||||
Authentication Required) response message is used by a proxy to | ||||
challenge the authorization of a client and MUST include a Proxy- | ||||
Authenticate header field containing at least one challenge | ||||
applicable to the proxy for the requested resource. | ||||
2.1. 401 Unauthorized | challenge = auth-scheme 1*SP 1#auth-param | |||
Note: User agents will need to take special care in parsing the | ||||
WWW-Authenticate or Proxy-Authenticate header field value if it | ||||
contains more than one challenge, or if more than one WWW- | ||||
Authenticate header field is provided, since the contents of a | ||||
challenge can itself contain a comma-separated list of | ||||
authentication parameters. | ||||
Note: Many browsers fail to parse challenges containing unknown | ||||
schemes. A workaround for this problem is to list well-supported | ||||
schemes (such as "basic") first. | ||||
The authentication parameter realm is defined for all authentication | ||||
schemes: | ||||
realm = "realm" "=" realm-value | ||||
realm-value = quoted-string | ||||
The realm directive (case-insensitive) is required for all | ||||
authentication schemes that issue a challenge. The realm value | ||||
(case-sensitive), in combination with the canonical root URI (the | ||||
scheme and authority components of the effective request URI; see | ||||
Section 4.3 of [Part1]) of the server being accessed, defines the | ||||
protection space. These realms allow the protected resources on a | ||||
server to be partitioned into a set of protection spaces, each with | ||||
its own authentication scheme and/or authorization database. The | ||||
realm value is a string, generally assigned by the origin server, | ||||
which can have additional semantics specific to the authentication | ||||
scheme. Note that there can be multiple challenges with the same | ||||
auth-scheme but different realms. | ||||
A user agent that wishes to authenticate itself with an origin server | ||||
-- usually, but not necessarily, after receiving a 401 (Unauthorized) | ||||
-- MAY do so by including an Authorization header field with the | ||||
request. A client that wishes to authenticate itself with a proxy -- | ||||
usually, but not necessarily, after receiving a 407 (Proxy | ||||
Authentication Required) -- MAY do so by including a Proxy- | ||||
Authorization header field with the request. Both the Authorization | ||||
field value and the Proxy-Authorization field value consist of | ||||
credentials containing the authentication information of the client | ||||
for the realm of the resource being requested. The user agent MUST | ||||
choose to use one of the challenges with the strongest auth-scheme it | ||||
understands and request credentials from the user based upon that | ||||
challenge. | ||||
credentials = auth-scheme ( token | ||||
/ quoted-string | ||||
/ #auth-param ) | ||||
The protection space determines the domain over which credentials can | ||||
be automatically applied. If a prior request has been authorized, | ||||
the same credentials MAY be reused for all other requests within that | ||||
protection space for a period of time determined by the | ||||
authentication scheme, parameters, and/or user preference. Unless | ||||
otherwise defined by the authentication scheme, a single protection | ||||
space cannot extend outside the scope of its server. | ||||
If the origin server does not wish to accept the credentials sent | ||||
with a request, it SHOULD return a 401 (Unauthorized) response. The | ||||
response MUST include a WWW-Authenticate header field containing at | ||||
least one (possibly new) challenge applicable to the requested | ||||
resource. If a proxy does not accept the credentials sent with a | ||||
request, it SHOULD return a 407 (Proxy Authentication Required). The | ||||
response MUST include a Proxy-Authenticate header field containing a | ||||
(possibly new) challenge applicable to the proxy for the requested | ||||
resource. | ||||
The HTTP protocol does not restrict applications to this simple | ||||
challenge-response mechanism for access authentication. Additional | ||||
mechanisms MAY be used, such as encryption at the transport level or | ||||
via message encapsulation, and with additional header fields | ||||
specifying authentication information. However, these additional | ||||
mechanisms are not defined by this specification. | ||||
Proxies MUST be completely transparent regarding user agent | ||||
authentication by origin servers. That is, they MUST forward the | ||||
WWW-Authenticate and Authorization headers untouched, and follow the | ||||
rules found in Section 4.1. Both the Proxy-Authenticate and the | ||||
Proxy-Authorization header fields are hop-by-hop headers (see Section | ||||
7.1.3.1 of [Part1]). | ||||
2.1. 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 | ||||
Values to be added to this name space are subject to IETF review | ||||
([RFC5226], Section 4.1). | ||||
The registry itself is maintained at | ||||
<http://www.iana.org/assignments/http-authschemes>. | ||||
3. Status Code Definitions | ||||
3.1. 401 Unauthorized | ||||
The request requires user authentication. The response MUST include | The request requires user authentication. The response MUST include | |||
a WWW-Authenticate header field (Section 3.4) containing a challenge | a WWW-Authenticate header field (Section 4.4) containing a challenge | |||
applicable to the target resource. The client MAY repeat the request | applicable to the target resource. The client MAY repeat the request | |||
with a suitable Authorization header field (Section 3.1). If the | with a suitable Authorization header field (Section 4.1). If the | |||
request already included Authorization credentials, then the 401 | request already included Authorization credentials, then the 401 | |||
response indicates that authorization has been refused for those | response indicates that authorization has been refused for those | |||
credentials. If the 401 response contains the same challenge as the | credentials. If the 401 response contains the same challenge as the | |||
prior response, and the user agent has already attempted | prior response, and the user agent has already attempted | |||
authentication at least once, then the user SHOULD be presented the | authentication at least once, then the user SHOULD be presented the | |||
representation that was given in the response, since that | representation that was given in the response, since that | |||
representation might include relevant diagnostic information. HTTP | representation might include relevant diagnostic information. | |||
access authentication is explained in "HTTP Authentication: Basic and | ||||
Digest Access Authentication" [RFC2617]. | ||||
2.2. 407 Proxy Authentication Required | 3.2. 407 Proxy Authentication Required | |||
This code is similar to 401 (Unauthorized), but indicates that the | This code is similar to 401 (Unauthorized), but indicates that the | |||
client must first authenticate itself with the proxy. The proxy MUST | client ought to first authenticate itself with the proxy. The proxy | |||
return a Proxy-Authenticate header field (Section 3.2) containing a | MUST return a Proxy-Authenticate header field (Section 4.2) | |||
challenge applicable to the proxy for the target resource. The | containing a challenge applicable to the proxy for the target | |||
client MAY repeat the request with a suitable Proxy-Authorization | resource. The client MAY repeat the request with a suitable Proxy- | |||
header field (Section 3.3). HTTP access authentication is explained | Authorization header field (Section 4.3). | |||
in "HTTP Authentication: Basic and Digest Access Authentication" | ||||
[RFC2617]. | ||||
3. 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. | |||
3.1. Authorization | 4.1. Authorization | |||
The "Authorization" request-header field allows a user agent to | The "Authorization" request-header field allows a user agent to | |||
authenticate itself with a server -- usually, but not necessarily, | authenticate itself with a server -- usually, but not necessarily, | |||
after receiving a 401 (Unauthorized) response. Its value consists of | after receiving a 401 (Unauthorized) response. Its value consists of | |||
credentials containing information of the user agent for the realm of | credentials containing information of the user agent for the realm of | |||
the resource being requested. | the resource being requested. | |||
Authorization = "Authorization" ":" OWS Authorization-v | Authorization = "Authorization" ":" OWS Authorization-v | |||
Authorization-v = credentials | Authorization-v = credentials | |||
HTTP access authentication is described in "HTTP Authentication: | If a request is authenticated and a realm specified, the same | |||
Basic and Digest Access Authentication" [RFC2617]. If a request is | credentials SHOULD be valid for all other requests within this realm | |||
authenticated and a realm specified, the same credentials SHOULD be | (assuming that the authentication scheme itself does not require | |||
valid for all other requests within this realm (assuming that the | otherwise, such as credentials that vary according to a challenge | |||
authentication scheme itself does not require otherwise, such as | value or using synchronized clocks). | |||
credentials that vary according to a challenge value or using | ||||
synchronized clocks). | ||||
When a shared cache (see Section 1.2 of [Part6]) receives a request | When a shared cache (see Section 1.2 of [Part6]) receives a request | |||
containing an Authorization field, it MUST NOT return the | containing an Authorization field, it MUST NOT return the | |||
corresponding response as a reply to any other request, unless one of | corresponding response as a reply to any other request, unless one of | |||
the following specific exceptions holds: | the following specific exceptions holds: | |||
1. If the response includes the "s-maxage" cache-control directive, | 1. If the response includes the "s-maxage" cache-control directive, | |||
the cache MAY use that response in replying to a subsequent | the cache MAY use that response in replying to a subsequent | |||
request. But (if the specified maximum age has passed) a proxy | request. But (if the specified maximum age has passed) a proxy | |||
cache MUST first revalidate it with the origin server, using the | cache MUST first revalidate it with the origin server, using the | |||
request-headers from the new request to allow the origin server | request-header fields from the new request to allow the origin | |||
to authenticate the new request. (This is the defined behavior | server to authenticate the new request. (This is the defined | |||
for s-maxage.) If the response includes "s-maxage=0", the proxy | behavior for s-maxage.) If the response includes "s-maxage=0", | |||
MUST always revalidate it before re-using it. | the proxy MUST always revalidate it before re-using it. | |||
2. If the response includes the "must-revalidate" cache-control | 2. If the response includes the "must-revalidate" cache-control | |||
directive, the cache MAY use that response in replying to a | directive, the cache MAY use that response in replying to a | |||
subsequent request. But if the response is stale, all caches | subsequent request. But if the response is stale, all caches | |||
MUST first revalidate it with the origin server, using the | MUST first revalidate it with the origin server, using the | |||
request-headers from the new request to allow the origin server | request-header fields from the new request to allow the origin | |||
to authenticate the new request. | server to authenticate the new request. | |||
3. If the response includes the "public" cache-control directive, it | 3. If the response includes the "public" cache-control directive, it | |||
MAY be returned in reply to any subsequent request. | MAY be returned in reply to any subsequent request. | |||
3.2. Proxy-Authenticate | 4.2. Proxy-Authenticate | |||
The "Proxy-Authenticate" response-header field consists of a | The "Proxy-Authenticate" response-header field consists of a | |||
challenge that indicates the authentication scheme and parameters | challenge that indicates the authentication scheme and parameters | |||
applicable to the proxy for this effective request URI (Section 4.3 | applicable to the proxy for this effective request URI (Section 4.3 | |||
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 = "Proxy-Authenticate" ":" OWS | Proxy-Authenticate = "Proxy-Authenticate" ":" OWS | |||
Proxy-Authenticate-v | Proxy-Authenticate-v | |||
Proxy-Authenticate-v = 1#challenge | Proxy-Authenticate-v = 1#challenge | |||
The HTTP access authentication process is described in "HTTP | ||||
Authentication: Basic and Digest Access Authentication" [RFC2617]. | ||||
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies | |||
only to the current connection and SHOULD NOT be passed on to | only to the current connection and SHOULD NOT be passed on to | |||
downstream clients. However, an intermediate proxy might need to | downstream clients. However, an intermediate proxy might need to | |||
obtain its own credentials by requesting them from the downstream | 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. | |||
3.3. Proxy-Authorization | 4.3. Proxy-Authorization | |||
The "Proxy-Authorization" request-header field allows the client to | The "Proxy-Authorization" request-header field allows the client to | |||
identify itself (or its user) to a proxy which requires | identify itself (or its user) to a proxy which requires | |||
authentication. Its value consists of credentials containing the | authentication. Its value consists of credentials containing the | |||
authentication information of the user agent for the proxy and/or | authentication information of the user agent for the proxy and/or | |||
realm of the resource being requested. | realm of the resource being requested. | |||
Proxy-Authorization = "Proxy-Authorization" ":" OWS | Proxy-Authorization = "Proxy-Authorization" ":" OWS | |||
Proxy-Authorization-v | Proxy-Authorization-v | |||
Proxy-Authorization-v = credentials | Proxy-Authorization-v = credentials | |||
The HTTP access authentication process is described in "HTTP | ||||
Authentication: Basic and Digest Access Authentication" [RFC2617]. | ||||
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 | |||
authenticate a given request. | authenticate a given request. | |||
3.4. WWW-Authenticate | 4.4. WWW-Authenticate | |||
The "WWW-Authenticate" response-header field consists of at least one | The "WWW-Authenticate" response-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 4.3 of [Part1]). It | applicable to the effective request URI (Section 4.3 of [Part1]). It | |||
MUST be included in 401 (Unauthorized) response messages. | MUST be included in 401 (Unauthorized) response messages. | |||
WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v | WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v | |||
WWW-Authenticate-v = 1#challenge | WWW-Authenticate-v = 1#challenge | |||
The HTTP access authentication process is described in "HTTP | ||||
Authentication: Basic and Digest Access Authentication" [RFC2617]. | ||||
User agents are advised to take special care in parsing the WWW- | User agents are advised to take special care in parsing the WWW- | |||
Authenticate field value as it might contain more than one challenge, | Authenticate field value as it might contain more than one challenge, | |||
or if more than one WWW-Authenticate header field is provided, the | or if more than one WWW-Authenticate header field is provided, the | |||
contents of a challenge itself can contain a comma-separated list of | contents of a challenge itself can contain a comma-separated list of | |||
authentication parameters. | authentication parameters. | |||
4. IANA Considerations | 5. IANA Considerations | |||
4.1. Status Code Registration | 5.1. Authenticaton Scheme Registry | |||
The registration procedure for HTTP Authentication Schemes is defined | ||||
by Section 2.1 of this document. | ||||
The HTTP Method Authentication Scheme shall be created at | ||||
<http://www.iana.org/assignments/http-authschemes>. | ||||
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 2.1 | | | 401 | Unauthorized | Section 3.1 | | |||
| 407 | Proxy Authentication Required | Section 2.2 | | | 407 | Proxy Authentication Required | Section 3.2 | | |||
+-------+-------------------------------+-------------+ | +-------+-------------------------------+-------------+ | |||
4.2. 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 [RFC3864]): | |||
+---------------------+----------+----------+-------------+ | +---------------------+----------+----------+-------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+---------------------+----------+----------+-------------+ | +---------------------+----------+----------+-------------+ | |||
| Authorization | http | standard | Section 3.1 | | | Authorization | http | standard | Section 4.1 | | |||
| Proxy-Authenticate | http | standard | Section 3.2 | | | Proxy-Authenticate | http | standard | Section 4.2 | | |||
| Proxy-Authorization | http | standard | Section 3.3 | | | Proxy-Authorization | http | standard | Section 4.3 | | |||
| WWW-Authenticate | http | standard | Section 3.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". | |||
5. Security Considerations | 6. Security Considerations | |||
This section is meant to inform application developers, information | This section is meant to inform application developers, information | |||
providers, and users of the security limitations in HTTP/1.1 as | providers, and users of the security limitations in HTTP/1.1 as | |||
described by this document. The discussion does not include | described by this document. The discussion does not include | |||
definitive solutions to the problems revealed, though it does make | definitive solutions to the problems revealed, though it does make | |||
some suggestions for reducing security risks. | some suggestions for reducing security risks. | |||
5.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 which 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 reprompt the | |||
skipping to change at page 9, line 31 | skipping to change at page 12, line 5 | |||
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 which mitigate the security problems inherent in this | |||
problem. In particular, user agents which cache credentials are | problem. In particular, user agents which cache credentials are | |||
encouraged to provide a readily accessible mechanism for discarding | encouraged to provide a readily accessible mechanism for discarding | |||
cached credentials under user control. | cached credentials under user control. | |||
6. Acknowledgments | 7. Acknowledgments | |||
[[acks: TBD.]] | This specification takes over the definition of the HTTP | |||
Authentication Framework, previously defined in RFC 2617. We thank | ||||
to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott | ||||
D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for | ||||
their work on that specification. | ||||
7. References | [[acks: HTTPbis acknowledgements.]] | |||
7.1. Normative References | 8. References | |||
8.1. Normative References | ||||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | |||
and Message Parsing", draft-ietf-httpbis-p1-messaging-11 | and Message Parsing", draft-ietf-httpbis-p1-messaging-12 | |||
(work in progress), August 2010. | (work in progress), October 2010. | |||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | |||
6: Caching", draft-ietf-httpbis-p6-cache-11 (work in | 6: Caching", draft-ietf-httpbis-p6-cache-12 (work in | |||
progress), August 2010. | progress), October 2010. | |||
[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. | |||
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | ||||
Leach, P., Luotonen, A., and L. Stewart, "HTTP | ||||
Authentication: Basic and Digest Access Authentication", | ||||
RFC 2617, June 1999. | ||||
[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. | |||
7.2. Informative References | 8.2. Informative References | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
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., | ||||
Leach, P., Luotonen, A., and L. Stewart, "HTTP | ||||
Authentication: Basic and Digest Access Authentication", | ||||
RFC 2617, June 1999. | ||||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
Procedures for Message Header Fields", BCP 90, RFC 3864, | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
September 2004. | September 2004. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | ||||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | ||||
May 2008. | ||||
Appendix A. Collected ABNF | Appendix A. Collected ABNF | |||
Authorization = "Authorization:" OWS Authorization-v | Authorization = "Authorization:" OWS Authorization-v | |||
Authorization-v = credentials | Authorization-v = credentials | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 1.2.2> | |||
Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v | Proxy-Authenticate = "Proxy-Authenticate:" OWS Proxy-Authenticate-v | |||
Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS | Proxy-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS | |||
challenge ] ) | challenge ] ) | |||
Proxy-Authorization = "Proxy-Authorization:" OWS | Proxy-Authorization = "Proxy-Authorization:" OWS | |||
Proxy-Authorization-v | Proxy-Authorization-v | |||
Proxy-Authorization-v = credentials | Proxy-Authorization-v = credentials | |||
WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v | WWW-Authenticate = "WWW-Authenticate:" OWS WWW-Authenticate-v | |||
WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS | WWW-Authenticate-v = *( "," OWS ) challenge *( OWS "," [ OWS | |||
challenge ] ) | challenge ] ) | |||
challenge = <challenge, defined in [RFC2617], Section 1.2> | auth-param = token "=" ( token / quoted-string ) | |||
credentials = <credentials, defined in [RFC2617], Section 1.2> | auth-scheme = token | |||
challenge = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS | ||||
auth-param ] ) | ||||
credentials = auth-scheme ( token / quoted-string / [ ( "," / | ||||
auth-param ) *( OWS "," [ OWS auth-param ] ) ] ) | ||||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | ||||
realm = "realm=" realm-value | ||||
realm-value = quoted-string | ||||
token = <token, defined in [Part1], Section 1.2.2> | ||||
ABNF diagnostics: | ABNF diagnostics: | |||
; Authorization defined but not used | ; Authorization defined but not used | |||
; Proxy-Authenticate defined but not used | ; Proxy-Authenticate defined but not used | |||
; Proxy-Authorization defined but not used | ; Proxy-Authorization defined but not used | |||
; WWW-Authenticate defined but not used | ; WWW-Authenticate defined but not used | |||
; realm defined but not used | ||||
Appendix B. Change Log (to be removed by RFC Editor before publication) | Appendix B. Change Log (to be removed by RFC Editor before publication) | |||
B.1. Since RFC2616 | B.1. Since RFC 2616 | |||
Extracted relevant partitions from [RFC2616]. | Extracted relevant partitions from [RFC2616]. | |||
B.2. Since draft-ietf-httpbis-p7-auth-00 | B.2. Since draft-ietf-httpbis-p7-auth-00 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and | |||
Informative references" | Informative references" | |||
skipping to change at page 11, line 31 | skipping to change at page 14, line 31 | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Explicitly import BNF rules for "challenge" and "credentials" from | o Explicitly import BNF rules for "challenge" and "credentials" from | |||
RFC2617. | RFC2617. | |||
o Add explicit references to BNF syntax and rules imported from | o Add explicit references to BNF syntax and rules imported from | |||
other parts of the specification. | other parts of the specification. | |||
B.4. Since draft-ietf-httpbis-p7-auth-02 | B.4. Since draft-ietf-httpbis-p7-auth-02 | |||
Ongoing work on IANA Message Header Registration | Ongoing work on IANA Message Header Field Registration | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): | |||
o Reference RFC 3984, and update header registrations for headers | o Reference RFC 3984, and update header field registrations for | |||
defined in this document. | header fields defined in this document. | |||
B.5. Since draft-ietf-httpbis-p7-auth-03 | B.5. Since draft-ietf-httpbis-p7-auth-03 | |||
B.6. Since draft-ietf-httpbis-p7-auth-04 | B.6. Since draft-ietf-httpbis-p7-auth-04 | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Use "/" instead of "|" for alternatives. | o Use "/" instead of "|" for alternatives. | |||
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | |||
whitespace ("OWS") and required whitespace ("RWS"). | whitespace ("OWS") and required whitespace ("RWS"). | |||
o Rewrite ABNFs to spell out whitespace rules, factor out header | o Rewrite ABNFs to spell out whitespace rules, factor out header | |||
value format definitions. | field value format definitions. | |||
B.7. Since draft-ietf-httpbis-p7-auth-05 | B.7. Since draft-ietf-httpbis-p7-auth-05 | |||
Final work on ABNF conversion | Final work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Add appendix containing collected and expanded ABNF, reorganize | o Add appendix containing collected and expanded ABNF, reorganize | |||
ABNF introduction. | ABNF introduction. | |||
B.8. Since draft-ietf-httpbis-p7-auth-06 | B.8. Since draft-ietf-httpbis-p7-auth-06 | |||
skipping to change at page 12, line 39 | skipping to change at page 15, line 39 | |||
Partly resolved issues: | Partly resolved issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the | |||
requested resource's URI" | requested resource's URI" | |||
B.12. Since draft-ietf-httpbis-p7-auth-10 | B.12. Since draft-ietf-httpbis-p7-auth-10 | |||
None yet. | None yet. | |||
B.13. Since draft-ietf-httpbis-p7-auth-11 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/130>: "introduction | ||||
to part 7 is work-in-progress" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/195>: "auth-param | ||||
syntax" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/237>: "absorbing the | ||||
auth framework from 2617" | ||||
Partly resolved issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/141>: "should we | ||||
have an auth scheme registry" | ||||
Index | Index | |||
4 | 4 | |||
401 Unauthorized (status code) 5 | 401 Unauthorized (status code) 7 | |||
407 Proxy Authentication Required (status code) 5 | 407 Proxy Authentication Required (status code) 8 | |||
A | A | |||
Authorization header 6 | auth-param 5 | |||
auth-scheme 5 | ||||
Authorization header 8 | ||||
C | ||||
challenge 5 | ||||
credentials 6 | ||||
G | G | |||
Grammar | Grammar | |||
Authorization 6 | Authorization 8 | |||
Authorization-v 6 | Authorization-v 8 | |||
challenge 5 | Proxy-Authenticate 9 | |||
credentials 5 | Proxy-Authenticate-v 9 | |||
Proxy-Authenticate 7 | Proxy-Authorization 9 | |||
Proxy-Authenticate-v 7 | Proxy-Authorization-v 9 | |||
Proxy-Authorization 7 | WWW-Authenticate 10 | |||
Proxy-Authorization-v 7 | WWW-Authenticate-v 10 | |||
WWW-Authenticate 7 | ||||
WWW-Authenticate-v 7 | ||||
H | H | |||
Headers | Headers | |||
Authorization 6 | Authorization 8 | |||
Proxy-Authenticate 6 | Proxy-Authenticate 9 | |||
Proxy-Authorization 7 | Proxy-Authorization 9 | |||
WWW-Authenticate 7 | WWW-Authenticate 10 | |||
P | P | |||
Proxy-Authenticate header 6 | Proxy-Authenticate header 9 | |||
Proxy-Authorization header 7 | Proxy-Authorization header 9 | |||
R | ||||
realm 5 | ||||
realm-value 5 | ||||
S | S | |||
Status Codes | Status Codes | |||
401 Unauthorized 5 | 401 Unauthorized 7 | |||
407 Proxy Authentication Required 5 | 407 Proxy Authentication Required 8 | |||
W | W | |||
WWW-Authenticate header 7 | WWW-Authenticate header 10 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Day Software | Day Software | |||
23 Corporate Plaza DR, Suite 280 | 23 Corporate Plaza DR, Suite 280 | |||
Newport Beach, CA 92660 | Newport Beach, CA 92660 | |||
USA | USA | |||
Phone: +1-949-706-5300 | Phone: +1-949-706-5300 | |||
End of changes. 62 change blocks. | ||||
150 lines changed or deleted | 308 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |