Ignore:
Timestamp:
Jul 8, 2012, 5:30:37 AM (8 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions(P7)

File:
1 edited

Legend:

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

    r1735 r1736  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 7, 2013";
     451       content: "Expires January 9, 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="2012-07-06">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
    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. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: January 7, 2013</td>
     522               <td class="left">Expires: January 9, 2013</td>
    523523               <td class="right">greenbytes</td>
    524524            </tr>
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 6, 2012</td>
     527               <td class="right">July 8, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on January 7, 2013.</p>
     555      <p>This Internet-Draft will expire on January 9, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    699699         </p>
    700700      </div>
    701       <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an Authorization header field with the request.
     701      <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an <a href="#header.authorization" class="smpl">Authorization</a> header field with the request.
    702702      </p>
    703703      <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a Proxy-Authorization header field with the request.
    704704      </p>
    705       <p id="rfc.section.2.1.p.12">Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm
    706          of the resource being requested, based upon a challenge received from the server (possibly at some point in the past). When
    707          creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure
    708          auth-scheme that it understands, obtaining credentials from the user as appropriate.
     705      <p id="rfc.section.2.1.p.12">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested,
     706         based upon a challenge received from the server (possibly at some point in the past). When creating their values, the user
     707         agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands,
     708         obtaining credentials from the user as appropriate.
    709709      </p>
    710710      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.c.2"></span><span id="rfc.iref.g.5"></span>  <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
     
    721721         authentication information. However, such additional mechanisms are not defined by this specification.
    722722      </p>
    723       <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate and Authorization headers unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
     723      <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
    724724      </p>
    725725      <div id="rfc.iref.p.1"></div>
     
    799799         </li>
    800800         <li>
    801             <p>The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect
    802                on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in.
     801            <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
     802               response directive, within the scope of the request they appear in.
    803803            </p>
    804             <p>Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly
    805                defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives
    806                (e.g., "no-store") or response directives (e.g., "private").
     804            <p>Therefore, new authentication schemes which 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
     805               either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private").
    807806            </p>
    808807         </li>
     
    812811      <div id="rfc.iref.s.1"></div>
    813812      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="status.401" href="#status.401">401 Unauthorized</a></h2>
    814       <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
     813      <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <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 request already included Authorization credentials, then the 401 response indicates that authorization has been
    815814         refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
    816815         already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic
     
    869868      </p>
    870869      <div id="rfc.figure.u.7"></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>
    871 </pre><p id="rfc.section.4.3.p.3">Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication
    872          using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed
    873          by the first outbound proxy that was expecting to receive credentials. A proxy <em class="bcp14">MAY</em> relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively
     870</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 outbound proxy that demanded authentication using the Proxy-Authenticate
     871         field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy
     872         that was expecting to receive credentials. A proxy <em class="bcp14">MAY</em> relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively
    874873         authenticate a given request.
    875874      </p>
     
    10131012      </p>
    10141013      <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.spaces" title="Protection Spaces">Section&nbsp;6.2</a>). Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content
    1015          of the Authorization request header field available), and separating protection spaces by using a different host name for
    1016          each party.
     1014         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.
    10171015      </p>
    10181016      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
Note: See TracChangeset for help on using the changeset viewer.