Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/latest/p7-auth.html?rev=2398
Timestamp: 2020-08-07 04:24:18
Document Index: 523021296

Matched Legal Cases: ['art1', 'art1', 'art1', 'art2', 'art2', 'art2', 'art6', 'art6', 'art6', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art1', 'art1', 'art1', 'art2', 'art2', 'art2', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art2', 'art2', 'art2', 'art2', 'art2', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6', 'art6']

source: draft-ietf-httpbis/latest/p7-auth.html @ 2398
Last change on this file since 2398 was 2398, checked in by fielding@…, 7 years ago
rephrase misused SHOULDs; addresses #472
content: "Expires March 18, 2014";
<meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.599, 2013/08/29 10:34:28, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
<meta name="dct.issued" scheme="ISO8601" content="2013-09-14">
<td class="right">September 14, 2013</td>
<td class="left">Expires: March 18, 2014</td>
<p>The changes in this draft are summarized in <a href="#changes.since.23" title="Since draft-ietf-httpbis-p7-auth-23">Appendix&nbsp;D.5</a>.
<p>This Internet-Draft will expire on March 18, 2014.</p>
<li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a><ul>
<li><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry.procedure">Procedure</a></li>
<li><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#considerations.for.new.authentication.schemes">Considerations for New Authentication Schemes</a></li>
<li><a href="#rfc.section.D.3">D.3</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.21">Since draft-ietf-httpbis-p7-auth-21</a></li>
<li><a href="#rfc.section.D.4">D.4</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.22">Since draft-ietf-httpbis-p7-auth-22</a></li>
<li><a href="#rfc.section.D.5">D.5</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.23">Since draft-ietf-httpbis-p7-auth-23</a></li>
<p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication schemes that can be used by a server to challenge a client request and by a client to provide
authentication information. The "basic" and "digest" authentication schemes continue to be specified in <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.
<p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 7</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
<p id="rfc.section.2.1.p.1">HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request
and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication
<p><b>Note:</b> User agents will need to take special care in parsing the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field values because they can contain more than one challenge, or if more than one of each is provided, since the contents
<p><b>Note:</b> Many clients fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported
in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response that contains a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field with at least one (possibly new) challenge applicable to the requested resource.
a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with a (possibly new) challenge applicable to the proxy.
<p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
<p id="rfc.section.2.1.p.17">The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional
to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but different realms.
parameters, and/or user preference. Unless specifically allowed by the authentication scheme, a single protection space cannot
<p id="rfc.section.3.1.p.1">The <dfn>401 (Unauthorized)</dfn> status code indicates that the request has not been applied because it lacks valid authentication credentials for the target
resource. The origin server <em class="bcp14">MUST</em> send a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing at least one challenge applicable to the target resource. If the request included authentication credentials,
then the 401 response indicates that authorization has been refused for those credentials. The user agent <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication
at least once, then the user agent <em class="bcp14">SHOULD</em> present the enclosed representation to the user, since it usually contains relevant diagnostic information.
<p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.2</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
<p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with an origin server — usually, but not necessarily,
after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Its value consists of credentials containing the authentication information of the user agent for the realm of the
resource being requested.
</pre><p id="rfc.section.4.1.p.3">If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests
within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary
according to a challenge value or using synchronized clocks).
<p id="rfc.section.4.1.p.4">See <a href="p6-cache.html#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for details of and requirements pertaining to handling of the Authorization field by HTTP caches.
applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response.
</pre><p id="rfc.section.4.2.p.3">Unlike <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>, the Proxy-Authenticate header field applies only to the next outbound client on the response chain that chose to direct
its request to the responding proxy. If that recipient is also a proxy, it will generally consume the Proxy-Authenticate header
field (and generate an appropriate <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> in a 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.
<p id="rfc.section.4.3.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication.
Its value consists of credentials containing the authentication information of the client for the proxy and/or realm of the
</pre><p id="rfc.section.4.3.p.3">Unlike <a href="#header.authorization" class="smpl">Authorization</a>, the Proxy-Authorization header field applies only to the next inbound proxy that demanded authentication using the <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy
applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
<p>For instance:</p><pre class="text"> WWW-Authenticate: Newauth realm="apps", type=1,
</pre><p>This header field contains two challenges; one for the "Newauth" scheme with a realm value of "apps", and two additional parameters
<p><b>Note:</b> The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be
<h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="authentication.scheme.registry" href="#authentication.scheme.registry">Authentication Scheme Registry</a></h2>
<p id="rfc.section.5.1.p.1">The HTTP Authentication Scheme Registry defines the name space for the authentication schemes in challenges and credentials.
It will be created and maintained at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
<h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="authentication.scheme.registry.procedure" href="#authentication.scheme.registry.procedure">Procedure</a></h3>
<p id="rfc.section.5.1.1.p.1">Registrations <em class="bcp14">MUST</em> include the following fields:
<p id="rfc.section.5.1.1.p.2">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
<h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="considerations.for.new.authentication.schemes" href="#considerations.for.new.authentication.schemes">Considerations for New Authentication Schemes</a></h3>
<p id="rfc.section.5.1.2.p.1">There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can
<p id="rfc.section.5.1.2.p.2"></p>
to ensure that the connection cannot be used by any party other than the authenticated user (see <a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
challenge or credential. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions
<p><b>Note:</b> The fact that the value syntax for the "realm" parameter is restricted to quoted-string was a bad design choice not to be
response directive (<a href="p6-cache.html#cache-response-directive.private" title="private">Section 5.2.2.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), within the scope of the request they appear in.
<p>Therefore, new authentication schemes that choose not to carry credentials in the <a href="#header.authorization" class="smpl">Authorization</a> header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of
either Cache-Control request directives (e.g., "no-store", <a href="p6-cache.html#cache-request-directive.no-store" title="no-store">Section 5.2.1.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) or response directives (e.g., "private").
<td class="left"><a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section&nbsp;3.1</a>
<td class="left"><a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section&nbsp;3.2</a>
<p id="rfc.section.5.3.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt;.
<p id="rfc.section.5.3.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to
the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>):
<td class="left"><a href="#header.authorization" id="rfc.xref.header.authorization.3" title="Authorization">Section&nbsp;4.1</a>
<td class="left"><a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.2" title="Proxy-Authenticate">Section&nbsp;4.2</a>
<td class="left"><a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.2" title="Proxy-Authorization">Section&nbsp;4.3</a>
<td class="left"><a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.3" title="WWW-Authenticate">Section&nbsp;4.4</a>
<p id="rfc.section.6.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP/1.1
authentication. More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
<li>Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt
<li>Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the
server side of the application "knows" that there is no further reason for the client to retain the credentials.
use of password protection in screen savers, idle time-outs, and other 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
to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the
same authentication credentials for other resources on the same origin server. This makes it possible for a different resource
to harvest authentication credentials for other resources.
<p id="rfc.section.6.2.p.2">This is of particular concern when an origin server hosts resources for multiple parties under the same canonical root URI
(<a href="#protection.space" title="Protection Space (Realm)">Section&nbsp;2.2</a>). Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content
of the <a href="#header.authorization" class="smpl">Authorization</a> request header field available), and separating protection spaces by using a different host name (or port number) for each
<p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for the Acknowledgments related to this document revision.
<address><span class="vcardline"><b>Roy T. Fielding</b>
</span><span class="vcardline">Adobe Systems Incorporated</span><span class="vcardline">345 Park Ave</span><span class="vcardline">San Jose, CA&nbsp;95110</span><span class="vcardline">USA</span><span class="vcardline">Email: <a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a></span><span class="vcardline">URI: <a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></span></address>
<address><span class="vcardline"><b>Julian F. Reschke</b>
</span><span class="vcardline">greenbytes GmbH</span><span class="vcardline">Hafenweg 16</span><span class="vcardline">Muenster, NW&nbsp;48155</span><span class="vcardline">Germany</span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></span></address>
<p id="rfc.section.A.p.1">The framework for HTTP Authentication is now defined by this document, rather than RFC 2617.</p>
<p id="rfc.section.A.p.2">The "realm" parameter is no longer always required on challenges; consequently, the ABNF allows challenges without any auth
parameters. (<a href="#access.authentication.framework" title="Access Authentication Framework">Section&nbsp;2</a>)
<p id="rfc.section.A.p.3">The "token68" alternative to auth-param lists has been added for consistency with legacy authentication schemes such as "Basic".
<p id="rfc.section.A.p.4">This specification introduces the Authentication Scheme Registry, along with considerations for new authentication schemes.
(<a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section&nbsp;5.1</a>)
<p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
<div id="rfc.figure.u.9"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
<a href="#imported.abnf" class="smpl">OWS</a> = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
<a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
<a href="#imported.abnf" class="smpl">token</a> = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
<p id="rfc.section.C.p.1">In the collected ABNF below, list rules are expanded as per <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
<div id="rfc.figure.u.10"></div><pre class="inline"><a href="#header.authorization" class="smpl">Authorization</a> = credentials
<a href="#imported.abnf" class="smpl">BWS</a> = &lt;BWS, defined in [Part1], Section 3.2.3&gt;
<a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in [Part1], Section 3.2.6&gt;
<a href="#imported.abnf" class="smpl">token</a> = &lt;token, defined in [Part1], Section 3.2.6&gt;
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/348">http://tools.ietf.org/wg/httpbis/trac/ticket/348</a>&gt;: "Realms and scope"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/349">http://tools.ietf.org/wg/httpbis/trac/ticket/349</a>&gt;: "Strength"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/357">http://tools.ietf.org/wg/httpbis/trac/ticket/357</a>&gt;: "Authentication exchanges"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/376">http://tools.ietf.org/wg/httpbis/trac/ticket/376</a>&gt;: "rename b64token for clarity"
<h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a>&nbsp;<a id="changes.since.21" href="#changes.since.21">Since draft-ietf-httpbis-p7-auth-21</a></h2>
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/403">http://tools.ietf.org/wg/httpbis/trac/ticket/403</a>&gt;: "Authentication and caching - max-age"
<h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a>&nbsp;<a id="changes.since.22" href="#changes.since.22">Since draft-ietf-httpbis-p7-auth-22</a></h2>
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/439">http://tools.ietf.org/wg/httpbis/trac/ticket/439</a>&gt;: "terminology: mechanism vs framework vs scheme"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/463">http://tools.ietf.org/wg/httpbis/trac/ticket/463</a>&gt;: "Editorial suggestions"
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/464">http://tools.ietf.org/wg/httpbis/trac/ticket/464</a>&gt;: "placement of extension point considerations"
<h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a>&nbsp;<a id="changes.since.23" href="#changes.since.23">Since draft-ietf-httpbis-p7-auth-23</a></h2>
<li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/473">http://tools.ietf.org/wg/httpbis/trac/ticket/473</a>&gt;: "Forwarding Proxy-*"
<p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.W">W</a>
<li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.4">4.2</a>, <a href="#rfc.xref.Part1.5">4.4</a>, <a href="#rfc.xref.Part1.6">5.1.2</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">7</a>, <a href="#Part1"><b>8.1</b></a>, <a href="#rfc.xref.Part1.9">B</a>, <a href="#rfc.xref.Part1.10">B</a>, <a href="#rfc.xref.Part1.11">B</a>, <a href="#rfc.xref.Part1.12">B</a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">C</a><ul>
<li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">C</a></li>
<li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">5.1.2</a></li>
<li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">B</a>, <a href="#rfc.xref.Part1.11">B</a></li>
<li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">B</a>, <a href="#rfc.xref.Part1.13">B</a></li>
<li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.4">4.2</a>, <a href="#rfc.xref.Part1.5">4.4</a></li>
<li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">7</a></li>
<li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a>, <a href="#rfc.xref.Part2.2">6</a>, <a href="#Part2"><b>8.1</b></a><ul>
<li><em>Section 6.5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2.1</a></li>
<li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a>, <a href="#rfc.xref.Part6.2">5.1.2</a>, <a href="#rfc.xref.Part6.3">5.1.2</a>, <a href="#Part6"><b>8.1</b></a><ul>
<li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a></li>
<li><em>Section 5.2.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">5.1.2</a></li>
<li><em>Section 5.2.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">5.1.2</a></li>