Changeset 1736 for draft-ietf-httpbis/latest/p7-auth.html
- Timestamp:
- 08/07/12 12:30:37 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.html
r1735 r1736 449 449 } 450 450 @bottom-center { 451 content: "Expires January 7, 2013";451 content: "Expires January 9, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 6">491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-08"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: January 7, 2013</td>522 <td class="left">Expires: January 9, 2013</td> 523 523 <td class="right">greenbytes</td> 524 524 </tr> 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 6, 2012</td>527 <td class="right">July 8, 2012</td> 528 528 </tr> 529 529 </tbody> … … 553 553 in progress”. 554 554 </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> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 699 699 </p> 700 700 </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 Authorizationheader 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. 702 702 </p> 703 703 <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. 704 704 </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 realm706 of the resource being requested, based upon a challenge received from the server (possibly at some point in the past). When707 creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure708 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. 709 709 </p> 710 710 <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> ) ] … … 721 721 authentication information. However, such additional mechanisms are not defined by this specification. 722 722 </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 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 4.1</a>. 724 724 </p> 725 725 <div id="rfc.iref.p.1"></div> … … 799 799 </li> 800 800 <li> 801 <p>The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect802 on HTTP caches as the "private" Cache-Controlresponse 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. 803 803 </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"). 807 806 </p> 808 807 </li> … … 812 811 <div id="rfc.iref.s.1"></div> 813 812 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <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 4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorizationheader field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section 4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been813 <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 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 4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been 815 814 refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has 816 815 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 … … 869 868 </p> 870 869 <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 authentication872 using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed873 by the first outbound proxythat 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 cooperatively870 </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 874 873 authenticate a given request. 875 874 </p> … … 1013 1012 </p> 1014 1013 <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 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. 1017 1015 </p> 1018 1016 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1>
Note: See TracChangeset
for help on using the changeset viewer.