draft-ietf-httpbis-p7-auth-21.txt		draft-ietf-httpbis-p7-auth-22.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Reschke, Ed.		Obsoletes: 2616 (if approved) J. Reschke, Ed.
	Updates: 2617 (if approved) greenbytes		Updates: 2617 (if approved) greenbytes
	Intended status: Standards Track October 4, 2012		Intended status: Standards Track February 23, 2013
	Expires: April 7, 2013		Expires: August 27, 2013
	Hypertext Transfer Protocol (HTTP/1.1): Authentication		Hypertext Transfer Protocol (HTTP/1.1): Authentication
	draft-ietf-httpbis-p7-auth-21		draft-ietf-httpbis-p7-auth-22
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. This document defines the HTTP Authentication framework.		systems. This document defines the HTTP Authentication framework.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.2.		The changes in this draft are summarized in Appendix D.3.
	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 April 7, 2013.		This Internet-Draft will expire on August 27, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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
	skipping to change at page 3, line 22		skipping to change at page 3, line 22
	2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6		2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6
	2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7		2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7
	2.3.1. Considerations for New Authentication Schemes . . . . 7		2.3.1. Considerations for New Authentication Schemes . . . . 7
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9
	3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9		3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9
	3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9		3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9
	4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9		4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
	4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10		4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10
	4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10		4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10
	4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11		4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12		5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 11
	5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12		5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11
	5.3. Header Field Registration . . . . . . . . . . . . . . . . 12		5.3. Header Field Registration . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6.1. Authentication Credentials and Idle Clients . . . . . . . 13		6.1. Authentication Credentials and Idle Clients . . . . . . . 12
	6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13		6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15		Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 14
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 16		publication) . . . . . . . . . . . . . . . . . . . . 16
	D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16		D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16
	D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17		D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17
			D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 access control and authentication. It		This document defines HTTP/1.1 access control and authentication. It
	includes the relevant parts of RFC 2616 with only minor changes		includes the relevant parts of RFC 2616 with only minor changes
	([RFC2616]), plus the general framework for HTTP authentication, as		([RFC2616]), plus the general framework for HTTP authentication, as
	previously defined in "HTTP Authentication: Basic and Digest Access		previously defined in "HTTP Authentication: Basic and Digest Access
	Authentication" ([RFC2617]).		Authentication" ([RFC2617]).
	HTTP provides several OPTIONAL challenge-response authentication		HTTP provides several OPTIONAL challenge-response authentication
	mechanisms which can be used by a server to challenge a client		mechanisms that can be used by a server to challenge a client request
	request and by a client to provide authentication information. The		and by a client to provide authentication information. The "basic"
	"basic" and "digest" authentication schemes continue to be specified		and "digest" authentication schemes continue to be specified in RFC
	in RFC 2617.		2617.
	1.1. Conformance and Error Handling		1.1. Conformance and Error Handling
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Conformance criteria and considerations regarding error handling are		Conformance criteria and considerations regarding error handling are
	defined in Section 2.5 of [Part1].		defined in Section 2.5 of [Part1].
	skipping to change at page 6, line 15		skipping to change at page 6, line 15
	(possibly at some point in the past). When creating their values,		(possibly at some point in the past). When creating their values,
	the user agent ought to do so by selecting the challenge with what it		the user agent ought to do so by selecting the challenge with what it
	considers to be the most secure auth-scheme that it understands,		considers to be the most secure auth-scheme that it understands,
	obtaining credentials from the user as appropriate.		obtaining credentials from the user as appropriate.
	credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]		credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
	Upon a request for a protected resource that omits credentials,		Upon a request for a protected resource that omits credentials,
	contains invalid credentials (e.g., a bad password) or partial		contains invalid credentials (e.g., a bad password) or partial
	credentials (e.g., when the authentication scheme requires more than		credentials (e.g., when the authentication scheme requires more than
	one round trip), an origin server SHOULD return a 401 (Unauthorized)		one round trip), an origin server SHOULD send a 401 (Unauthorized)
	response. Such responses MUST include a WWW-Authenticate header		response that contains a WWW-Authenticate header field with at least
	field containing at least one (possibly new) challenge applicable to		one (possibly new) challenge applicable to the requested resource.
	the requested resource.
	Likewise, upon a request that requires authentication by proxies that		Likewise, upon a request that requires authentication by proxies that
	omit credentials or contain invalid or partial credentials, a proxy		omit credentials or contain invalid or partial credentials, a proxy
	SHOULD return a 407 (Proxy Authentication Required) response. Such		SHOULD send a 407 (Proxy Authentication Required) response that
	responses MUST include a Proxy-Authenticate header field containing a		contains a Proxy-Authenticate header field with a (possibly new)
	(possibly new) challenge applicable to the proxy.		challenge applicable to the proxy.
	A server receiving credentials that are valid, but not adequate to		A server receiving credentials that are valid, but not adequate to
	gain access, ought to respond with the 403 (Forbidden) status code		gain access, ought to respond with the 403 (Forbidden) status code
	(Section 7.5.3 of [Part2]).		(Section 6.5.3 of [Part2]).
	The HTTP protocol does not restrict applications to this simple		The HTTP protocol does not restrict applications to this simple
	challenge-response mechanism for access authentication. Additional		challenge-response mechanism for access authentication. Additional
	mechanisms MAY be used, such as encryption at the transport level or		mechanisms MAY be used, such as encryption at the transport level or
	via message encapsulation, and with additional header fields		via message encapsulation, and with additional header fields
	specifying authentication information. However, such additional		specifying authentication information. However, such additional
	mechanisms are not defined by this specification.		mechanisms are not defined by this specification.
	Proxies MUST forward the WWW-Authenticate and Authorization header		Proxies MUST forward the WWW-Authenticate and Authorization header
	fields unmodified and follow the rules found in Section 4.1.		fields unmodified and follow the rules found in Section 4.1.
	skipping to change at page 7, line 4		skipping to change at page 6, line 51
	The authentication parameter realm is reserved for use by		The authentication parameter realm is reserved for use by
	authentication schemes that wish to indicate the scope of protection.		authentication schemes that wish to indicate the scope of protection.
	A protection space is defined by the canonical root URI (the scheme		A protection space is defined by the canonical root URI (the scheme
	and authority components of the effective request URI; see Section		and authority components of the effective request URI; see Section
	5.5 of [Part1]) of the server being accessed, in combination with the		5.5 of [Part1]) of the server being accessed, in combination with the
	realm value if present. These realms allow the protected resources		realm value if present. These realms allow the protected resources
	on a server to be partitioned into a set of protection spaces, each		on a server to be partitioned into a set of protection spaces, each
	with its own authentication scheme and/or authorization database.		with its own authentication scheme and/or authorization database.
	The realm value is a string, generally assigned by the origin server,		The realm value is a string, generally assigned by the origin server,
	which can have additional semantics specific to the authentication		that can have additional semantics specific to the authentication
	scheme. Note that there can be multiple challenges with the same		scheme. Note that there can be multiple challenges with the same
	auth-scheme but different realms.		auth-scheme but different realms.
	The protection space determines the domain over which credentials can		The protection space determines the domain over which credentials can
	be automatically applied. If a prior request has been authorized,		be automatically applied. If a prior request has been authorized,
	the same credentials MAY be reused for all other requests within that		the same credentials MAY be reused for all other requests within that
	protection space for a period of time determined by the		protection space for a period of time determined by the
	authentication scheme, parameters, and/or user preference. Unless		authentication scheme, parameters, and/or user preference. Unless
	otherwise defined by the authentication scheme, a single protection		otherwise defined by the authentication scheme, a single protection
	space cannot extend outside the scope of its server.		space cannot extend outside the scope of its server.
	skipping to change at page 8, line 46		skipping to change at page 8, line 45
	o Authentication schemes need to document whether they are usable in		o Authentication schemes need to document whether they are usable in
	origin-server authentication (i.e., using WWW-Authenticate),		origin-server authentication (i.e., using WWW-Authenticate),
	and/or proxy authentication (i.e., using Proxy-Authenticate).		and/or proxy authentication (i.e., using Proxy-Authenticate).
	o The credentials carried in an Authorization header field are		o The credentials carried in an Authorization header field are
	specific to the User Agent, and therefore have the same effect on		specific to the User Agent, and therefore have the same effect on
	HTTP caches as the "private" Cache-Control response directive,		HTTP caches as the "private" Cache-Control response directive,
	within the scope of the request they appear in.		within the scope of the request they appear in.
	Therefore, new authentication schemes which choose not to carry		Therefore, new authentication schemes that choose not to carry
	credentials in the Authorization header field (e.g., using a newly		credentials in the Authorization header field (e.g., using a newly
	defined header field) will need to explicitly disallow caching, by		defined header field) will need to explicitly disallow caching, by
	mandating the use of either Cache-Control request directives		mandating the use of either Cache-Control request directives
	(e.g., "no-store") or response directives (e.g., "private").		(e.g., "no-store") or response directives (e.g., "private").
	3. Status Code Definitions		3. Status Code Definitions
	3.1. 401 Unauthorized		3.1. 401 Unauthorized
	The request requires user authentication. The response MUST include		The 401 (Unauthorized) status code indicates that the request has not
	a WWW-Authenticate header field (Section 4.4) containing a challenge		been applied because it lacks valid authentication credentials for
	applicable to the target resource. The client MAY repeat the request		the target resource. The origin server MUST send a WWW-Authenticate
	with a suitable Authorization header field (Section 4.1). If the		header field (Section 4.4) containing at least one challenge
	request already included Authorization credentials, then the 401		applicable to the target resource. If the request included
	response indicates that authorization has been refused for those		authentication credentials, then the 401 response indicates that
	credentials. If the 401 response contains the same challenge as the		authorization has been refused for those credentials. The client MAY
	prior response, and the user agent has already attempted		repeat the request with a new or replaced Authorization header field
	authentication at least once, then the user SHOULD be presented the		(Section 4.1). If the 401 response contains the same challenge as
	representation that was given in the response, since that		the prior response, and the user agent has already attempted
	representation might include relevant diagnostic information.		authentication at least once, then the user agent SHOULD present the
			enclosed representation to the user, since it usually contains
			relevant diagnostic information.
	3.2. 407 Proxy Authentication Required		3.2. 407 Proxy Authentication Required
	This code is similar to 401 (Unauthorized), but indicates that the		The 407 (Proxy Authentication Required) status code is similar to 401
	client ought to first authenticate itself with the proxy. The proxy		(Unauthorized), but indicates that the client needs to authenticate
	MUST return a Proxy-Authenticate header field (Section 4.2)		itself in order to use a proxy. The proxy MUST send a Proxy-
	containing a challenge applicable to the proxy for the target		Authenticate header field (Section 4.2) containing a challenge
	resource. The client MAY repeat the request with a suitable Proxy-		applicable to that proxy for the target resource. The client MAY
	Authorization header field (Section 4.3).		repeat the request with a new or replaced Proxy-Authorization header
			field (Section 4.3).
	4. Header Field Definitions		4. Header Field Definitions
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to authentication.		fields related to authentication.
	4.1. Authorization		4.1. Authorization
	The "Authorization" header field allows a user agent to authenticate		The "Authorization" header field allows a user agent to authenticate
	itself with a server -- usually, but not necessarily, after receiving		itself with a server -- usually, but not necessarily, after receiving
	skipping to change at page 9, line 51		skipping to change at page 10, line 5
	resource being requested.		resource being requested.
	Authorization = credentials		Authorization = credentials
	If a request is authenticated and a realm specified, the same		If a request is authenticated and a realm specified, the same
	credentials SHOULD be valid for all other requests within this realm		credentials SHOULD be valid for all other requests within this realm
	(assuming that the authentication scheme itself does not require		(assuming that the authentication scheme itself does not require
	otherwise, such as credentials that vary according to a challenge		otherwise, such as credentials that vary according to a challenge
	value or using synchronized clocks).		value or using synchronized clocks).
	When a shared cache (see Section 1.2 of [Part6]) receives a request		See Section 3.2 of [Part6] for details of and requirements pertaining
	containing an Authorization field, it MUST NOT return the		to handling of the Authorization field by HTTP caches.
	corresponding response as a reply to any other request, unless one of
	the following specific exceptions holds:
	1. If the response includes the "s-maxage" cache-control directive,
	the cache MAY use that response in replying to a subsequent
	request. But (if the specified maximum age has passed) a proxy
	cache MUST first revalidate it with the origin server, using the
	header fields from the new request to allow the origin server to
	authenticate the new request. (This is the defined behavior for
	s-maxage.) If the response includes "s-maxage=0", the proxy MUST
	always revalidate it before re-using it.
	2. If the response includes the "must-revalidate" cache-control
	directive, the cache MAY use that response in replying to a
	subsequent request. But if the response is stale, all caches
	MUST first revalidate it with the origin server, using the header
	fields from the new request to allow the origin server to
	authenticate the new request.
	3. If the response includes the "public" cache-control directive, it
	MAY be returned in reply to any subsequent request.
	4.2. Proxy-Authenticate		4.2. Proxy-Authenticate
	The "Proxy-Authenticate" header field consists of at least one		The "Proxy-Authenticate" 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 proxy for this effective request URI (Section 5.5		applicable to the proxy for this effective request URI (Section 5.5
	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 = 1#challenge		Proxy-Authenticate = 1#challenge
	skipping to change at page 10, line 49		skipping to change at page 10, line 31
	to obtain its own credentials by requesting them from the downstream		to 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.
	Note that the parsing considerations for WWW-Authenticate apply to		Note that the parsing considerations for WWW-Authenticate apply to
	this header field as well; see Section 4.4 for details.		this header field as well; see Section 4.4 for details.
	4.3. Proxy-Authorization		4.3. Proxy-Authorization
	The "Proxy-Authorization" header field allows the client to identify		The "Proxy-Authorization" header field allows the client to identify
	itself (or its user) to a proxy which requires authentication. Its		itself (or its user) to a proxy that requires authentication. Its
	value consists of credentials containing the authentication		value consists of credentials containing the authentication
	information of the user agent for the proxy and/or realm of the		information of the user agent for the proxy and/or realm of the
	resource being requested.		resource being requested.
	Proxy-Authorization = credentials		Proxy-Authorization = credentials
	Unlike Authorization, the Proxy-Authorization header field applies		Unlike Authorization, the Proxy-Authorization header field applies
	only to the next outbound proxy that demanded authentication using		only to the next outbound proxy that demanded authentication using
	the Proxy-Authenticate field. When multiple proxies are used in a		the Proxy-Authenticate field. When multiple proxies are used in a
	chain, the Proxy-Authorization header field is consumed by the first		chain, the Proxy-Authorization header field is consumed by the first
	skipping to change at page 12, line 32		skipping to change at page 12, line 16
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-------------------------------+-------------+		+-------+-------------------------------+-------------+
	| 401 | Unauthorized | Section 3.1 |		| 401 | Unauthorized | Section 3.1 |
	| 407 | Proxy Authentication Required | Section 3.2 |		| 407 | Proxy Authentication Required | Section 3.2 |
	+-------+-------------------------------+-------------+		+-------+-------------------------------+-------------+
	5.3. Header Field Registration		5.3. Header Field Registration
	The Message Header Field Registry located at <http://www.iana.org/		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 [BCP90]):
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	| Authorization | http | standard | Section 4.1 |		| Authorization | http | standard | Section 4.1 |
	| Proxy-Authenticate | http | standard | Section 4.2 |		| Proxy-Authenticate | http | standard | Section 4.2 |
	| Proxy-Authorization | http | standard | Section 4.3 |		| Proxy-Authorization | http | standard | Section 4.3 |
	| WWW-Authenticate | http | standard | Section 4.4 |		| WWW-Authenticate | http | standard | Section 4.4 |
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	6. Security Considerations		6. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform developers, information providers,
	providers, and users of the security limitations in HTTP/1.1 as		and users of known security concerns specific to HTTP/1.1
	described by this document. The discussion does not include		authentication. More general security considerations are addressed
	definitive solutions to the problems revealed, though it does make		in HTTP messaging [Part1] and semantics [Part2].
	some suggestions for reducing security risks.
	6.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 that 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 re-prompt the
	user for credentials.		user for credentials.
	o Applications which include a session termination indication (such		o Applications that include a session termination indication (such
	as a "logout" or "commit" button on a page) after which the server		as a "logout" or "commit" button on a page) after which the server
	side of the application "knows" that there is no further reason		side of the application "knows" that there is no further reason
	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 that mitigate the security problems inherent in this problem.
	problem. In particular, user agents which cache credentials are		In particular, user agents that cache credentials are encouraged to
	encouraged to provide a readily accessible mechanism for discarding		provide a readily accessible mechanism for discarding cached
	cached credentials under user control.		credentials under user control.
	6.2. Protection Spaces		6.2. Protection Spaces
	Authentication schemes that solely rely on the "realm" mechanism for		Authentication schemes that solely rely on the "realm" mechanism for
	establishing a protection space will expose credentials to all		establishing a protection space will expose credentials to all
	resources on a server. Clients that have successfully made		resources on a server. Clients that have successfully made
	authenticated requests with a resource can use the same		authenticated requests with a resource can use the same
	authentication credentials for other resources on the same server.		authentication credentials for other resources on the same server.
	This makes it possible for a different resource to harvest		This makes it possible for a different resource to harvest
	authentication credentials for other resources.		authentication credentials for other resources.
	skipping to change at page 14, line 18		skipping to change at page 13, line 49
	See Section 9 of [Part1] for the Acknowledgments related to this		See Section 9 of [Part1] for the Acknowledgments related to this
	document revision.		document revision.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-21 (work in progress),		draft-ietf-httpbis-p1-messaging-22 (work in progress),
	October 2012.		February 2013.
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-21 (work in progress),		draft-ietf-httpbis-p2-semantics-22 (work in progress),
	October 2012.		February 2013.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-21 (work in progress),		draft-ietf-httpbis-p6-cache-22 (work in progress),
	October 2012.		February 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	8.2. Informative References		8.2. Informative References
			[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
			Procedures for Message Header Fields", BCP 90, RFC 3864,
			September 2004.
	[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.,		[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.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	Appendix A. Changes from RFCs 2616 and 2617		Appendix A. Changes from RFCs 2616 and 2617
	The "realm" parameter isn't required anymore in general;		The framework for HTTP Authentication is now defined by this
			document, rather than RFC 2617.
			The "realm" parameter is no longer always required on challenges;
	consequently, the ABNF allows challenges without any auth parameters.		consequently, the ABNF allows challenges without any auth parameters.
	(Section 2)		(Section 2)
	The "token68" alternative to auth-param lists has been added for		The "token68" alternative to auth-param lists has been added for
	consistency with legacy authentication schemes such as "Basic".		consistency with legacy authentication schemes such as "Basic".
	(Section 2)		(Section 2)
	Introduce Authentication Scheme Registry. (Section 2.3)		This specification introduces the Authentication Scheme Registry,
			along with considerations for new authentication schemes.
			(Section 2.3)
	Appendix B. Imported ABNF		Appendix B. Imported ABNF
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),		Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
	CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double		CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
	quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any		quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
	8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII		8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
	character).		character).
	The rules below are defined in [Part1]:		The rules below are defined in [Part1]:
	BWS = <BWS, defined in [Part1], Section 3.2.1>		BWS = <BWS, defined in [Part1], Section 3.2.3>
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
	token = <token, defined in [Part1], Section 3.2.4>		token = <token, defined in [Part1], Section 3.2.6>
	Appendix C. Collected ABNF		Appendix C. Collected ABNF
	Authorization = credentials		Authorization = credentials
	BWS = <BWS, defined in [Part1], Section 3.2.1>		BWS = <BWS, defined in [Part1], Section 3.2.3>
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS		Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
	challenge ] )		challenge ] )
	Proxy-Authorization = credentials		Proxy-Authorization = credentials
	WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge		WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
	] )		] )
	auth-param = token BWS "=" BWS ( token / quoted-string )		auth-param = token BWS "=" BWS ( token / quoted-string )
	auth-scheme = token		auth-scheme = token
	challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(		challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
	OWS "," [ OWS auth-param ] ) ] ) ]		OWS "," [ OWS auth-param ] ) ] ) ]
	credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )		credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
	*( OWS "," [ OWS auth-param ] ) ] ) ]		*( OWS "," [ OWS auth-param ] ) ] ) ]
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
	token = <token, defined in [Part1], Section 3.2.4>		token = <token, defined in [Part1], Section 3.2.6>
	token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )		token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
	*"="		*"="
	Appendix D. Change Log (to be removed by RFC Editor before publication)		Appendix D. Change Log (to be removed by RFC Editor before publication)
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the first Working Group Last Call draft are summarized
	in <http://trac.tools.ietf.org/html/		in <http://trac.tools.ietf.org/html/
	draft-ietf-httpbis-p7-auth-19#appendix-C>.		draft-ietf-httpbis-p7-auth-19#appendix-C>.
	D.1. Since draft-ietf-httpbis-p7-auth-19		D.1. Since draft-ietf-httpbis-p7-auth-19
	skipping to change at page 17, line 23		skipping to change at page 17, line 23
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename		o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename
	b64token for clarity"		b64token for clarity"
	Other changes:		Other changes:
	o Conformance criteria and considerations regarding error handling		o Conformance criteria and considerations regarding error handling
	are now defined in Part 1.		are now defined in Part 1.
			D.3. Since draft-ietf-httpbis-p7-auth-21
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>:
			"Authentication and caching - max-age"
	Index		Index
	4		4
	401 Unauthorized (status code) 9		401 Unauthorized (status code) 9
	407 Proxy Authentication Required (status code) 9		407 Proxy Authentication Required (status code) 9
	A		A
	Authorization header field 9		Authorization header field 9
	C		C
	Canonical Root URI 6		Canonical Root URI 6
	G		G
	Grammar		Grammar
	auth-param 5		auth-param 5
	auth-scheme 5		auth-scheme 5
	Authorization 9		Authorization 9
	challenge 5		challenge 5
	credentials 6		credentials 6
	Proxy-Authenticate 10		Proxy-Authenticate 10
	Proxy-Authorization 11		Proxy-Authorization 10
	token68 5		token68 5
	WWW-Authenticate 11		WWW-Authenticate 11
	P		P
	Protection Space 6		Protection Space 6
	Proxy-Authenticate header field 10		Proxy-Authenticate header field 10
	Proxy-Authorization header field 10		Proxy-Authorization header field 10
	R		R
	Realm 6		Realm 6
	W		W
	WWW-Authenticate header field 11		WWW-Authenticate header field 10
	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. 40 change blocks.
	104 lines changed or deleted		97 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/