p7-auth.unpg.txt   rfc7235.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7235 Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 J. Reschke, Ed.
Updates: 2617 (if approved) greenbytes Updates: 2617 greenbytes
Intended status: Standards Track June 6, 2014 Category: Standards Track June 2014
Expires: December 8, 2014 ISSN: 2070-1721
Hypertext Transfer Protocol (HTTP/1.1): Authentication Hypertext Transfer Protocol (HTTP/1.1): Authentication
draft-ietf-httpbis-p7-auth-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypermedia information level 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)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
_This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 8, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7235.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 7 skipping to change at page 2, line 15
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling .............................3
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation ............................................3
2. Access Authentication Framework . . . . . . . . . . . . . . . 4 2. Access Authentication Framework .................................3
2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4 2.1. Challenge and Response .....................................3
2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6 2.2. Protection Space (Realm) ...................................5
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7 3. Status Code Definitions .........................................6
3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7 3.1. 401 Unauthorized ...........................................6
3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7 3.2. 407 Proxy Authentication Required ..........................6
4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8 4. Header Field Definitions ........................................7
4.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 8 4.1. WWW-Authenticate ...........................................7
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Authorization ..............................................8
4.3. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 9 4.3. Proxy-Authenticate .........................................8
4.4. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10 4.4. Proxy-Authorization ........................................9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations .............................................9
5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10 5.1. Authentication Scheme Registry .............................9
5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10 5.1.1. Procedure ...........................................9
5.1.2. Considerations for New Authentication Schemes . . . . 10 5.1.2. Considerations for New Authentication Schemes ......10
5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12 5.2. Status Code Registration ..................................11
5.3. Header Field Registration . . . . . . . . . . . . . . . . 12 5.3. Header Field Registration .................................11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations ........................................12
6.1. Confidentiality of Credentials . . . . . . . . . . . . . . 13 6.1. Confidentiality of Credentials ............................12
6.2. Authentication Credentials and Idle Clients . . . . . . . 13 6.2. Authentication Credentials and Idle Clients ...............12
6.3. Protection Spaces . . . . . . . . . . . . . . . . . . . . 14 6.3. Protection Spaces .........................................13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments ................................................14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References .....................................................14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References ......................................14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References ....................................14
Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16 Appendix A. Changes from RFCs 2616 and 2617 .......................16
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Imported ABNF .........................................16
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16 Appendix C. Collected ABNF ........................................17
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Index .............................................................18
1. Introduction 1. Introduction
HTTP provides a general framework for access control and HTTP provides a general framework for access control and
authentication, via an extensible set of challenge-response authentication, via an extensible set of challenge-response
authentication schemes, which can be used by a server to challenge a authentication schemes, which can be used by a server to challenge a
client request and by a client to provide authentication information. client request and by a client to provide authentication information.
This document defines HTTP/1.1 authentication in terms of the This document defines HTTP/1.1 authentication in terms of the
architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): architecture defined in "Hypertext Transfer Protocol (HTTP/1.1):
Message Syntax and Routing" [RFC7230], including the general Message Syntax and Routing" [RFC7230], including the general
skipping to change at page 5, line 25 skipping to change at page 4, line 26
token68 = 1*( ALPHA / DIGIT / token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"=" "-" / "." / "_" / "~" / "+" / "/" ) *"="
The token68 syntax allows the 66 unreserved URI characters The token68 syntax allows the 66 unreserved URI characters
([RFC3986]), plus a few others, so that it can hold a base64, ([RFC3986]), plus a few others, so that it can hold a base64,
base64url (URL and filename safe alphabet), base32, or base16 (hex) base64url (URL and filename safe alphabet), base32, or base16 (hex)
encoding, with or without padding, but excluding whitespace encoding, with or without padding, but excluding whitespace
([RFC4648]). ([RFC4648]).
A 401 (Unauthorized) response message is used by an origin server to A 401 (Unauthorized) response message is used by an origin server to
challenge the authorization of a user agent, including a WWW- challenge the authorization of a user agent, including a
Authenticate header field containing at least one challenge WWW-Authenticate header field containing at least one challenge
applicable to the requested resource. applicable to the requested resource.
A 407 (Proxy Authentication Required) response message is used by a A 407 (Proxy Authentication Required) response message is used by a
proxy to challenge the authorization of a client, including a Proxy- proxy to challenge the authorization of a client, including a
Authenticate header field containing at least one challenge Proxy-Authenticate header field containing at least one challenge
applicable to the proxy for the requested resource. applicable to the proxy for the requested resource.
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Note: Many clients fail to parse a challenge that contains an Note: Many clients fail to parse a challenge that contains an
unknown scheme. A workaround for this problem is to list well- unknown scheme. A workaround for this problem is to list well-
supported schemes (such as "basic") first. supported schemes (such as "basic") first.
A user agent that wishes to authenticate itself with an origin server A user agent that wishes to authenticate itself with an origin server
-- usually, but not necessarily, after receiving a 401 (Unauthorized) -- usually, but not necessarily, after receiving a 401 (Unauthorized)
skipping to change at page 7, line 18 skipping to change at page 6, line 20
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 user agent MAY reuse the same credentials for all other requests the user agent MAY reuse the same credentials for all other requests
within that protection space for a period of time determined by the within that protection space for a period of time determined by the
authentication scheme, parameters, and/or user preferences (such as a authentication scheme, parameters, and/or user preferences (such as a
configurable inactivity timeout). Unless specifically allowed by the configurable inactivity timeout). Unless specifically allowed by the
authentication scheme, a single protection space cannot extend authentication scheme, a single protection space cannot extend
outside the scope of its server. outside the scope of its server.
For historical reasons, a sender MUST only generate the quoted-string For historical reasons, a sender MUST only generate the quoted-string
syntax. Recipients might have to support both token and quoted- syntax. Recipients might have to support both token and
string syntax for maximum interoperability with existing clients that quoted-string syntax for maximum interoperability with existing
have been accepting both notations for a long time. clients that have been accepting both notations for a long time.
3. Status Code Definitions 3. Status Code Definitions
3.1. 401 Unauthorized 3.1. 401 Unauthorized
The 401 (Unauthorized) status code indicates that the request has not The 401 (Unauthorized) status code indicates that the request has not
been applied because it lacks valid authentication credentials for been applied because it lacks valid authentication credentials for
the target resource. The server generating a 401 response MUST send the target resource. The server generating a 401 response MUST send
a WWW-Authenticate header field (Section 4.1) containing at least one a WWW-Authenticate header field (Section 4.1) containing at least one
challenge applicable to the target resource. challenge applicable to the target resource.
skipping to change at page 8, line 17 skipping to change at page 7, line 17
This section defines the syntax and semantics of header fields This section defines the syntax and semantics of header fields
related to the HTTP authentication framework. related to the HTTP authentication framework.
4.1. WWW-Authenticate 4.1. WWW-Authenticate
The "WWW-Authenticate" header field indicates the authentication The "WWW-Authenticate" header field indicates the authentication
scheme(s) and parameters applicable to the target resource. scheme(s) and parameters applicable to the target resource.
WWW-Authenticate = 1#challenge WWW-Authenticate = 1#challenge
A server generating a 401 (Unauthorized) response MUST send a WWW- A server generating a 401 (Unauthorized) response MUST send a
Authenticate header field containing at least one challenge. A WWW-Authenticate header field containing at least one challenge. A
server MAY generate a WWW-Authenticate header field in other response server MAY generate a WWW-Authenticate header field in other response
messages to indicate that supplying credentials (or different messages to indicate that supplying credentials (or different
credentials) might affect the response. credentials) might affect the response.
A proxy forwarding a response MUST NOT modify any WWW-Authenticate A proxy forwarding a response MUST NOT modify any WWW-Authenticate
fields in that response. fields in that response.
User agents are advised to take special care in parsing the field User agents are advised to take special care in parsing the field
value, as it might contain more than one challenge, and each value, as it might contain more than one challenge, and each
challenge can contain a comma-separated list of authentication challenge can contain a comma-separated list of authentication
skipping to change at page 11, line 20 skipping to change at page 10, line 25
and inherently flawed unless steps are taken to ensure that the and inherently flawed unless steps are taken to ensure that the
connection cannot be used by any party other than the connection cannot be used by any party other than the
authenticated user (see Section 2.3 of [RFC7230]). authenticated user (see Section 2.3 of [RFC7230]).
o The authentication parameter "realm" is reserved for defining o The authentication parameter "realm" is reserved for defining
protection spaces as described in Section 2.2. New schemes MUST protection spaces as described in Section 2.2. New schemes MUST
NOT use it in a way incompatible with that definition. NOT use it in a way incompatible with that definition.
o The "token68" notation was introduced for compatibility with o The "token68" notation was introduced for compatibility with
existing authentication schemes and can only be used once per existing authentication schemes and can only be used once per
challenge or credential. Thus, new schemes ought to use the auth- challenge or credential. Thus, new schemes ought to use the
param syntax instead, because otherwise future extensions will be auth-param syntax instead, because otherwise future extensions
impossible. will be impossible.
o The parsing of challenges and credentials is defined by this o The parsing of challenges and credentials is defined by this
specification and cannot be modified by new authentication specification and cannot be modified by new authentication
schemes. When the auth-param syntax is used, all parameters ought schemes. When the auth-param syntax is used, all parameters ought
to support both token and quoted-string syntax, and syntactical to support both token and quoted-string syntax, and syntactical
constraints ought to be defined on the field value after parsing constraints ought to be defined on the field value after parsing
(i.e., quoted-string processing). This is necessary so that (i.e., quoted-string processing). This is necessary so that
recipients can use a generic parser that applies to all recipients can use a generic parser that applies to all
authentication schemes. authentication schemes.
skipping to change at page 15, line 14 skipping to change at page 14, line 29
8.1. Normative References 8.1. Normative References
[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.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] 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-latest (work in progress), RFC 7230, June 2014.
June 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
draft-ietf-httpbis-p2-semantics-latest (work in progress),
June 2014. June 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] 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-latest (work in progress), RFC 7234, June 2014.
June 2014.
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
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web Application Applications and Web Services", The Open Web Application
Security Project (OWASP) 2.0.1, July 2005, Security Project (OWASP) 2.0.1, July 2005,
skipping to change at page 17, line 35 skipping to change at page 18, line 8
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6> quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6> token = <token, see [RFC7230], Section 3.2.6>
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
*"=" *"="
Index Index
4 4
401 Unauthorized (status code) 7 401 Unauthorized (status code) 6
407 Proxy Authentication Required (status code) 7 407 Proxy Authentication Required (status code) 6
A A
Authorization header field 9 Authorization header field 8
C C
Canonical Root URI 6 Canonical Root URI 5
G G
Grammar Grammar
auth-param 5 auth-param 4
auth-scheme 5 auth-scheme 4
Authorization 9 Authorization 8
challenge 5 challenge 4
credentials 6 credentials 5
Proxy-Authenticate 9 Proxy-Authenticate 8
Proxy-Authorization 10 Proxy-Authorization 9
token68 5 token68 4
WWW-Authenticate 8 WWW-Authenticate 7
P P
Protection Space 6 Protection Space 5
Proxy-Authenticate header field 9 Proxy-Authenticate header field 8
Proxy-Authorization header field 10 Proxy-Authorization header field 9
R R
Realm 6 Realm 5
W W
WWW-Authenticate header field 8 WWW-Authenticate header field 7
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. 22 change blocks. 
101 lines changed or deleted 80 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/