draft-ietf-httpbis-p7-auth-26.txt		draft-ietf-httpbis-p7-auth-latest.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 February 6, 2014		Intended status: Standards Track June 2014
	Expires: August 10, 2014		Expires: December 3, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Authentication		Hypertext Transfer Protocol (HTTP/1.1): Authentication
	draft-ietf-httpbis-p7-auth-26		draft-ietf-httpbis-p7-auth-latest
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level protocol for distributed, collaborative, hypermedia information		level protocol for distributed, collaborative, hypermedia information
	systems. This document defines the HTTP Authentication framework.		systems. This document defines the HTTP Authentication framework.
	Editorial Note (To be removed by RFC Editor)		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.		_This is a temporary document for the purpose of tracking the
			editorial changes made during the AUTH48 (RFC publication) phase._
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This 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 August 10, 2014.		This Internet-Draft will expire on December 3, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	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 . . . . . . . . . . . . . . . . . . . 8
	4.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 8		4.1. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 9		4.3. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 9
	4.4. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 9		4.4. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10
	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 . . . . . . . . . . . . . . . . . 12		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. Confidentiality of Credentials . . . . . . . . . . . . . . 13		6.1. Confidentiality of Credentials . . . . . . . . . . . . . . 13
	6.2. Authentication Credentials and Idle Clients . . . . . . . 13		6.2. Authentication Credentials and Idle Clients . . . . . . . 13
	6.3. Protection Spaces . . . . . . . . . . . . . . . . . . . . 14		6.3. Protection Spaces . . . . . . . . . . . . . . . . . . . . 14
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	8.2. Informative References . . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16		Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 16		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 16
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 16
	Appendix D. Change Log (to be removed by RFC Editor before		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	publication) . . . . . . . . . . . . . . . . . . . . 17
	D.1. Since draft-ietf-httpbis-p7-auth-24 . . . . . . . . . . . 17
	D.2. Since draft-ietf-httpbis-p7-auth-25 . . . . . . . . . . . 18
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	HTTP provides a general framework for access control and		HTTP provides a general framework for access control and
	authentication, via an extensible set of challenge-response		authentication, via an extensible set of challenge-response
	authentication schemes, which can be used by a server to challenge a		authentication schemes, which can be used by a server to challenge a
	client request and by a client to provide authentication information.		client request and by a client to provide authentication information.
	This document defines HTTP/1.1 authentication in terms of the		This document defines HTTP/1.1 authentication in terms of the
	architecture defined in [Part1], including the general framework		architecture defined in "Hypertext Transfer Protocol (HTTP/1.1):
	previously described in RFC 2617 and the related fields and status		Message Syntax and Routing" [RFC7230], including the general
	codes previously defined in RFC 2616.		framework previously described in "HTTP Authentication: Basic and
			Digest Access Authentication" [RFC2617] and the related fields and
			status codes previously defined in "Hypertext Transfer Protocol --
			HTTP/1.1" [RFC2616].
	The IANA Authentication Scheme Registry (Section 5.1) lists		The IANA Authentication Scheme Registry (Section 5.1) lists
	registered authentication schemes and their corresponding		registered authentication schemes and their corresponding
	specifications, including the "basic" and "digest" authentication		specifications, including the "basic" and "digest" authentication
	schemes previously defined by RFC 2617.		schemes previously defined by RFC 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 [RFC7230].
	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 a list extension, defined in Section 7 of		notation of [RFC5234] with a list extension, defined in Section 7 of
	[Part1], that allows for compact definition of comma-separated lists		[RFC7230], that allows for compact definition of comma-separated
	using a '#' operator (similar to how the '*' operator indicates		lists using a '#' operator (similar to how the '*' operator indicates
	repetition). Appendix B describes rules imported from other		repetition). Appendix B describes rules imported from other
	documents. Appendix C shows the collected grammar with all list		documents. Appendix C shows the collected grammar with all list
	operators expanded to standard ABNF notation.		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 be either 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.
	Authentication parameters are name=value pairs, where the name token		Authentication parameters are name=value pairs, where the name token
	is matched case-insensitively, and each parameter name MUST only		is matched case-insensitively, and each parameter name MUST only
	occur once per 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]).
	A 401 (Unauthorized) response message is used by an origin server to		A 401 (Unauthorized) response message is used by an origin server to
	challenge the authorization of a user agent, including a WWW-		challenge the authorization of a user agent, including a WWW-
	Authenticate header field containing at least one challenge		Authenticate header field containing at least one challenge
	applicable to the requested resource.		applicable to the requested resource.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 29 ¶
	(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 omits proxy credentials or		Likewise, upon receipt of a request that omits proxy credentials or
	contains invalid or partial proxy credentials, a proxy that requires		contains invalid or partial proxy credentials, a proxy that requires
	authentication SHOULD generate a 407 (Proxy Authentication Required)		authentication SHOULD generate a 407 (Proxy Authentication Required)
	response that contains a Proxy-Authenticate header field with at		response that contains a Proxy-Authenticate header field with at
	least one (possibly new) challenge applicable to the proxy.		least one (possibly new) challenge applicable to the proxy.
	A server that receives valid credentials which are not adequate to		A server that receives valid credentials that 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 [RFC7231]).
	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.
	2.2. Protection Space (Realm)		2.2. Protection Space (Realm)
	The ""realm"" authentication parameter is reserved for use by		The ""realm"" authentication parameter is reserved for use by
	authentication schemes that wish to indicate a 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 [RFC7230]) of the server being accessed, in combination with
	realm value if present. These realms allow the protected resources		the realm value if present. These realms allow the protected
	on a server to be partitioned into a set of protection spaces, each		resources on a server to be partitioned into a set of protection
	with its own authentication scheme and/or authorization database.		spaces, each with its own authentication scheme and/or authorization
	The realm value is a string, generally assigned by the origin server,		database. The realm value is a string, generally assigned by the
	which can have additional semantics specific to the authentication		origin server, that can have additional semantics specific to the
	scheme. Note that a response can have multiple challenges with the		authentication scheme. Note that a response can have multiple
	same auth-scheme but different realms.		challenges with the same auth-scheme but with 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 user agent MAY reuse the same credentials for all other requests		the user agent MAY reuse the same credentials for all other requests
	within that protection space for a period of time determined by the		within that protection space for a period of time determined by the
	authentication scheme, parameters, and/or user preferences (such as a		authentication scheme, parameters, and/or user preferences (such as a
	configurable inactivity timeout). Unless specifically allowed by the		configurable inactivity timeout). Unless specifically allowed by the
	authentication scheme, a single protection space cannot extend		authentication scheme, a single protection space cannot extend
	outside the scope of its server.		outside the scope of its server.
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 44 ¶
	credentials. The user agent MAY repeat the request with a new or		credentials. The user agent MAY repeat the request with a new or
	replaced Authorization header field (Section 4.2). If the 401		replaced Authorization header field (Section 4.2). If the 401
	response contains the same challenge as the prior response, and the		response contains the same challenge as the prior response, and the
	user agent has already attempted authentication at least once, then		user agent has already attempted authentication at least once, then
	the user agent SHOULD present the enclosed representation to the		the user agent SHOULD present the enclosed representation to the
	user, since it usually contains relevant diagnostic information.		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		The "407 (Proxy Authentication Required)" status code is similar to
	401 (Unauthorized), but indicates that the client needs to		401 (Unauthorized), but it indicates that the client needs to
	authenticate itself in order to use a proxy. The proxy MUST send a		authenticate itself in order to use a proxy. The proxy MUST send a
	Proxy-Authenticate header field (Section 4.3) containing a challenge		Proxy-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.4).		field (Section 4.4).
	4. Header Field Definitions		4. Header Field Definitions
	This section defines the syntax and semantics of header fields		This section defines the syntax and semantics of header fields
	related to the HTTP authentication framework.		related to the HTTP authentication framework.
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 22 ¶
	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).
	A proxy forwarding a request MUST NOT modify any Authorization fields		A proxy forwarding a request MUST NOT modify any Authorization fields
	in that request. See Section 3.2 of [Part6] for details of and		in that request. See Section 3.2 of [RFC7234] for details of and
	requirements pertaining to handling of the Authorization field by		requirements pertaining to handling of the Authorization field by
	HTTP caches.		HTTP caches.
	4.3. 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]). A proxy MUST send at least one Proxy-Authenticate		of [RFC7230]). A proxy MUST send at least one Proxy-Authenticate
	header field in each 407 (Proxy Authentication Required) response		header field in each 407 (Proxy Authentication Required) response
	that it generates.		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. This is		only to the next outbound client on the response chain. This is
	because only the client that chose a given proxy is likely to have		because only the client that chose a given proxy is likely to have
	the credentials necessary for authentication. However, when multiple		the credentials necessary for authentication. However, when multiple
	proxies are used within the same administrative domain, such as		proxies are used within the same administrative domain, such as
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 28 ¶
	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.
	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 "Hypertext Transfer Protocol (HTTP) Authentication Scheme
	the authentication schemes in challenges and credentials. It will be		Registry" defines the namespace for the authentication schemes in
	created and maintained at (the suggested URI)		challenges and credentials. It has been created and is now
	<http://www.iana.org/assignments/http-authschemes>.		maintained at <http://www.iana.org/assignments/http-authschemes>.
	5.1.1. Procedure		5.1.1. Procedure
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Authentication Scheme Name		o Authentication Scheme Name
	o Pointer to specification text		o Pointer to specification text
	o Notes (optional)		o Notes (optional)
	Values to be added to this name space require IETF Review (see		Values to be added to this namespace require IETF Review (see
	[RFC5226], Section 4.1).		[RFC5226], Section 4.1).
	5.1.2. Considerations for New Authentication Schemes		5.1.2. Considerations for New Authentication Schemes
	There are certain aspects of the HTTP Authentication Framework that		There are certain aspects of the HTTP Authentication Framework that
	put constraints on how new authentication schemes can work:		put constraints on how new authentication schemes can work:
	o HTTP authentication is presumed to be stateless: all of the		o HTTP authentication is presumed to be stateless: all of the
	information necessary to authenticate a request MUST be provided		information necessary to authenticate a request MUST be provided
	in the request, rather than be dependent on the server remembering		in the request, rather than be dependent on the server remembering
	prior requests. Authentication based on, or bound to, the		prior requests. Authentication based on, or bound to, the
	underlying connection is outside the scope of this specification		underlying connection is outside the scope of this specification
	and inherently flawed unless steps are taken to ensure that the		and inherently flawed unless steps are taken to ensure that the
	connection cannot be used by any party other than the		connection cannot be used by any party other than the
	authenticated user (see Section 2.3 of [Part1]).		authenticated user (see Section 2.3 of [RFC7230]).
	o The authentication parameter "realm" is reserved for defining		o The authentication parameter "realm" is reserved for defining
	Protection Spaces as defined in Section 2.2. New schemes MUST NOT		protection spaces as described in Section 2.2. New schemes MUST
	use it in a way incompatible with that definition.		NOT use it in a way incompatible with that definition.
	o The "token68" notation was introduced for compatibility with		o The "token68" notation was introduced for compatibility with
	existing authentication schemes and can only be used once per		existing authentication schemes and can only be used once per
	challenge or credential. New schemes thus ought to use the "auth-		challenge or credential. Thus, new schemes ought to use the auth-
	param" syntax instead, because otherwise future extensions will be		param syntax instead, because otherwise future extensions will be
	impossible.		impossible.
	o The parsing of challenges and credentials is defined by this		o The parsing of challenges and credentials is defined by this
	specification, and cannot be modified by new authentication		specification and cannot be modified by new authentication
	schemes. When the auth-param syntax is used, all parameters ought		schemes. When the auth-param syntax is used, all parameters ought
	to support both token and quoted-string syntax, and syntactical		to support both token and quoted-string syntax, and syntactical
	constraints ought to be defined on the field value after parsing		constraints ought to be defined on the field value after parsing
	(i.e., quoted-string processing). This is necessary so that		(i.e., quoted-string processing). This is necessary so that
	recipients can use a generic parser that applies to all		recipients can use a generic parser that applies to all
	authentication schemes.		authentication schemes.
	Note: The fact that the value syntax for the "realm" parameter is		Note: The fact that the value syntax for the "realm" parameter is
	restricted to quoted-string was a bad design choice not to be		restricted to quoted-string was a bad design choice not to be
	repeated for new parameters.		repeated for new parameters.
	o Definitions of new schemes ought to define the treatment of		o Definitions of new schemes ought to define the treatment of
	unknown extension parameters. In general, a "must-ignore" rule is		unknown extension parameters. In general, a "must-ignore" rule is
	preferable over "must-understand", because otherwise it will be		preferable to a "must-understand" rule, because otherwise it will
	hard to introduce new parameters in the presence of legacy		be hard to introduce new parameters in the presence of legacy
	recipients. Furthermore, it's good to describe the policy for		recipients. Furthermore, it's good to describe the policy for
	defining new parameters (such as "update the specification", or		defining new parameters (such as "update the specification" or
	"use this registry").		"use this registry").
	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
	(Section 5.2.2.6 of [Part6]), within the scope of the request they		(Section 5.2.2.6 of [RFC7234]), within the scope of the request in
	appear in.		which they appear.
	Therefore, new authentication schemes that 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", Section 5.2.1.5 of [Part6]) or response		(e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response
	directives (e.g., "private").		directives (e.g., "private").
	5.2. Status Code Registration		5.2. Status Code Registration
	The HTTP Status Code Registry located at		The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
	<http://www.iana.org/assignments/http-status-codes> shall be updated		at <http://www.iana.org/assignments/http-status-codes> has been
	with the registrations below:		updated with the registrations below:
	+-------+-------------------------------+-------------+		+-------+-------------------------------+-------------+
	| 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
	HTTP header fields are registered within the Message Header Field		HTTP header fields are registered within the "Message Headers"
	Registry maintained at <http://www.iana.org/assignments/		registry maintained at
	message-headers/message-header-index.html>.		<http://www.iana.org/assignments/message-headers/>.
	This document defines the following HTTP header fields, so their		This document defines the following HTTP header fields, so the
	associated registry entries shall be updated according to the		"Permanent Message Header Field Names" registry has been updated
	permanent registrations below (see [BCP90]):		accordingly (see [BCP90]).
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	| Authorization | http | standard | Section 4.2 |		| Authorization | http | standard | Section 4.2 |
	| Proxy-Authenticate | http | standard | Section 4.3 |		| Proxy-Authenticate | http | standard | Section 4.3 |
	| Proxy-Authorization | http | standard | Section 4.4 |		| Proxy-Authorization | http | standard | Section 4.4 |
	| WWW-Authenticate | http | standard | Section 4.1 |		| WWW-Authenticate | http | standard | Section 4.1 |
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	skipping to change at page 12, line 44 ¶		skipping to change at page 13, line 4 ¶
	| WWW-Authenticate | http | standard | Section 4.1 |		| 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 authentication.		and users of known security concerns specific to HTTP authentication.
	More general security considerations are addressed in HTTP messaging		More general security considerations are addressed in HTTP messaging
	[Part1] and semantics [Part2].		[RFC7230] and semantics [RFC7231].
	Everything about the topic of HTTP authentication is a security		Everything about the topic of HTTP authentication is a security
	consideration, so the list of considerations below is not exhaustive.		consideration, so the list of considerations below is not exhaustive.
	Furthermore, it is limited to security considerations regarding the		Furthermore, it is limited to security considerations regarding the
	authentication framework, in general, rather than discussing all of		authentication framework, in general, rather than discussing all of
	the potential considerations for specific authentication schemes		the potential considerations for specific authentication schemes
	(which ought to be documented in the specifications that define those		(which ought to be documented in the specifications that define those
	schemes). Various organizations maintain topical information and		schemes). Various organizations maintain topical information and
	links to current research on Web application security (e.g.,		links to current research on Web application security (e.g.,
	[OWASP]), including common pitfalls for implementing and using the		[OWASP]), including common pitfalls for implementing and using the
	skipping to change at page 13, line 23 ¶		skipping to change at page 13, line 33 ¶
	authentication scheme defines how the credentials are encoded prior		authentication scheme defines how the credentials are encoded prior
	to transmission. While this provides flexibility for the development		to transmission. While this provides flexibility for the development
	of future authentication schemes, it is inadequate for the protection		of future authentication schemes, it is inadequate for the protection
	of existing schemes that provide no confidentiality on their own, or		of existing schemes that provide no confidentiality on their own, or
	that do not sufficiently protect against replay attacks.		that do not sufficiently protect against replay attacks.
	Furthermore, if the server expects credentials that are specific to		Furthermore, if the server expects credentials that are specific to
	each individual user, the exchange of those credentials will have the		each individual user, the exchange of those credentials will have the
	effect of identifying that user even if the content within		effect of identifying that user even if the content within
	credentials remains confidential.		credentials remains confidential.
	HTTP depends on the security properties of the underlying transport		HTTP depends on the security properties of the underlying transport-
	or session-level connection to provide confidential transmission of		or session-level connection to provide confidential transmission of
	header fields. In other words, if a server limits access to		header fields. In other words, if a server limits access to
	authenticated users using this framework, the server needs to ensure		authenticated users using this framework, the server needs to ensure
	that the connection is properly secured in accordance with the nature		that the connection is properly secured in accordance with the nature
	of the authentication scheme used. For example, services that depend		of the authentication scheme used. For example, services that depend
	on individual user authentication often require a connection to be		on individual user authentication often require a connection to be
	secured with TLS ("Transport Layer Security", [RFC5246]) prior to		secured with TLS ("Transport Layer Security", [RFC5246]) prior to
	exchanging any credentials.		exchanging any credentials.
	6.2. Authentication Credentials and Idle Clients		6.2. Authentication Credentials and Idle Clients
	skipping to change at page 14, line 38 ¶		skipping to change at page 14, line 48 ¶
	7. Acknowledgments		7. Acknowledgments
	This specification takes over the definition of the HTTP		This specification takes over the definition of the HTTP
	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 [RFC7230] 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
	Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-26 (work in progress),
	February 2014.
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-26 (work in progress),
	February 2014.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-26 (work in progress),
	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.
			[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Message Syntax and Routing",
			draft-ietf-httpbis-p1-messaging-latest (work in progress),
			June 2014.
			[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Semantics and Content",
			draft-ietf-httpbis-p2-semantics-latest (work in progress),
			June 2014.
			[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
			Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
			draft-ietf-httpbis-p6-cache-latest (work in progress),
			June 2014.
	8.2. Informative References		8.2. Informative References
	[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
	[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web		[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
	Applications and Web Services", The Open Web Application		Applications and Web Services", The Open Web Application
	Security Project (OWASP) 2.0.1, July 2005,		Security Project (OWASP) 2.0.1, July 2005,
	<https://www.owasp.org/>.		<https://www.owasp.org/>.
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 39 ¶
	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 [RFC7230]:
	BWS = <BWS, defined in [Part1], Section 3.2.3>		BWS = <BWS, see [RFC7230], Section 3.2.3>
	OWS = <OWS, defined in [Part1], Section 3.2.3>		OWS = <OWS, see [RFC7230], Section 3.2.3>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>		quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
	token = <token, defined in [Part1], Section 3.2.6>		token = <token, see [RFC7230], Section 3.2.6>
	Appendix C. Collected ABNF		Appendix C. Collected ABNF
	In the collected ABNF below, list rules are expanded as per Section		In the collected ABNF below, list rules are expanded as per Section
	1.2 of [Part1].		1.2 of [RFC7230].
	Authorization = credentials		Authorization = credentials
	BWS = <BWS, defined in [Part1], Section 3.2.3>		BWS = <BWS, see [RFC7230], Section 3.2.3>
	OWS = <OWS, defined in [Part1], Section 3.2.3>		OWS = <OWS, see [RFC7230], 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.6>		quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
	token = <token, defined in [Part1], Section 3.2.6>		token = <token, see [RFC7230], Section 3.2.6>
	token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )		token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
	*"="		*"="
	Appendix D. Change Log (to be removed by RFC Editor before publication)
	Changes up to the IETF Last Call draft are summarized in <http://
	trac.tools.ietf.org/html/draft-ietf-httpbis-p7-auth-24#appendix-D>.
	D.1. Since draft-ietf-httpbis-p7-auth-24
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/510>: "SECDIR review
	of draft-ietf-httpbis-p7-auth-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/513>: "APPSDIR
	review of draft-ietf-httpbis-p7-auth-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/516>: "note about
	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 8		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 8		Authorization 9
	challenge 5		challenge 5
	credentials 6		credentials 6
	Proxy-Authenticate 9		Proxy-Authenticate 9
	Proxy-Authorization 9		Proxy-Authorization 10
	token68 5		token68 5
	WWW-Authenticate 8		WWW-Authenticate 8
	P		P
	Protection Space 6		Protection Space 6
	Proxy-Authenticate header field 9		Proxy-Authenticate header field 9
	Proxy-Authorization header field 9		Proxy-Authorization header field 10
	R		R
	Realm 6		Realm 6
	W		W
	WWW-Authenticate header field 8		WWW-Authenticate header field 8
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
End of changes. 54 change blocks.
	136 lines changed or deleted		97 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/