Changeset 2229 for draft-ietf-httpbis/latest
- Timestamp:
- 28/04/13 15:38:27 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.html
r2218 r2229 449 449 } 450 450 @bottom-center { 451 content: "Expires October 2013";451 content: "Expires October 30, 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="2013-04 ">491 <meta name="dct.issued" scheme="ISO8601" content="2013-04-28"> 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. This document defines the HTTP Authentication framework."> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">April 2 013</td>519 <td class="right">April 28, 2013</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: October 2013</td>522 <td class="left">Expires: October 30, 2013</td> 523 523 <td class="right"></td> 524 524 </tr> … … 546 546 in progress”. 547 547 </p> 548 <p>This Internet-Draft will expire in October2013.</p>548 <p>This Internet-Draft will expire on October 30, 2013.</p> 549 549 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 550 550 <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> <a id="challenge.and.response" href="#challenge.and.response">Challenge and Response</a></h2> 640 640 <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 a n extensible, case-insensitive tokento identify the authentication641 and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication 642 642 scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can either be 643 643 a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information. … … 674 674 </p> 675 675 <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 selecting676 in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting 677 677 the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the 678 678 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 702 702 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. 704 704 </p> 705 705 <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 706 706 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 cannot707 parameters, and/or user preference. Unless specifically allowed by the authentication scheme, a single protection space cannot 708 708 extend outside the scope of its server. 709 709 </p> … … 742 742 <li> 743 743 <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 extensions744 challenge or credential. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions 745 745 will be impossible. 746 746 </p> … … 769 769 <li> 770 770 <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. 772 772 </p> 773 773 <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"). 775 775 </p> 776 776 </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 782 782 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 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 4.1</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication783 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 4.1</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication 784 784 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. 785 785 </p> … … 792 792 <div id="rfc.iref.a.1"></div> 793 793 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <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, 795 795 after receiving a <a href="#status.401" class="smpl">401 796 796 (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). 801 801 </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. 803 803 </p> 804 804 <div id="rfc.iref.p.2"></div> … … 817 817 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2> 818 818 <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 of820 theresource 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. 821 821 </p> 822 822 <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> <a id="protection.spaces" href="#protection.spaces">Protection Spaces</a></h2> 958 958 <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 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 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. 965 967 </p> 966 968 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> … … 1135 1137 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/439">http://tools.ietf.org/wg/httpbis/trac/ticket/439</a>>: "terminology: mechanism vs framework vs scheme" 1136 1138 </li> 1139 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/463">http://tools.ietf.org/wg/httpbis/trac/ticket/463</a>>: "Editorial suggestions" 1140 </li> 1137 1141 </ul> 1138 1142 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> … … 1189 1193 </ul> 1190 1194 </li> 1191 <li><em>Part6</em> <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> <a href="#rfc.xref.Part6.1">4.1</a></li> 1195 <li><em>Part6</em> <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> <a href="#rfc.xref.Part6.3">4.1</a></li> 1197 <li><em>Section 7.2.1.2</em> <a href="#rfc.xref.Part6.2">2.3.1</a></li> 1198 <li><em>Section 7.2.2.2</em> <a href="#rfc.xref.Part6.1">2.3.1</a></li> 1193 1199 </ul> 1194 1200 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r2218 r2229 31 31 <!ENTITY status.403 "<xref target='Part2' x:rel='#status.403' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!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'/>"> 33 35 ]> 34 36 <?rfc toc="yes" ?> … … 160 162 HTTP provides a simple challenge-response authentication framework 161 163 that can be used by a server to challenge a client request and by a 162 client to provide authentication information. It uses a n extensible,163 case-insensitive tokento identify the authentication scheme, followed164 client to provide authentication information. It uses a case-insensitive 165 token as a means to identify the authentication scheme, followed 164 166 by additional information necessary for achieving authentication via that 165 167 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 232 234 contain the client's credentials for the realm of the resource being 233 requested, based upon a challenge received from the server(possibly at235 requested, based upon a challenge received in a response (possibly at 234 236 some point in the past). When creating their values, the user agent ought to 235 237 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 292 294 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 but295 additional semantics specific to the authentication scheme. Note that a 296 response can have multiple challenges with the same auth-scheme but 295 297 different realms. 296 298 </t> … … 301 303 protection space for a period of time determined by the 302 304 authentication scheme, parameters, and/or user preference. Unless 303 otherwise defined by the authentication scheme, a single protection305 specifically allowed by the authentication scheme, a single protection 304 306 space cannot extend outside the scope of its server. 305 307 </t> … … 362 364 <t> 363 365 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. 365 367 New schemes thus ought to use the "auth-param" syntax instead, because 366 368 otherwise future extensions will be impossible. … … 404 406 The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to 405 407 the User Agent, and therefore have the same effect on HTTP caches as the 406 "private" Cache-Control response directive , within the scope of the407 request they appear in.408 "private" Cache-Control response directive (&caching-rsd-private;), 409 within the scope of the request they appear in. 408 410 </t> 409 411 <t> … … 411 413 credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined 412 414 header field) will need to explicitly disallow caching, by mandating the use of 413 either Cache-Control request directives (e.g., "no-store" ) or response414 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"). 415 417 </t> 416 418 </x:lt> … … 435 437 If the request included authentication credentials, then the 401 response 436 438 indicates that authorization has been refused for those credentials. 437 The client &MAY; repeat the request with a new or replaced439 The user agent &MAY; repeat the request with a new or replaced 438 440 <x:ref>Authorization</x:ref> header field (<xref target="header.authorization"/>). 439 441 If the 401 response contains the same challenge as the prior response, and … … 470 472 <t> 471 473 The "Authorization" header field allows a user agent to authenticate 472 itself with a server — usually, but not necessarily, after receiving a <x:ref>401474 itself with an origin server — usually, but not necessarily, after receiving a <x:ref>401 473 475 (Unauthorized)</x:ref> response. Its value consists of credentials containing 474 476 information of the user agent for the realm of the resource being … … 525 527 The "Proxy-Authorization" header field allows the client to 526 528 identify itself (or its user) to a proxy that requires 527 authentication. Its value consists of 528 credentials containing the authentication information of the user529 agent for the proxy and/or realm of theresource 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. 530 532 </t> 531 533 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/> … … 718 720 <t> 719 721 Authentication schemes that solely rely on the "realm" mechanism for 720 establishing a protection space will expose credentials to all resources on a721 server. Clients that have successfully made authenticated requests with a722 resource can use the same authentication credentials for other resources on723 the same server. This makes it possible for a different resource to harvest724 authentication credentials for other resources.725 </t> 726 <t> 727 This is of particular concern when a server hosts resources for multiple722 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 728 730 parties under the same canonical root URI (<xref target="protection.space"/>). 729 731 Possible mitigation strategies include restricting direct access to 730 732 authentication credentials (i.e., not making the content of the 731 733 <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. 733 735 </t> 734 736 </section> … … 1170 1172 "terminology: mechanism vs framework vs scheme" 1171 1173 </t> 1174 <t> 1175 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/463"/>: 1176 "Editorial suggestions" 1177 </t> 1172 1178 </list> 1173 1179 </t>
Note: See TracChangeset
for help on using the changeset viewer.