Changeset 2229 for draft-ietf-httpbis/latest

Timestamp:

28/04/13 15:38:27 (9 years ago)

Author:

julian.reschke@…

Message:

Apply many editorial suggestions (see #463)

Location:

draft-ietf-httpbis/latest

Files:

• p7-auth.html (modified) (16 diffs)
• p7-auth.xml (modified) (13 diffs)

draft-ietf-httpbis/latest/p7-auth.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires October 2013"; 
+       content: "Expires October 30, 2013"; 
   } 
   @bottom-right {
@@ -489 +489 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-04">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-04-28">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
@@ -517 +517 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">April 2013</td>
+               <td class="right">April 28, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: October 2013</td>
+               <td class="left">Expires: October 30, 2013</td>
                <td class="right"></td>
             </tr>
@@ -546 +546 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in October 2013.</p>
+      <p>This Internet-Draft will expire on October 30, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -639 +639 @@
       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="challenge.and.response" href="#challenge.and.response">Challenge and Response</a></h2>
       <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 an extensible, case-insensitive token to identify the authentication
+         and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication
          scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can either be
          a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.
@@ -674 +674 @@
       </p>
       <p id="rfc.section.2.1.p.12">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received
-         from the server (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
+         in a response (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 considers to be the most secure auth-scheme that it understands, obtaining credentials from the
          user as appropriate.
@@ -701 +701 @@
          on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
          database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific
-         to the authentication scheme. Note that there can be multiple challenges with the same auth-scheme but different realms.
+         to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but different realms.
       </p>
       <p id="rfc.section.2.2.p.3">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been
          authorized, the same credentials <em class="bcp14">MAY</em> be reused for all other requests within that protection space for a period of time determined by the authentication scheme,
-         parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot
+         parameters, and/or user preference. Unless specifically allowed by the authentication scheme, a single protection space cannot
          extend outside the scope of its server.
       </p>
@@ -742 +742 @@
          <li>
             <p>The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per
-               challenge/credentials. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions
+               challenge or credential. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions
                will be impossible.
             </p>
@@ -769 +769 @@
          <li>
             <p>The credentials carried in an <a href="#header.authorization" class="smpl">Authorization</a> header field are specific to the User Agent, and therefore have the same effect on HTTP caches as the "private" Cache-Control
-               response directive, within the scope of the request they appear in.
+               response directive (<a href="p6-cache.html#cache-response-directive.private" title="private">Section 7.2.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), within the scope of the request they appear in.
             </p>
             <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") or response directives (e.g., "private").
+               either Cache-Control request directives (e.g., "no-store", <a href="p6-cache.html#cache-request-directive.no-store" title="no-store">Section 7.2.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) or response directives (e.g., "private").
             </p>
          </li>
@@ -781 +781 @@
       <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 client <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
+         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>
@@ -792 +792 @@
       <div id="rfc.iref.a.1"></div>
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="header.authorization" href="#header.authorization">Authorization</a></h2>
-      <p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with a server — usually, but not necessarily,
+      <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 information of the user agent for the realm of the resource being requested.
@@ -800 +800 @@
          such as credentials that vary according to a challenge value or using synchronized clocks).
       </p>
-      <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.
+      <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.3"><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.
       </p>
       <div id="rfc.iref.p.2"></div>
@@ -817 +817 @@
       <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2>
       <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 user agent for the proxy and/or realm of
-         the resource being requested.
+         Its value consists of credentials containing the authentication information of the client for the proxy and/or realm of the
+         resource being requested.
       </p>
       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
@@ -957 +957 @@
       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="protection.spaces" href="#protection.spaces">Protection Spaces</a></h2>
       <p id="rfc.section.6.2.p.1">Authentication schemes that solely rely on the "realm" mechanism for establishing a protection space will expose credentials
-         to all resources on a server. Clients that have successfully made authenticated requests with a resource can use the same
-         authentication credentials for other resources on the same server. This makes it possible for a different resource to harvest
-         authentication credentials for other resources.
-      </p>
-      <p id="rfc.section.6.2.p.2">This is of particular concern when a 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 for each party.
+         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>
+      <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
+         party.
       </p>
       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
@@ -1135 +1137 @@
          <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>
+         <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>
       </ul>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
@@ -1189 +1193 @@
                      </ul>
                   </li>
-                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</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>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3.1</a>, <a href="#rfc.xref.Part6.2">2.3.1</a>, <a href="#rfc.xref.Part6.3">4.1</a>, <a href="#Part6"><b>8.1</b></a><ul>
+                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">4.1</a></li>
+                        <li><em>Section 7.2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.3.1</a></li>
+                        <li><em>Section 7.2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3.1</a></li>
                      </ul>
                   </li>

draft-ietf-httpbis/latest/p7-auth.xml

@@ -31 +31 @@
   <!ENTITY status.403                   "<xref target='Part2' x:rel='#status.403' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY caching-authenticated-responses "<xref target='Part6' x:rel='#caching.authenticated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY caching-rqd-no-store         "<xref target='Part6' x:rel='#cache-request-directive.no-store' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY caching-rsd-private          "<xref target='Part6' x:rel='#cache-response-directive.private' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
 ]>
 <?rfc toc="yes" ?>
@@ -160 +162 @@
    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 an extensible,
-   case-insensitive token to identify the authentication scheme, followed
+   client to provide authentication information. It uses a case-insensitive
+   token as a means to identify the authentication scheme, followed
    by additional information necessary for achieving authentication via that
    scheme. The latter can either be a comma-separated list of parameters or a
@@ -231 +233 @@
    Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value
    contain the client's credentials for the realm of the resource being
-   requested, based upon a challenge received from the server (possibly at
+   requested, based upon a challenge received in a response (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 considers to be the most
@@ -291 +293 @@
    authentication scheme and/or authorization database. The realm value
    is a string, generally assigned by the origin server, that can have
-   additional semantics specific to the authentication scheme. Note that
-   there can be multiple challenges with the same auth-scheme but
+   additional semantics specific to the authentication scheme. Note that a
+   response can have multiple challenges with the same auth-scheme but
    different realms.
 </t>
@@ -301 +303 @@
    protection space for a period of time determined by the
    authentication scheme, parameters, and/or user preference. Unless
-   otherwise defined by the authentication scheme, a single protection
+   specifically allowed by the authentication scheme, a single protection
    space cannot extend outside the scope of its server.
 </t>
@@ -362 +364 @@
     <t>
       The "token68" notation was introduced for compatibility with existing
-      authentication schemes and can only be used once per challenge/credentials.
+      authentication schemes and can only be used once per challenge or credential.
       New schemes thus ought to use the "auth-param" syntax instead, because
       otherwise future extensions will be impossible.
@@ -404 +406 @@
       The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
       the User Agent, and therefore have the same effect on HTTP caches as the
-      "private" Cache-Control response directive, within the scope of the
-      request they appear in.
+      "private" Cache-Control response directive (&caching-rsd-private;),
+      within the scope of the request they appear in.
     </t>
     <t>
@@ -411 +413 @@
       credentials in the <x:ref>Authorization</x:ref> 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") or response
-      directives (e.g., "private").
+      either Cache-Control request directives (e.g., "no-store",
+      &caching-rqd-no-store;) or response directives (e.g., "private").
     </t>
     </x:lt>
@@ -435 +437 @@
    If the request included authentication credentials, then the 401 response
    indicates that authorization has been refused for those credentials.
-   The client &MAY; repeat the request with a new or replaced
+   The user agent &MAY; repeat the request with a new or replaced
    <x:ref>Authorization</x:ref> header field (<xref target="header.authorization"/>).
    If the 401 response contains the same challenge as the prior response, and
@@ -470 +472 @@
 <t>
    The "Authorization" header field allows a user agent to authenticate
-   itself with a server &mdash; usually, but not necessarily, after receiving a <x:ref>401
+   itself with an origin server &mdash; usually, but not necessarily, after receiving a <x:ref>401
    (Unauthorized)</x:ref> response. Its value consists of credentials containing 
    information of the user agent for the realm of the resource being
@@ -525 +527 @@
    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 user
-   agent for the proxy and/or realm of the resource being requested.
+   authentication. Its value consists of credentials containing the
+   authentication information of the client for the proxy and/or realm of the
+   resource being requested.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
@@ -718 +720 @@
 <t>
   Authentication schemes that solely rely on the "realm" mechanism for
-  establishing a protection space will expose credentials to all resources on a
-  server. Clients that have successfully made authenticated requests with a
-  resource can use the same authentication credentials for other resources on
-  the same server. This makes it possible for a different resource to harvest
-  authentication credentials for other resources.
-</t>
-<t>
-  This is of particular concern when a server hosts resources for multiple
+  establishing a protection space will expose credentials 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.
+</t>
+<t>
+  This is of particular concern when an origin server hosts resources for multiple
   parties under the same canonical root URI (<xref target="protection.space"/>).
   Possible mitigation strategies include restricting direct access to
   authentication credentials (i.e., not making the content of the
   <x:ref>Authorization</x:ref> request header field available), and separating protection
-  spaces by using a different host name for each party.
+  spaces by using a different host name (or port number) for each party.
 </t>
 </section>
@@ -1170 +1172 @@
       "terminology: mechanism vs framework vs scheme"
     </t>
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/463"/>:
+      "Editorial suggestions"
+    </t>
   </list>
 </t>