draft-ietf-httpbis-p7-auth-23.txt		draft-ietf-httpbis-p7-auth-24.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 July 15, 2013		Intended status: Standards Track September 25, 2013
	Expires: January 16, 2014		Expires: March 29, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Authentication		Hypertext Transfer Protocol (HTTP/1.1): Authentication
	draft-ietf-httpbis-p7-auth-23		draft-ietf-httpbis-p7-auth-24
	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.4.		The changes in this draft are summarized in Appendix D.5.
	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 16, 2014.		This Internet-Draft will expire on March 29, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 3, line 43		skipping to change at page 3, line 43
	8.2. Informative References . . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15		Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 16		publication) . . . . . . . . . . . . . . . . . . . . 16
	D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16		D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16
	D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17		D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17
	D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17		D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17
	D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17		D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		D.5. Since draft-ietf-httpbis-p7-auth-23 . . . . . . . . . . . 17
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	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 32		skipping to change at page 4, line 32
	"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 the list rule extension defined in Section
	1.2 of [Part1]. Appendix B describes rules imported from other		7 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
	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-
	skipping to change at page 6, line 36		skipping to change at page 6, line 36
	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]).
	The HTTP protocol does not restrict applications to this simple		The HTTP protocol does not restrict applications to this simple
	challenge-response framework for access authentication. Additional		challenge-response framework 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		A proxy 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.
	2.2. Protection Space (Realm)		2.2. Protection Space (Realm)
	The authentication parameter realm is reserved for use by		The authentication parameter realm is reserved for use by
	authentication schemes that wish to indicate the scope of protection.		authentication schemes that wish to indicate the scope of protection.
	A protection space is defined by the canonical root URI (the scheme		A protection space is defined by the canonical root URI (the scheme
	and authority components of the effective request URI; see Section		and authority components of the effective request URI; see Section
	5.5 of [Part1]) of the server being accessed, in combination with the		5.5 of [Part1]) of the server being accessed, in combination with the
	realm value if present. These realms allow the protected resources		realm value if present. These realms allow the protected resources
	on a server to be partitioned into a set of protection spaces, each		on a server to be partitioned into a set of protection spaces, each
	with its own authentication scheme and/or authorization database.		with its own authentication scheme and/or authorization database.
	The realm value is a string, generally assigned by the origin server,		The realm value is a string, generally assigned by the origin server,
	that 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
	same auth-scheme but different realms.		same auth-scheme but different realms.
	The protection space determines the domain over which credentials can		The protection space determines the domain over which credentials can
	be automatically applied. If a prior request has been authorized,		be automatically applied. If a prior request has been authorized,
	the same credentials MAY be reused for all other requests within that		the user agent MAY reuse the same credentials for all other requests
	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 preference. Unless		authentication scheme, parameters, and/or user preference. Unless
	specifically allowed by the authentication scheme, a single		specifically allowed by the authentication scheme, a single
	protection space cannot extend outside the scope of its server.		protection space cannot extend outside the scope of its server.
	For historical reasons, senders MUST only generate the quoted-string		For historical reasons, a sender MUST only generate the quoted-string
	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
	skipping to change at page 8, line 10		skipping to change at page 8, line 10
	4. Header Field Definitions		4. Header Field Definitions
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to authentication.		fields related to authentication.
	4.1. Authorization		4.1. Authorization
	The "Authorization" header field allows a user agent to authenticate		The "Authorization" header field allows a user agent to authenticate
	itself with 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 information of the user agent for the realm of		credentials containing the authentication information of the user
	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 SHOULD be valid for all other requests within this realm		credentials are presumed to be valid for all other requests within
	(assuming that the authentication scheme itself does not require		this realm (assuming that the authentication scheme itself does not
	otherwise, such as credentials that vary according to a challenge		require otherwise, such as credentials that vary according to a
	value or using synchronized clocks).		challenge value or using synchronized clocks).
	See Section 3.2 of [Part6] for details of and requirements pertaining		See Section 3.2 of [Part6] for details of and requirements pertaining
	to handling of the Authorization field by HTTP caches.		to handling of the Authorization field by HTTP caches.
	4.2. Proxy-Authenticate		4.2. Proxy-Authenticate
	The "Proxy-Authenticate" header field consists of at least one		The "Proxy-Authenticate" header field consists of at least one
	challenge that indicates the authentication scheme(s) and parameters		challenge that indicates the authentication scheme(s) and parameters
	applicable to the proxy for this effective request URI (Section 5.5		applicable to the proxy for this effective request URI (Section 5.5
	of [Part1]). It MUST be included as part of a 407 (Proxy		of [Part1]). It MUST be included as part of a 407 (Proxy
	Authentication Required) response.		Authentication Required) response.
	Proxy-Authenticate = 1#challenge		Proxy-Authenticate = 1#challenge
	Unlike WWW-Authenticate, the Proxy-Authenticate header field applies		Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
	only to the current connection, and intermediaries SHOULD NOT forward		only to the next outbound client on the response chain that chose to
	it to downstream clients. However, an intermediate proxy might need		direct its request to the responding proxy. If that recipient is
	to obtain its own credentials by requesting them from the downstream		also a proxy, it will generally consume the Proxy-Authenticate header
	client, which in some circumstances will appear as if the proxy is		field (and generate an appropriate Proxy-Authorization in a
	forwarding the Proxy-Authenticate header field.		subsequent request) rather than forward the header field to its own
			outbound clients. However, if a recipient proxy needs to obtain its
			own credentials by requesting them from a further outbound client, it
			will generate its own 407 response, which might have the appearance
			of forwarding the Proxy-Authenticate header field if both proxies use
			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.4 for details.
	4.3. Proxy-Authorization		4.3. Proxy-Authorization
	The "Proxy-Authorization" header field allows the client to identify		The "Proxy-Authorization" header field allows the client to identify
	itself (or its user) to a proxy 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 outbound proxy that demanded authentication using		only to the next inbound proxy that demanded authentication using the
	the Proxy-Authenticate field. When multiple proxies are used in a		Proxy-Authenticate field. When multiple proxies are used in a chain,
	chain, the Proxy-Authorization header field is consumed by the first		the Proxy-Authorization header field is consumed by the first inbound
	outbound proxy that was expecting to receive credentials. A proxy		proxy that was expecting to receive credentials. A proxy MAY relay
	MAY relay the credentials from the client request to the next proxy		the credentials from the client request to the next proxy if that is
	if that is the mechanism by which the proxies cooperatively		the mechanism by which the proxies cooperatively authenticate a given
	authenticate a given request.		request.
	4.4. WWW-Authenticate		4.4. WWW-Authenticate
	The "WWW-Authenticate" header field consists of at least one		The "WWW-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 effective request URI (Section 5.5 of [Part1]).		applicable to the effective request URI (Section 5.5 of [Part1]).
	It MUST be included in 401 (Unauthorized) response messages and MAY		It MUST be included in 401 (Unauthorized) response messages and MAY
	be included in other response messages to indicate that supplying		be included in other response messages to indicate that supplying
	credentials (or different credentials) might affect the response.		credentials (or different credentials) might affect the response.
	skipping to change at page 11, line 30		skipping to change at page 11, line 33
	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 7.2.2.6 of [Part6]), within the scope of the request they		(Section 5.2.2.6 of [Part6]), within the scope of the request they
	appear in.		appear in.
	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 7.2.1.5 of [Part6]) or response		(e.g., "no-store", Section 5.2.1.5 of [Part6]) 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 HTTP Status Code Registry located at
	<http://www.iana.org/assignments/http-status-codes> shall be updated		<http://www.iana.org/assignments/http-status-codes> shall be updated
	with the registrations below:		with the registrations below:
	+-------+-------------------------------+-------------+		+-------+-------------------------------+-------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	skipping to change at page 12, line 44		skipping to change at page 12, line 44
	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/1.1
	authentication. More general security considerations are addressed		authentication. More general security considerations are addressed
	in HTTP messaging [Part1] and semantics [Part2].		in HTTP messaging [Part1] and semantics [Part2].
	6.1. Authentication Credentials and Idle Clients		6.1. Authentication Credentials and Idle Clients
	Existing HTTP clients and user agents typically retain authentication		Existing HTTP clients and user agents typically retain authentication
	information indefinitely. HTTP/1.1 does not provide a method for a		information indefinitely. HTTP does not provide a mechanism for the
	server to direct clients to discard these cached credentials. This		origin server to direct clients to discard these cached credentials,
	is a significant defect that requires further extensions to HTTP.		since the protocol has no awareness of how credentials are obtained
			or managed by the user agent. The mechanisms for expiring or
			revoking credentials can be specified as part of an authentication
			scheme definition.
	Circumstances under which credential caching can interfere with the		Circumstances under which credential caching can interfere with the
	application's security model include but are not limited to:		application's security model include but are not limited to:
	o Clients that have been idle for an extended period, following		o Clients that have been idle for an extended period, following
	which the server might wish to cause the client to re-prompt the		which the server might wish to cause the client to re-prompt the
	user for credentials.		user for credentials.
	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.
	This is currently under separate study. There are a number of work-		User agents that cache credentials are encouraged to provide a
	arounds to parts of this problem, and we encourage the use of		readily accessible mechanism for discarding cached credentials under
	password protection in screen savers, idle time-outs, and other		user control.
	methods that mitigate the security problems inherent in this problem.
	In particular, user agents that cache credentials are encouraged to
	provide a readily accessible mechanism for discarding cached
	credentials under user control.
	6.2. Protection Spaces		6.2. Protection Spaces
	Authentication schemes that solely rely on the "realm" mechanism for		Authentication schemes that solely rely on the "realm" mechanism for
	establishing a protection space will expose credentials to all		establishing a protection space will expose credentials to all
	resources on 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.
	skipping to change at page 13, line 45		skipping to change at page 13, line 45
	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 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-23 (work in progress),		draft-ietf-httpbis-p1-messaging-24 (work in progress),
	July 2013.		September 2013.
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-23 (work in progress),		draft-ietf-httpbis-p2-semantics-24 (work in progress),
	July 2013.		September 2013.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-23 (work in progress),		draft-ietf-httpbis-p6-cache-24 (work in progress),
	July 2013.		September 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	8.2. Informative References		8.2. Informative References
	[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	skipping to change at page 17, line 43		skipping to change at page 17, line 43
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology:
	mechanism vs framework vs scheme"		mechanism vs framework vs scheme"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial		o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial
	suggestions"		suggestions"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of		o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of
	extension point considerations"		extension point considerations"
			D.5. Since draft-ietf-httpbis-p7-auth-23
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/473>: "Forwarding
			Proxy-*"
	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 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 6		credentials 6
	Proxy-Authenticate 8		Proxy-Authenticate 8
	Proxy-Authorization 8		Proxy-Authorization 9
	token68 5		token68 5
	WWW-Authenticate 9		WWW-Authenticate 9
	P		P
	Protection Space 6		Protection Space 6
	Proxy-Authenticate header field 8		Proxy-Authenticate header field 8
	Proxy-Authorization header field 8		Proxy-Authorization header field 8
	R		R
	Realm 6		Realm 6
End of changes. 24 change blocks.
	50 lines changed or deleted		63 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/