draft-ietf-httpbis-p7-auth-09.txt   draft-ietf-httpbis-p7-auth-10.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) One Laptop per Child Updates: 2617 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: September 9, 2010 HP Expires: January 13, 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
March 8, 2010 July 12, 2010
HTTP/1.1, part 7: Authentication HTTP/1.1, part 7: Authentication
draft-ietf-httpbis-p7-auth-09 draft-ietf-httpbis-p7-auth-10
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/11> 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 C.10. The changes in this draft are summarized in Appendix C.11.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
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
skipping to change at page 3, line 32 skipping to change at page 3, line 32
4.1. Status Code Registration . . . . . . . . . . . . . . . . . 8 4.1. Status Code Registration . . . . . . . . . . . . . . . . . 8
4.2. Message Header Registration . . . . . . . . . . . . . . . 8 4.2. Message Header Registration . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Authentication Credentials and Idle Clients . . . . . . . 9 5.1. Authentication Credentials and Idle Clients . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Compatibility with Previous Versions . . . . . . . . 10 Appendix A. Compatibility with Previous Versions . . . . . . . . 10
A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 10 A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 10
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 11 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 10
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 11 publication) . . . . . . . . . . . . . . . . . . . . 11
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 11 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 11
C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 11 C.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 11
C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 11 C.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 11
C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 12 C.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 11
C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 12 C.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 11
C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 12 C.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 11
C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 12 C.7. Since draft-ietf-httpbis-p7-auth-05 . . . . . . . . . . . 12
C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 12 C.8. Since draft-ietf-httpbis-p7-auth-06 . . . . . . . . . . . 12
C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 12 C.9. Since draft-ietf-httpbis-p7-auth-07 . . . . . . . . . . . 12
C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 13 C.10. Since draft-ietf-httpbis-p7-auth-08 . . . . . . . . . . . 12
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 C.11. Since draft-ietf-httpbis-p7-auth-09 . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document defines HTTP/1.1 access control and authentication. This document defines HTTP/1.1 access control and authentication.
Right now it includes the extracted relevant sections of RFC 2616 Right now it includes the extracted relevant sections of RFC 2616
with only minor changes. The intention is to move the general with only minor changes. The intention is to move the general
framework for HTTP authentication here, as currently specified in framework for HTTP authentication here, as currently specified in
[RFC2617], and allow the individual authentication mechanisms to be [RFC2617], and allow the individual authentication mechanisms to be
defined elsewhere. This introduction will be rewritten when that defined elsewhere. This introduction will be rewritten when that
occurs. occurs.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
This specification adopts the definitions of "challenge" and This specification adopts the definitions of "challenge" and
"credentials" from that specification. "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
REQUIRED level and all the SHOULD level requirements for its "REQUIRED" level and all the "SHOULD" level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the "MUST" level requirements but not all the "SHOULD"
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant".
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the ABNF syntax defined in Section 1.2 of
[Part1] (which extends the syntax defined in [RFC5234] with a list [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix B shows the collected ABNF, with the list rule rule). Appendix B shows the collected ABNF, with the list rule
expanded. expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
skipping to change at page 6, line 52 skipping to change at page 6, line 52
request-headers from the new request to allow the origin server request-headers from the new request to allow the origin server
to authenticate the new request. 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 3.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 request-target. It MUST be included applicable to the proxy for this Effective Request URI (Section 4.3
as part of a 407 (Proxy Authentication Required) response. of [Part1]). It MUST be included as part of a 407 (Proxy
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 The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [RFC2617]. 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
skipping to change at page 7, line 46 skipping to change at page 7, line 47
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 3.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 request-target. It MUST be included in 401 applicable to the Effective Request URI (Section 4.3 of [Part1]). It
(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 The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [RFC2617]. 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
skipping to change at page 9, line 44 skipping to change at page 9, line 42
[[acks: TBD.]] [[acks: TBD.]]
7. References 7. References
7.1. Normative References 7.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-09 and Message Parsing", draft-ietf-httpbis-p1-messaging-10
(work in progress), March 2010. (work in progress), July 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-09 (work in 6: Caching", draft-ietf-httpbis-p6-cache-10 (work in
progress), March 2010. progress), July 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., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 13, line 9 skipping to change at page 12, line 34
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes" registrations for optional status codes"
C.10. Since draft-ietf-httpbis-p7-auth-08 C.10. Since draft-ietf-httpbis-p7-auth-08
No significant changes. No significant changes.
C.11. Since draft-ietf-httpbis-p7-auth-09
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
requested resource's URI"
Index Index
4 4
401 Unauthorized (status code) 5 401 Unauthorized (status code) 5
407 Proxy Authentication Required (status code) 5 407 Proxy Authentication Required (status code) 5
A A
Authorization header 6 Authorization header 6
G G
skipping to change at page 14, line 15 skipping to change at page 13, line 43
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
Fax: +1-949-706-5305 Fax: +1-949-706-5305
Email: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
One Laptop per Child Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
Email: jg@laptop.org EMail: jg@freedesktop.org
URI: http://www.laptop.org/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
Hewlett-Packard Company Hewlett-Packard Company
HP Labs, Large Scale Systems Group HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177 1501 Page Mill Road, MS 1177
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
Email: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems, Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
Email: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: paulle@microsoft.com EMail: paulle@microsoft.com
Tim Berners-Lee Tim Berners-Lee
World Wide Web Consortium World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32 The Stata Center, Building 32
32 Vassar Street 32 Vassar Street
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
Email: timbl@w3.org EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/ URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
Email: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 34 change blocks. 
52 lines changed or deleted 54 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/