| 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/