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

Apply many editorial suggestions (see #463)

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.