draft-ietf-httpbis-p7-auth-25.txt		draft-ietf-httpbis-p7-auth-26.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 November 17, 2013		Intended status: Standards Track February 6, 2014
	Expires: May 21, 2014		Expires: August 10, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Authentication		Hypertext Transfer Protocol (HTTP/1.1): Authentication
	draft-ietf-httpbis-p7-auth-25		draft-ietf-httpbis-p7-auth-26
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	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)		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.1.		The changes in this draft are summarized in Appendix D.2.
	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 May 21, 2014.		This Internet-Draft will expire on August 10, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	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 17		skipping to change at page 3, line 17
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	2. Access Authentication Framework . . . . . . . . . . . . . . . 4		2. Access Authentication Framework . . . . . . . . . . . . . . . 4
	2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4		2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4
	2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6		2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
	3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7		3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7
	3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7		3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7
	4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7		4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
	4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 7		4.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 8		4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 8		4.3. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 9
	4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9		4.4. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10		5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10
	5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10		5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10
	5.1.2. Considerations for New Authentication Schemes . . . . 10		5.1.2. Considerations for New Authentication Schemes . . . . 10
	5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11		5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12
	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 . . . . . . . 12		6.1. Confidentiality of Credentials . . . . . . . . . . . . . . 13
	6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13		6.2. Authentication Credentials and Idle Clients . . . . . . . 13
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		6.3. Protection Spaces . . . . . . . . . . . . . . . . . . . . 14
			7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15		Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 16
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15		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) . . . . . . . . . . . . . . . . . . . . 17
	D.1. Since draft-ietf-httpbis-p7-auth-24 . . . . . . . . . . . 16		D.1. Since draft-ietf-httpbis-p7-auth-24 . . . . . . . . . . . 17
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		D.2. Since draft-ietf-httpbis-p7-auth-25 . . . . . . . . . . . 18
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 access control and authentication. It		HTTP provides a general framework for access control and
	includes the relevant parts of RFC 2616 with only minor changes		authentication, via an extensible set of challenge-response
	([RFC2616]), plus the general framework for HTTP authentication, as		authentication schemes, which can be used by a server to challenge a
	previously defined in "HTTP Authentication: Basic and Digest Access		client request and by a client to provide authentication information.
	Authentication" ([RFC2617]).		This document defines HTTP/1.1 authentication in terms of the
			architecture defined in [Part1], including the general framework
			previously described in RFC 2617 and the related fields and status
			codes previously defined in RFC 2616.
	HTTP provides several OPTIONAL challenge-response authentication		The IANA Authentication Scheme Registry (Section 5.1) lists
	schemes that can be used by a server to challenge a client request		registered authentication schemes and their corresponding
	and by a client to provide authentication information. The "basic"		specifications, including the "basic" and "digest" authentication
	and "digest" authentication schemes continue to be specified in RFC		schemes previously defined by 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].
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] with the list rule extension defined in Section		notation of [RFC5234] with a list extension, defined in Section 7 of
	7 of [Part1]. Appendix B describes rules imported from other		[Part1], that allows for compact definition of comma-separated lists
	documents. Appendix C shows the collected ABNF with the list rule		using a '#' operator (similar to how the '*' operator indicates
	expanded.		repetition). Appendix B describes rules imported from other
			documents. Appendix C shows the collected grammar with all list
			operators expanded to standard ABNF notation.
	2. Access Authentication Framework		2. Access Authentication Framework
	2.1. Challenge and Response		2.1. Challenge and Response
	HTTP provides a simple challenge-response authentication framework		HTTP provides a simple challenge-response authentication framework
	that can be used by a server to challenge a client request and by a		that can be used by a server to challenge a client request and by a
	client to provide authentication information. It uses a case-		client to provide authentication information. It uses a case-
	insensitive token as a means to identify the authentication scheme,		insensitive token as a means to identify the authentication scheme,
	followed by additional information necessary for achieving		followed by additional information necessary for achieving
	authentication via that scheme. The latter can either be a comma-		authentication via that scheme. The latter can either be a comma-
	separated list of parameters or a single sequence of characters		separated list of parameters or a single sequence of characters
	capable of holding base64-encoded information.		capable of holding base64-encoded information.
	Parameters are name-value pairs where the name is matched case-		Authentication parameters are name=value pairs, where the name token
	insensitively, and each parameter name MUST only occur once per		is matched case-insensitively, and each parameter name MUST only
	challenge.		occur once per challenge.
	auth-scheme = token		auth-scheme = token
	auth-param = token BWS "=" BWS ( token / quoted-string )		auth-param = token BWS "=" BWS ( token / quoted-string )
	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]).
	The 401 (Unauthorized) response message is used by an origin server		A 401 (Unauthorized) response message is used by an origin server to
	to challenge the authorization of a user agent. This response MUST		challenge the authorization of a user agent, including a WWW-
	include a WWW-Authenticate header field containing at least one		Authenticate header field containing at least one challenge
	challenge applicable to the requested resource.		applicable to the requested resource.
	The 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 and MUST include a		proxy to challenge the authorization of a client, including a Proxy-
	Proxy-Authenticate header field containing at least one challenge		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 challenges containing unknown		Note: Many clients fail to parse a challenge that contains an
	schemes. A workaround for this problem is to list well-supported		unknown scheme. A workaround for this problem is to list well-
	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)
	-- can do so by including an Authorization header field with the		-- can do so by including an Authorization header field with the
	request.		request.
	A client that wishes to authenticate itself with a proxy -- usually,		A client that wishes to authenticate itself with a proxy -- usually,
	but not necessarily, after receiving a 407 (Proxy Authentication		but not necessarily, after receiving a 407 (Proxy Authentication
	Required) -- can do so by including a Proxy-Authorization header		Required) -- can do so by including a Proxy-Authorization header
	field with the request.		field with the request.
	Both the Authorization field value and the Proxy-Authorization field		Both the Authorization field value and the Proxy-Authorization field
	value contain the client's credentials for the realm of the resource		value contain the client's credentials for the realm of the resource
	being requested, based upon a challenge received in a response		being requested, based upon a challenge received in a response
	(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. Transmission of
			credentials within header field values implies significant security
			considerations regarding the confidentiality of the underlying
			connection, as described in Section 6.1.
	credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]		credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
	Upon receipt of a request for a protected resource that omits		Upon receipt of a request for a protected resource that omits
	credentials, contains invalid credentials (e.g., a bad password) or		credentials, contains invalid credentials (e.g., a bad password) or
	partial credentials (e.g., when the authentication scheme requires		partial credentials (e.g., when the authentication scheme requires
	more than one round trip), an origin server SHOULD send a 401		more than one round trip), an origin server SHOULD send a 401
	(Unauthorized) response that contains a WWW-Authenticate header field		(Unauthorized) response that contains a WWW-Authenticate header field
	with at least one (possibly new) challenge applicable to the		with at least one (possibly new) challenge applicable to the
	requested resource.		requested resource.
	Likewise, upon receipt of a request that requires authentication by		Likewise, upon receipt of a request that omits proxy credentials or
	proxies that omit credentials or contain invalid or partial		contains invalid or partial proxy credentials, a proxy that requires
	credentials, a proxy SHOULD send a 407 (Proxy Authentication		authentication SHOULD generate a 407 (Proxy Authentication Required)
	Required) response that contains a Proxy-Authenticate header field		response that contains a Proxy-Authenticate header field with at
	with a (possibly new) challenge applicable to the proxy.		least one (possibly new) challenge applicable to the proxy.
	A server receiving credentials that are valid, but not adequate to		A server that receives valid credentials which are 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 6.5.3 of [Part2]).		(Section 6.5.3 of [Part2]).
	HTTP does not restrict applications to this simple challenge-response		HTTP does not restrict applications to this simple challenge-response
	framework for access authentication. Additional mechanisms can be		framework for access authentication. Additional mechanisms can be
	used, such as authentication at the transport level or via message		used, such as authentication at the transport level or via message
	encapsulation, and with additional header fields specifying		encapsulation, and with additional header fields specifying
	authentication information. However, such additional mechanisms are		authentication information. However, such additional mechanisms are
	not defined by this specification.		not defined by this specification.
	A proxy MUST forward the WWW-Authenticate and Authorization header
	fields unmodified and follow the rules found in Section 4.1.
	2.2. Protection Space (Realm)		2.2. Protection Space (Realm)
	The authentication parameter realm is reserved for use by		The "realm" authentication parameter is reserved for use by
	authentication schemes that wish to indicate the scope of protection.		authentication schemes that wish to indicate a 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		which can have additional semantics specific to the authentication
	scheme. Note that a response can have multiple challenges with the		scheme. Note that a response can have multiple challenges with the
	skipping to change at page 7, line 20		skipping to change at page 7, line 25
	syntax. Recipients might have to support both token and quoted-		syntax. Recipients might have to support both token and quoted-
	string syntax for maximum interoperability with existing clients that		string syntax for maximum interoperability with existing clients that
	have been accepting both notations for a long time.		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 origin server MUST send a WWW-Authenticate		the target resource. The server generating a 401 response MUST send
	header field (Section 4.4) containing at least one challenge		a WWW-Authenticate header field (Section 4.1) containing at least one
	applicable to the target resource. If the request included		challenge applicable to the target resource.
	authentication credentials, then the 401 response indicates that
	authorization has been refused for those credentials. The user agent		If the request included authentication credentials, then the 401
	MAY repeat the request with a new or replaced Authorization header		response indicates that authorization has been refused for those
	field (Section 4.1). If the 401 response contains the same challenge		credentials. The user agent MAY repeat the request with a new or
	as the prior response, and the user agent has already attempted		replaced Authorization header field (Section 4.2). If the 401
	authentication at least once, then the user agent SHOULD present the		response contains the same challenge as the prior response, and the
	enclosed representation to the user, since it usually contains		user agent has already attempted authentication at least once, then
	relevant diagnostic information.		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
	The 407 (Proxy Authentication Required) status code is similar to 401		The 407 (Proxy Authentication Required) status code is similar to 401
	(Unauthorized), but indicates that the client needs to authenticate		(Unauthorized), but indicates that the client needs to authenticate
	itself in order to use a proxy. The proxy MUST send a Proxy-		itself in order to use a proxy. The proxy MUST send a Proxy-
	Authenticate header field (Section 4.2) containing a challenge		Authenticate header field (Section 4.3) containing a challenge
	applicable to that proxy for the target resource. The client MAY		applicable to that proxy for the target resource. The client MAY
	repeat the request with a new or replaced Proxy-Authorization header		repeat the request with a new or replaced Proxy-Authorization header
	field (Section 4.3).		field (Section 4.4).
	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 header fields
	fields related to authentication.		related to the HTTP authentication framework.
	4.1. Authorization		4.1. WWW-Authenticate
			The "WWW-Authenticate" header field indicates the authentication
			scheme(s) and parameters applicable to the target resource.
			WWW-Authenticate = 1#challenge
			A server generating a 401 (Unauthorized) response MUST send a WWW-
			Authenticate header field containing at least one challenge. A
			server MAY generate a WWW-Authenticate header field in other response
			messages to indicate that supplying credentials (or different
			credentials) might affect the response.
			A proxy forwarding a response MUST NOT modify any WWW-Authenticate
			fields in that response.
			User agents are advised to take special care in parsing the field
			value, as it might contain more than one challenge, and each
			challenge can contain a comma-separated list of authentication
			parameters. Furthermore, the header field itself can occur multiple
			times.
			For instance:
			WWW-Authenticate: Newauth realm="apps", type=1,
			title="Login to \"apps\"", Basic realm="simple"
			This header field contains two challenges; one for the "Newauth"
			scheme with a realm value of "apps", and two additional parameters
			"type" and "title", and another one for the "Basic" scheme with a
			realm value of "simple".
			Note: The challenge grammar production uses the list syntax as
			well. Therefore, a sequence of comma, whitespace, and comma can
			be considered either as applying to the preceding challenge, or to
			be an empty entry in the list of challenges. In practice, this
			ambiguity does not affect the semantics of the header field value
			and thus is harmless.
			4.2. Authorization
	The "Authorization" header field allows a user agent to authenticate		The "Authorization" header field allows a user agent to authenticate
	itself with an origin server -- usually, but not necessarily, after		itself with an origin server -- usually, but not necessarily, after
	receiving a 401 (Unauthorized) response. Its value consists of		receiving a 401 (Unauthorized) response. Its value consists of
	credentials containing the authentication information of the user		credentials containing the authentication information of the user
	agent for the realm of the resource being requested.		agent for the realm of the 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 are presumed to be valid for all other requests within		credentials are presumed to be valid for all other requests within
	this realm (assuming that the authentication scheme itself does not		this realm (assuming that the authentication scheme itself does not
	require otherwise, such as credentials that vary according to a		require otherwise, such as credentials that vary according to a
	challenge value or using synchronized clocks).		challenge value or using synchronized clocks).
	See Section 3.2 of [Part6] for details of and requirements pertaining		A proxy forwarding a request MUST NOT modify any Authorization fields
	to handling of the Authorization field by HTTP caches.		in that request. See Section 3.2 of [Part6] for details of and
			requirements pertaining to handling of the Authorization field by
			HTTP caches.
	4.2. Proxy-Authenticate		4.3. 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]). A proxy MUST send at least one Proxy-Authenticate
	Authentication Required) response.		header field in each 407 (Proxy Authentication Required) response
			that it generates.
	Proxy-Authenticate = 1#challenge		Proxy-Authenticate = 1#challenge
	Unlike WWW-Authenticate, the Proxy-Authenticate header field applies		Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
	only to the next outbound client on the response chain that chose to		only to the next outbound client on the response chain. This is
	direct its request to the responding proxy. If that recipient is		because only the client that chose a given proxy is likely to have
	also a proxy, it will generally consume the Proxy-Authenticate header		the credentials necessary for authentication. However, when multiple
	field (and generate an appropriate Proxy-Authorization in a		proxies are used within the same administrative domain, such as
	subsequent request) rather than forward the header field to its own		office and regional caching proxies within a large corporate network,
	outbound clients. However, if a recipient proxy needs to obtain its		it is common for credentials to be generated by the user agent and
	own credentials by requesting them from a further outbound client, it		passed through the hierarchy until consumed. Hence, in such a
	will generate its own 407 response, which might have the appearance		configuration, it will appear as if Proxy-Authenticate is being
	of forwarding the Proxy-Authenticate header field if both proxies use		forwarded because each proxy will send the same challenge set.
	the same challenge set.
	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.1 for details.
	4.3. Proxy-Authorization		4.4. 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 that 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 client for the proxy and/or realm of the resource		information of the client for the proxy and/or realm of the resource
	being requested.		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 inbound proxy that demanded authentication using the		only to the next inbound proxy that demanded authentication using the
	Proxy-Authenticate field. When multiple proxies are used in a chain,		Proxy-Authenticate field. When multiple proxies are used in a chain,
	the Proxy-Authorization header field is consumed by the first inbound		the Proxy-Authorization header field is consumed by the first inbound
	proxy that was expecting to receive credentials. A proxy MAY relay		proxy that was expecting to receive credentials. A proxy MAY relay
	the credentials from the client request to the next proxy if that is		the credentials from the client request to the next proxy if that is
	the mechanism by which the proxies cooperatively authenticate a given		the mechanism by which the proxies cooperatively authenticate a given
	request.		request.
	4.4. WWW-Authenticate
	The "WWW-Authenticate" header field consists of at least one
	challenge that indicates the authentication scheme(s) and parameters
	applicable to the effective request URI (Section 5.5 of [Part1]).
	It MUST be included in 401 (Unauthorized) response messages and MAY
	be included in other response messages to indicate that supplying
	credentials (or different credentials) might affect the response.
	WWW-Authenticate = 1#challenge
	User agents are advised to take special care in parsing the field
	value, as it might contain more than one challenge, and each
	challenge can contain a comma-separated list of authentication
	parameters. Furthermore, the header field itself can occur multiple
	times.
	For instance:
	WWW-Authenticate: Newauth realm="apps", type=1,
	title="Login to \"apps\"", Basic realm="simple"
	This header field contains two challenges; one for the "Newauth"
	scheme with a realm value of "apps", and two additional parameters
	"type" and "title", and another one for the "Basic" scheme with a
	realm value of "simple".
	Note: The challenge grammar production uses the list syntax as
	well. Therefore, a sequence of comma, whitespace, and comma can
	be considered either as applying to the preceding challenge, or to
	be an empty entry in the list of challenges. In practice, this
	ambiguity does not affect the semantics of the header field value
	and thus is harmless.
	5. IANA Considerations		5. IANA Considerations
	5.1. Authentication Scheme Registry		5.1. Authentication Scheme Registry
	The HTTP Authentication Scheme Registry defines the name space for		The HTTP Authentication Scheme Registry defines the name space for
	the authentication schemes in challenges and credentials. It will be		the authentication schemes in challenges and credentials. It will be
	created and maintained at (the suggested URI)		created and maintained at (the suggested URI)
	<http://www.iana.org/assignments/http-authschemes>.		<http://www.iana.org/assignments/http-authschemes>.
	5.1.1. Procedure		5.1.1. Procedure
	skipping to change at page 12, line 25		skipping to change at page 12, line 31
	Registry maintained at <http://www.iana.org/assignments/		Registry maintained at <http://www.iana.org/assignments/
	message-headers/message-header-index.html>.		message-headers/message-header-index.html>.
	This document defines the following HTTP header fields, so their		This document defines the following HTTP header fields, so their
	associated registry entries shall be updated according to the		associated registry entries shall be updated according to the
	permanent registrations below (see [BCP90]):		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.2 |
	| Proxy-Authenticate | http | standard | Section 4.2 |		| Proxy-Authenticate | http | standard | Section 4.3 |
	| Proxy-Authorization | http | standard | Section 4.3 |		| Proxy-Authorization | http | standard | Section 4.4 |
	| WWW-Authenticate | http | standard | Section 4.4 |		| WWW-Authenticate | http | standard | Section 4.1 |
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	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 developers, information providers,		This section is meant to inform developers, information providers,
	and users of known security concerns specific to HTTP/1.1		and users of known security concerns specific to HTTP authentication.
	authentication. More general security considerations are addressed		More general security considerations are addressed in HTTP messaging
	in HTTP messaging [Part1] and semantics [Part2].		[Part1] and semantics [Part2].
	6.1. Authentication Credentials and Idle Clients		Everything about the topic of HTTP authentication is a security
			consideration, so the list of considerations below is not exhaustive.
			Furthermore, it is limited to security considerations regarding the
			authentication framework, in general, rather than discussing all of
			the potential considerations for specific authentication schemes
			(which ought to be documented in the specifications that define those
			schemes). Various organizations maintain topical information and
			links to current research on Web application security (e.g.,
			[OWASP]), including common pitfalls for implementing and using the
			authentication schemes found in practice.
			6.1. Confidentiality of Credentials
			The HTTP authentication framework does not define a single mechanism
			for maintaining the confidentiality of credentials; instead, each
			authentication scheme defines how the credentials are encoded prior
			to transmission. While this provides flexibility for the development
			of future authentication schemes, it is inadequate for the protection
			of existing schemes that provide no confidentiality on their own, or
			that do not sufficiently protect against replay attacks.
			Furthermore, if the server expects credentials that are specific to
			each individual user, the exchange of those credentials will have the
			effect of identifying that user even if the content within
			credentials remains confidential.
			HTTP depends on the security properties of the underlying transport
			or session-level connection to provide confidential transmission of
			header fields. In other words, if a server limits access to
			authenticated users using this framework, the server needs to ensure
			that the connection is properly secured in accordance with the nature
			of the authentication scheme used. For example, services that depend
			on individual user authentication often require a connection to be
			secured with TLS ("Transport Layer Security", [RFC5246]) prior to
			exchanging any credentials.
			6.2. 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 does not provide a mechanism for the		information indefinitely. HTTP does not provide a mechanism for the
	origin server to direct clients to discard these cached credentials,		origin server to direct clients to discard these cached credentials,
	since the protocol has no awareness of how credentials are obtained		since the protocol has no awareness of how credentials are obtained
	or managed by the user agent. The mechanisms for expiring or		or managed by the user agent. The mechanisms for expiring or
	revoking credentials can be specified as part of an authentication		revoking credentials can be specified as part of an authentication
	scheme definition.		scheme definition.
	Circumstances under which credential caching can interfere with the		Circumstances under which credential caching can interfere with the
	skipping to change at page 13, line 18		skipping to change at page 14, line 11
	o Applications that 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.
	User agents that cache credentials are encouraged to provide a		User agents that cache credentials are encouraged to provide a
	readily accessible mechanism for discarding cached credentials under		readily accessible mechanism for discarding cached credentials under
	user control.		user control.
	6.2. Protection Spaces		6.3. 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 an origin server. Clients that have successfully made		resources on an origin 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 origin		authentication credentials for other resources on the same origin
	server. This makes it possible for a different resource to harvest		server. This makes it possible for a different resource to harvest
	authentication credentials for other resources.		authentication credentials for other resources.
	This is of particular concern when an origin server hosts resources		This is of particular concern when an origin server hosts resources
	skipping to change at page 14, line 4		skipping to change at page 14, line 42
	Authentication Framework, previously defined in RFC 2617. We thank		Authentication Framework, previously defined in RFC 2617. We thank
	John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.		John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D.
	Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for		Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for
	their work on that specification. See Section 6 of [RFC2617] for		their work on that specification. See Section 6 of [RFC2617] for
	further acknowledgements.		further acknowledgements.
	See Section 10 of [Part1] for the Acknowledgments related to this		See Section 10 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-25 (work in progress),		draft-ietf-httpbis-p1-messaging-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p2-semantics-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p6-cache-26 (work in progress),
	November 2013.		February 2014.
	[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		[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
			Applications and Web Services", The Open Web Application
			Security Project (OWASP) 2.0.1, July 2005,
			<https://www.owasp.org/>.
	[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.
	[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.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	Appendix A. Changes from RFCs 2616 and 2617		Appendix A. Changes from RFCs 2616 and 2617
	The framework for HTTP Authentication is now defined by this		The framework for HTTP Authentication is now defined by this
	document, rather than RFC 2617.		document, rather than RFC 2617.
	The "realm" parameter is no longer always required on challenges;		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
	skipping to change at page 17, line 5		skipping to change at page 18, line 5
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/510>: "SECDIR review		o <http://tools.ietf.org/wg/httpbis/trac/ticket/510>: "SECDIR review
	of draft-ietf-httpbis-p7-auth-24"		of draft-ietf-httpbis-p7-auth-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/513>: "APPSDIR		o <http://tools.ietf.org/wg/httpbis/trac/ticket/513>: "APPSDIR
	review of draft-ietf-httpbis-p7-auth-24"		review of draft-ietf-httpbis-p7-auth-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/516>: "note about		o <http://tools.ietf.org/wg/httpbis/trac/ticket/516>: "note about
	WWW-A parsing potentially misleading"		WWW-A parsing potentially misleading"
			D.2. Since draft-ietf-httpbis-p7-auth-25
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/522>: "Gen-art
			review of draft-ietf-httpbis-p7-auth-25"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/536>: "IESG ballot
			on draft-ietf-httpbis-p7-auth-25"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
			'stateless' to Abstract"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/539>: "mention TLS
			vs plain text passwords or dict attacks?"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
			introduction of list rule"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
			security considerations with pointers to current research"
	Index		Index
	4		4
	401 Unauthorized (status code) 7		401 Unauthorized (status code) 7
	407 Proxy Authentication Required (status code) 7		407 Proxy Authentication Required (status code) 7
	A		A
	Authorization header field 7		Authorization header field 8
	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 8		Authorization 8
	challenge 5		challenge 5
	credentials 5		credentials 6
	Proxy-Authenticate 8		Proxy-Authenticate 9
	Proxy-Authorization 8		Proxy-Authorization 9
	token68 5		token68 5
	WWW-Authenticate 9		WWW-Authenticate 8
	P		P
	Protection Space 6		Protection Space 6
	Proxy-Authenticate header field 8		Proxy-Authenticate header field 9
	Proxy-Authorization header field 8		Proxy-Authorization header field 9
	R		R
	Realm 6		Realm 6
	W		W
	WWW-Authenticate header field 9		WWW-Authenticate header field 8
	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. 51 change blocks.
	154 lines changed or deleted		233 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/