draft-ietf-httpbis-p7-auth-20.txt		draft-ietf-httpbis-p7-auth-21.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) Y. Lafon, Ed.		Obsoletes: 2616 (if approved) J. Reschke, Ed.
	Updates: 2617 (if approved) W3C		Updates: 2617 (if approved) greenbytes
	Intended status: Standards Track J. Reschke, Ed.		Intended status: Standards Track October 4, 2012
	Expires: January 17, 2013 greenbytes		Expires: April 7, 2013
	July 16, 2012
	HTTP/1.1, part 7: Authentication		Hypertext Transfer Protocol (HTTP/1.1): Authentication
	draft-ietf-httpbis-p7-auth-20		draft-ietf-httpbis-p7-auth-21
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. This document defines the HTTP Authentication framework.		systems. This document defines the HTTP Authentication framework.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.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 January 17, 2013.		This Internet-Draft will expire on April 7, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 9		skipping to change at page 3, line 9
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	2. Access Authentication Framework . . . . . . . . . . . . . . . 5		2. Access Authentication Framework . . . . . . . . . . . . . . . 4
	2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 5		2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4
	2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 7		2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6
	2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 8		2.3. Authentication Scheme Registry . . . . . . . . . . . . . . 7
	2.3.1. Considerations for New Authentication Schemes . . . . 8		2.3.1. Considerations for New Authentication Schemes . . . . 7
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 9
	3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9		3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 9
	3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 10		3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 9
	4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10		4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
	4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 10		4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 11		4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 10
	4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 11		4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 10
	4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 12		4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12		5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 12
	5.2. Status Code Registration . . . . . . . . . . . . . . . . . 13		5.2. Status Code Registration . . . . . . . . . . . . . . . . . 12
	5.3. Header Field Registration . . . . . . . . . . . . . . . . 13		5.3. Header Field Registration . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6.1. Authentication Credentials and Idle Clients . . . . . . . 13		6.1. Authentication Credentials and Idle Clients . . . . . . . 13
	6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 14		6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16		Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 16		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 17		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) . . . . . . . . . . . . . . . . . . . . 17		publication) . . . . . . . . . . . . . . . . . . . . 16
	D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 17		D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 access control and authentication. It		This document defines HTTP/1.1 access control and authentication. It
	includes the relevant parts of RFC 2616 with only minor changes		includes the relevant parts of RFC 2616 with only minor changes
	([RFC2616]), plus the general framework for HTTP authentication, as		([RFC2616]), plus the general framework for HTTP authentication, as
	previously defined in "HTTP Authentication: Basic and Digest Access		previously defined in "HTTP Authentication: Basic and Digest Access
	Authentication" ([RFC2617]).		Authentication" ([RFC2617]).
	HTTP provides several OPTIONAL challenge-response authentication		HTTP provides several OPTIONAL challenge-response authentication
	skipping to change at page 4, line 25		skipping to change at page 4, line 25
	request and by a client to provide authentication information. The		request and by a client to provide authentication information. The
	"basic" and "digest" authentication schemes continue to be specified		"basic" and "digest" authentication schemes continue to be specified
	in RFC 2617.		in 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].
	This specification targets conformance criteria according to the role		Conformance criteria and considerations regarding error handling are
	of a participant in HTTP communication. Hence, HTTP requirements are		defined in Section 2.5 of [Part1].
	placed on senders, recipients, clients, servers, user agents,
	intermediaries, origin servers, proxies, gateways, or caches,
	depending on what behavior is being constrained by the requirement.
	See Section 2 of [Part1] for definitions of these terms.
	The verb "generate" is used instead of "send" where a requirement
	differentiates between creating a protocol element and merely
	forwarding a received element downstream.
	An implementation is considered conformant if it complies with all of
	the requirements associated with the roles it partakes in HTTP. Note
	that SHOULD-level requirements are relevant here, unless one of the
	documented exceptions is applicable.
	This document also uses ABNF to define valid protocol elements
	(Section 1.2). In addition to the prose requirements placed upon
	them, senders MUST NOT generate protocol elements that do not match
	the grammar defined by the ABNF rules for those protocol elements
	that are applicable to the sender's role. If a received protocol
	element is processed, the recipient MUST be able to parse any value
	that would match the ABNF rules for that protocol element, excluding
	only those rules not applicable to the recipient's role.
	Unless noted otherwise, a recipient MAY attempt to recover a usable
	protocol element from an invalid construct. HTTP does not define
	specific error handling mechanisms except when they have a direct
	impact on security, since different applications of the protocol
	require different error handling strategies. For example, a Web
	browser might wish to transparently recover from a response where the
	Location header field doesn't parse according to the ABNF, whereas a
	systems control client might consider any form of error recovery to
	be dangerous.
	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 the list rule extension defined in Section
	1.2 of [Part1]. Appendix B describes rules imported from other		1.2 of [Part1]. Appendix B describes rules imported from other
	documents. Appendix C shows the collected ABNF with the list rule		documents. Appendix C shows the collected ABNF with the list rule
	expanded.		expanded.
	2. Access Authentication Framework		2. Access Authentication Framework
	skipping to change at page 5, line 40		skipping to change at page 5, line 9
	capable of holding base64-encoded information.		capable of holding base64-encoded information.
	Parameters are name-value pairs where the name is matched case-		Parameters are name-value pairs where the name is matched case-
	insensitively, and each parameter name MUST only occur once per		insensitively, and each parameter name MUST only occur once per
	challenge.		challenge.
	auth-scheme = token		auth-scheme = token
	auth-param = token BWS "=" BWS ( token / quoted-string )		auth-param = token BWS "=" BWS ( token / quoted-string )
	b64token = 1*( ALPHA / DIGIT /		token68 = 1*( ALPHA / DIGIT /
	"-" / "." / "_" / "~" / "+" / "/" ) *"="		"-" / "." / "_" / "~" / "+" / "/" ) *"="
	The "b64token" 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		The 401 (Unauthorized) response message is used by an origin server
	to challenge the authorization of a user agent. This response MUST		to challenge the authorization of a user agent. This response MUST
	include a WWW-Authenticate header field containing at least one		include a WWW-Authenticate header field containing at least one
	challenge applicable to the requested resource.		challenge applicable to the requested resource.
	The 407 (Proxy Authentication Required) response message is used by a		The 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 and MUST include a
	Proxy-Authenticate header field containing at least one challenge		Proxy-Authenticate header field containing at least one challenge
	applicable to the proxy for the requested resource.		applicable to the proxy for the requested resource.
	challenge = auth-scheme [ 1*SP ( b64token / #auth-param ) ]		challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
	Note: User agents will need to take special care in parsing the		Note: User agents will need to take special care in parsing the
	WWW-Authenticate and Proxy-Authenticate header field values		WWW-Authenticate and Proxy-Authenticate header field values
	because they can contain more than one challenge, or if more than		because they can contain more than one challenge, or if more than
	one of each is provided, since the contents of a challenge can		one of each is provided, since the contents of a challenge can
	itself contain a comma-separated list of authentication		itself contain a comma-separated list of authentication
	parameters.		parameters.
	Note: Many clients fail to parse challenges containing unknown		Note: Many clients fail to parse challenges containing unknown
	schemes. A workaround for this problem is to list well-supported		schemes. A workaround for this problem is to list well-supported
	skipping to change at page 6, line 42		skipping to change at page 6, line 10
	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 from the server		being requested, based upon a challenge received from the server
	(possibly at some point in the past). When creating their values,		(possibly at some point in the past). When creating their values,
	the user agent ought to do so by selecting the challenge with what it		the user agent ought to do so by selecting the challenge with what it
	considers to be the most secure auth-scheme that it understands,		considers to be the most secure auth-scheme that it understands,
	obtaining credentials from the user as appropriate.		obtaining credentials from the user as appropriate.
	credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]		credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
	Upon a request for a protected resource that omits credentials,		Upon a request for a protected resource that omits credentials,
	contains invalid credentials (e.g., a bad password) or partial		contains invalid credentials (e.g., a bad password) or partial
	credentials (e.g., when the authentication scheme requires more than		credentials (e.g., when the authentication scheme requires more than
	one round trip), an origin server SHOULD return a 401 (Unauthorized)		one round trip), an origin server SHOULD return a 401 (Unauthorized)
	response. Such responses MUST include a WWW-Authenticate header		response. Such responses MUST include a WWW-Authenticate header
	field containing at least one (possibly new) challenge applicable to		field containing at least one (possibly new) challenge applicable to
	the requested resource.		the requested resource.
	Likewise, upon a request that requires authentication by proxies that		Likewise, upon a request that requires authentication by proxies that
	omit credentials or contain invalid or partial credentials, a proxy		omit credentials or contain invalid or partial credentials, a proxy
	SHOULD return a 407 (Proxy Authentication Required) response. Such		SHOULD return a 407 (Proxy Authentication Required) response. Such
	responses MUST include a Proxy-Authenticate header field containing a		responses MUST include a Proxy-Authenticate header field containing a
	(possibly new) challenge applicable to the proxy.		(possibly new) challenge applicable to the proxy.
	A server receiving credentials that are valid, but not adequate to		A server receiving credentials that are valid, but not adequate to
	gain access, ought to respond with the 403 (Forbidden) status code		gain access, ought to respond with the 403 (Forbidden) status code
	(Section 4.6.3 of [Part2]).		(Section 7.5.3 of [Part2]).
	The HTTP protocol does not restrict applications to this simple		The HTTP protocol does not restrict applications to this simple
	challenge-response mechanism for access authentication. Additional		challenge-response mechanism for access authentication. Additional
	mechanisms MAY be used, such as encryption at the transport level or		mechanisms MAY be used, such as encryption at the transport level or
	via message encapsulation, and with additional header fields		via message encapsulation, and with additional header fields
	specifying authentication information. However, such additional		specifying authentication information. However, such additional
	mechanisms are not defined by this specification.		mechanisms are not defined by this specification.
	Proxies MUST forward the WWW-Authenticate and Authorization header		Proxies MUST forward the WWW-Authenticate and Authorization header
	fields unmodified and follow the rules found in Section 4.1.		fields unmodified and follow the rules found in Section 4.1.
	skipping to change at page 8, line 36		skipping to change at page 8, line 4
	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.4 of [Part1]).		authenticated user (see Section 2.3 of [Part1]).
	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 defined in Section 2.2. New schemes MUST NOT
	use it in a way incompatible with that definition.		use it in a way incompatible with that definition.
	o The "b64token" 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/credentials. New schemes thus ought to use the "auth-		challenge/credentials. New schemes thus 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
	skipping to change at page 14, line 44		skipping to change at page 14, line 4
	Possible mitigation strategies include restricting direct access to		Possible mitigation strategies include restricting direct access to
	authentication credentials (i.e., not making the content of the		authentication credentials (i.e., not making the content of the
	Authorization request header field available), and separating		Authorization request header field available), and separating
	protection spaces by using a different host name for each party.		protection spaces by using a different host name for each party.
	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 9 of [Part1] for the Acknowledgments related to this		See Section 9 of [Part1] for the Acknowledgments related to this
	document revision.		document revision.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	"HTTP/1.1, part 1: Message Routing and Syntax"",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-20 (work in progress),		draft-ietf-httpbis-p1-messaging-21 (work in progress),
	July 2012.		October 2012.
	[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	"HTTP/1.1, part 2: Semantics and Payloads",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-20 (work in progress),		draft-ietf-httpbis-p2-semantics-21 (work in progress),
	July 2012.		October 2012.
	[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-20 (work in progress),		draft-ietf-httpbis-p6-cache-21 (work in progress),
	July 2012.		October 2012.
	[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
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	skipping to change at page 16, line 11		skipping to change at page 15, line 20
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	Appendix A. Changes from RFCs 2616 and 2617		Appendix A. Changes from RFCs 2616 and 2617
	The "realm" parameter isn't required anymore in general;		The "realm" parameter isn't required anymore in general;
	consequently, the ABNF allows challenges without any auth parameters.		consequently, the ABNF allows challenges without any auth parameters.
	(Section 2)		(Section 2)
	The "b64token" alternative to auth-param lists has been added for		The "token68" alternative to auth-param lists has been added for
	consistency with legacy authentication schemes such as "Basic".		consistency with legacy authentication schemes such as "Basic".
	(Section 2)		(Section 2)
	Introduce Authentication Scheme Registry. (Section 2.3)		Introduce Authentication Scheme Registry. (Section 2.3)
	Change ABNF productions for header fields to only define the field
	value. (Section 4)
	Appendix B. Imported ABNF		Appendix B. Imported ABNF
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),		Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
	CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double		CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
	quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any		quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
	8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII		8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
	character).		character).
	The rules below are defined in [Part1]:		The rules below are defined in [Part1]:
	skipping to change at page 17, line 23		skipping to change at page 16, line 23
	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
	b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )		challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
	*"="
	challenge = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *(
	OWS "," [ OWS auth-param ] ) ] ) ]		OWS "," [ OWS auth-param ] ) ] ) ]
	credentials = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param )		credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
	*( OWS "," [ OWS auth-param ] ) ] ) ]		*( OWS "," [ OWS auth-param ] ) ] ) ]
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
	token = <token, defined in [Part1], Section 3.2.4>		token = <token, defined in [Part1], Section 3.2.4>
			token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
			*"="
	Appendix D. Change Log (to be removed by RFC Editor before publication)		Appendix D. Change Log (to be removed by RFC Editor before publication)
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the first Working Group Last Call draft are summarized
	in <http://trac.tools.ietf.org/html/		in <http://trac.tools.ietf.org/html/
	draft-ietf-httpbis-p7-auth-19#appendix-C>.		draft-ietf-httpbis-p7-auth-19#appendix-C>.
	D.1. Since draft-ietf-httpbis-p7-auth-19		D.1. Since draft-ietf-httpbis-p7-auth-19
	Closed issues:		Closed issues:
	skipping to change at page 18, line 11		skipping to change at page 17, line 11
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/357>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/357>:
	"Authentication exchanges"		"Authentication exchanges"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF		o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
	requirements for recipients"		requirements for recipients"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note		o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
	introduction of new IANA registries as normative changes"		introduction of new IANA registries as normative changes"
			D.2. Since draft-ietf-httpbis-p7-auth-20
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename
			b64token for clarity"
			Other changes:
			o Conformance criteria and considerations regarding error handling
			are now defined in Part 1.
	Index		Index
	4		4
	401 Unauthorized (status code) 9		401 Unauthorized (status code) 9
	407 Proxy Authentication Required (status code) 10		407 Proxy Authentication Required (status code) 9
	A		A
	auth-param 5		Authorization header field 9
	auth-scheme 5
	Authorization header field 10
	B
	b64token 5
	C		C
	Canonical Root URI 7		Canonical Root URI 6
	challenge 6
	credentials 6
	G		G
	Grammar		Grammar
	auth-param 5		auth-param 5
	auth-scheme 5		auth-scheme 5
	Authorization 10		Authorization 9
	b64token 5		challenge 5
	challenge 6
	credentials 6		credentials 6
	Proxy-Authenticate 11		Proxy-Authenticate 10
	Proxy-Authorization 11
	WWW-Authenticate 12
	H
	Header Fields
	Authorization 10
	Proxy-Authenticate 11
	Proxy-Authorization 11		Proxy-Authorization 11
	WWW-Authenticate 12		token68 5
			WWW-Authenticate 11
	P		P
	Protection Space 7		Protection Space 6
	Proxy-Authenticate header field 11		Proxy-Authenticate header field 10
	Proxy-Authorization header field 11		Proxy-Authorization header field 10
	R		R
	Realm 7		Realm 6
	S
	Status Codes
	401 Unauthorized 9
	407 Proxy Authentication Required 10
	W		W
	WWW-Authenticate header field 12		WWW-Authenticate header field 11
	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
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Yves Lafon (editor)
	World Wide Web Consortium
	W3C / ERCIM
	2004, rte des Lucioles
	Sophia-Antipolis, AM 06902
	France
	EMail: ylafon@w3.org
	URI: http://www.raubacapeu.net/people/yves/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
	EMail: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
End of changes. 39 change blocks.
	140 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/