Changeset 2229


Ignore:
Timestamp:
Apr 28, 2013, 8:38:27 AM (6 years ago)
Author:
julian.reschke@…
Message:

Apply many editorial suggestions (see #463)

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p7-auth.html

    r2218 r2229  
    449449  }
    450450  @bottom-center {
    451        content: "Expires October 2013";
     451       content: "Expires October 30, 2013";
    452452  }
    453453  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2013-04">
     491      <meta name="dct.issued" scheme="ISO8601" content="2013-04-28">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <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.">
     
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">April 2013</td>
     519               <td class="right">April 28, 2013</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: October 2013</td>
     522               <td class="left">Expires: October 30, 2013</td>
    523523               <td class="right"></td>
    524524            </tr>
     
    546546         in progress”.
    547547      </p>
    548       <p>This Internet-Draft will expire in October 2013.</p>
     548      <p>This Internet-Draft will expire on October 30, 2013.</p>
    549549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    550550      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    639639      <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>
    640640      <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
    641          and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication
     641         and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication
    642642         scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can either be
    643643         a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.
     
    674674      </p>
    675675      <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
    676          from the server (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
     676         in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
    677677         the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the
    678678         user as appropriate.
     
    701701         on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
    702702         database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific
    703          to the authentication scheme. Note that there can be multiple challenges with the same auth-scheme but different realms.
     703         to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but different realms.
    704704      </p>
    705705      <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
    706706         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,
    707          parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot
     707         parameters, and/or user preference. Unless specifically allowed by the authentication scheme, a single protection space cannot
    708708         extend outside the scope of its server.
    709709      </p>
     
    742742         <li>
    743743            <p>The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per
    744                challenge/credentials. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions
     744               challenge or credential. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions
    745745               will be impossible.
    746746            </p>
     
    769769         <li>
    770770            <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
    771                response directive, within the scope of the request they appear in.
     771               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.
    772772            </p>
    773773            <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
    774                either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private").
     774               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").
    775775            </p>
    776776         </li>
     
    781781      <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
    782782         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,
    783          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
     783         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
    784784         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.
    785785      </p>
     
    792792      <div id="rfc.iref.a.1"></div>
    793793      <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>
    794       <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,
     794      <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,
    795795         after receiving a <a href="#status.401" class="smpl">401
    796796            (Unauthorized)</a> response. Its value consists of credentials containing information of the user agent for the realm of the resource being requested.
     
    800800         such as credentials that vary according to a challenge value or using synchronized clocks).
    801801      </p>
    802       <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.
     802      <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.
    803803      </p>
    804804      <div id="rfc.iref.p.2"></div>
     
    817817      <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>
    818818      <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.
    819          Its value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of
    820          the resource being requested.
     819         Its value consists of credentials containing the authentication information of the client for the proxy and/or realm of the
     820         resource being requested.
    821821      </p>
    822822      <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>
     
    957957      <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>
    958958      <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
    959          to all resources on a server. Clients that have successfully made authenticated requests with a resource can use the same
    960          authentication credentials for other resources on the same server. This makes it possible for a different resource to harvest
    961          authentication credentials for other resources.
    962       </p>
    963       <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
    964          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.
     959         to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the
     960         same authentication credentials for other resources on the same origin server. This makes it possible for a different resource
     961         to harvest authentication credentials for other resources.
     962      </p>
     963      <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
     964         (<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
     965         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
     966         party.
    965967      </p>
    966968      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
     
    11351137         <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"
    11361138         </li>
     1139         <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"
     1140         </li>
    11371141      </ul>
    11381142      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
     
    11891193                     </ul>
    11901194                  </li>
    1191                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a>, <a href="#Part6"><b>8.1</b></a><ul>
    1192                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a></li>
     1195                  <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>
     1196                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">4.1</a></li>
     1197                        <li><em>Section 7.2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.3.1</a></li>
     1198                        <li><em>Section 7.2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3.1</a></li>
    11931199                     </ul>
    11941200                  </li>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r2218 r2229  
    3131  <!ENTITY status.403                   "<xref target='Part2' x:rel='#status.403' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3232  <!ENTITY caching-authenticated-responses "<xref target='Part6' x:rel='#caching.authenticated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     33  <!ENTITY caching-rqd-no-store         "<xref target='Part6' x:rel='#cache-request-directive.no-store' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     34  <!ENTITY caching-rsd-private          "<xref target='Part6' x:rel='#cache-response-directive.private' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3335]>
    3436<?rfc toc="yes" ?>
     
    160162   HTTP provides a simple challenge-response authentication framework
    161163   that can be used by a server to challenge a client request and by a
    162    client to provide authentication information. It uses an extensible,
    163    case-insensitive token to identify the authentication scheme, followed
     164   client to provide authentication information. It uses a case-insensitive
     165   token as a means to identify the authentication scheme, followed
    164166   by additional information necessary for achieving authentication via that
    165167   scheme. The latter can either be a comma-separated list of parameters or a
     
    231233   Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value
    232234   contain the client's credentials for the realm of the resource being
    233    requested, based upon a challenge received from the server (possibly at
     235   requested, based upon a challenge received in a response (possibly at
    234236   some point in the past). When creating their values, the user agent ought to
    235237   do so by selecting the challenge with what it considers to be the most
     
    291293   authentication scheme and/or authorization database. The realm value
    292294   is a string, generally assigned by the origin server, that can have
    293    additional semantics specific to the authentication scheme. Note that
    294    there can be multiple challenges with the same auth-scheme but
     295   additional semantics specific to the authentication scheme. Note that a
     296   response can have multiple challenges with the same auth-scheme but
    295297   different realms.
    296298</t>
     
    301303   protection space for a period of time determined by the
    302304   authentication scheme, parameters, and/or user preference. Unless
    303    otherwise defined by the authentication scheme, a single protection
     305   specifically allowed by the authentication scheme, a single protection
    304306   space cannot extend outside the scope of its server.
    305307</t>
     
    362364    <t>
    363365      The "token68" notation was introduced for compatibility with existing
    364       authentication schemes and can only be used once per challenge/credentials.
     366      authentication schemes and can only be used once per challenge or credential.
    365367      New schemes thus ought to use the "auth-param" syntax instead, because
    366368      otherwise future extensions will be impossible.
     
    404406      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
    405407      the User Agent, and therefore have the same effect on HTTP caches as the
    406       "private" Cache-Control response directive, within the scope of the
    407       request they appear in.
     408      "private" Cache-Control response directive (&caching-rsd-private;),
     409      within the scope of the request they appear in.
    408410    </t>
    409411    <t>
     
    411413      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
    412414      header field) will need to explicitly disallow caching, by mandating the use of
    413       either Cache-Control request directives (e.g., "no-store") or response
    414       directives (e.g., "private").
     415      either Cache-Control request directives (e.g., "no-store",
     416      &caching-rqd-no-store;) or response directives (e.g., "private").
    415417    </t>
    416418    </x:lt>
     
    435437   If the request included authentication credentials, then the 401 response
    436438   indicates that authorization has been refused for those credentials.
    437    The client &MAY; repeat the request with a new or replaced
     439   The user agent &MAY; repeat the request with a new or replaced
    438440   <x:ref>Authorization</x:ref> header field (<xref target="header.authorization"/>).
    439441   If the 401 response contains the same challenge as the prior response, and
     
    470472<t>
    471473   The "Authorization" header field allows a user agent to authenticate
    472    itself with a server &mdash; usually, but not necessarily, after receiving a <x:ref>401
     474   itself with an origin server &mdash; usually, but not necessarily, after receiving a <x:ref>401
    473475   (Unauthorized)</x:ref> response. Its value consists of credentials containing
    474476   information of the user agent for the realm of the resource being
     
    525527   The "Proxy-Authorization" header field allows the client to
    526528   identify itself (or its user) to a proxy that requires
    527    authentication. Its value consists of
    528    credentials containing the authentication information of the user
    529    agent for the proxy and/or realm of the resource being requested.
     529   authentication. Its value consists of credentials containing the
     530   authentication information of the client for the proxy and/or realm of the
     531   resource being requested.
    530532</t>
    531533<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
     
    718720<t>
    719721  Authentication schemes that solely rely on the "realm" mechanism for
    720   establishing a protection space will expose credentials to all resources on a
    721   server. Clients that have successfully made authenticated requests with a
    722   resource can use the same authentication credentials for other resources on
    723   the same server. This makes it possible for a different resource to harvest
    724   authentication credentials for other resources.
    725 </t>
    726 <t>
    727   This is of particular concern when a server hosts resources for multiple
     722  establishing a protection space will expose credentials to all resources on
     723  an origin server. Clients that have successfully made authenticated requests
     724  with a resource can use the same authentication credentials for other
     725  resources on the same origin server. This makes it possible for a different
     726  resource to harvest authentication credentials for other resources.
     727</t>
     728<t>
     729  This is of particular concern when an origin server hosts resources for multiple
    728730  parties under the same canonical root URI (<xref target="protection.space"/>).
    729731  Possible mitigation strategies include restricting direct access to
    730732  authentication credentials (i.e., not making the content of the
    731733  <x:ref>Authorization</x:ref> request header field available), and separating protection
    732   spaces by using a different host name for each party.
     734  spaces by using a different host name (or port number) for each party.
    733735</t>
    734736</section>
     
    11701172      "terminology: mechanism vs framework vs scheme"
    11711173    </t>
     1174    <t>
     1175      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/463"/>:
     1176      "Editorial suggestions"
     1177    </t>
    11721178  </list>
    11731179</t>
Note: See TracChangeset for help on using the changeset viewer.