* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #237: i237.diff

File i237.diff, 19.5 KB (added by julian.reschke@gmx.de, 4 years ago)

proposed patch for part 7 (missing: potentially additional authors, change information wrt 2617?)

  • p7-auth.xml

     
    206206<middle> 
    207207<section title="Introduction" anchor="introduction"> 
    208208<t> 
    209    This document defines HTTP/1.1 access control and authentication. Right now it 
    210    includes the extracted relevant sections of 
    211    <xref target="RFC2616" x:fmt="none">RFC 2616</xref> with only minor changes. 
    212    The intention is to move the general framework for HTTP authentication here, 
    213    as currently specified in <xref target="RFC2617"/>, and allow the individual 
    214    authentication mechanisms to be defined elsewhere.  This introduction will 
    215    be rewritten when that occurs.  
     209   This document defines HTTP/1.1 access control and authentication. It 
     210   includes the relevant parts of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> 
     211   with only minor changes, plus the general framework for HTTP authentication, 
     212   as previously defined in <xref target="RFC2617" x:fmt="none">RFC 2617</xref>. 
    216213</t> 
    217 <t> 
    218    HTTP provides several &OPTIONAL; challenge-response authentication 
    219    mechanisms which can be used by a server to challenge a client 
    220    request and by a client to provide authentication information. The 
    221    general framework for access authentication, and the specification of 
    222    "basic" and "digest" authentication, are specified in "HTTP 
    223    Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. This 
    224    specification adopts the definitions of "challenge" and "credentials" 
    225    from that specification. 
    226 </t> 
    227214 
    228215<section title="Requirements" anchor="intro.requirements"> 
    229216<t> 
     
    249236  <x:anchor-alias value="LF"/> 
    250237  <x:anchor-alias value="OCTET"/> 
    251238  <x:anchor-alias value="VCHAR"/> 
     239  <x:anchor-alias value="SP"/> 
    252240  <x:anchor-alias value="WSP"/> 
    253241<t> 
    254242  This specification uses the ABNF syntax defined in &notation; (which 
     
    268256</t> 
    269257 
    270258<section title="Core Rules" anchor="core.rules"> 
    271   <x:anchor-alias value="OWS"/> 
     259   <x:anchor-alias value="quoted-string"/> 
     260   <x:anchor-alias value="token"/> 
     261   <x:anchor-alias value="OWS"/> 
    272262<t> 
    273   The core rules below are defined in &basic-rules;: 
     263   The core rules below are defined in &basic-rules;: 
    274264</t> 
    275265<figure><artwork type="abnf2616"> 
    276   <x:ref>OWS</x:ref>         = &lt;OWS, defined in &basic-rules;&gt; 
     266  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &basic-rules;&gt; 
     267  <x:ref>token</x:ref>         = &lt;token, defined in &basic-rules;&gt; 
     268  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt; 
    277269</artwork></figure> 
    278270</section> 
     271</section> 
     272</section> 
    279273 
    280 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> 
     274<section title="Access Authentication Framework" anchor="access.authentication.framework"> 
     275  <x:anchor-alias value="auth-scheme"/> 
     276  <x:anchor-alias value="auth-param"/> 
    281277  <x:anchor-alias value="challenge"/> 
    282278  <x:anchor-alias value="credentials"/> 
    283279<t> 
    284   <x:anchor-alias value="OWS"/> 
    285   The ABNF rules below are defined in other specifications:  
     280   HTTP provides a simple challenge-response authentication mechanism 
     281   that can be used by a server to challenge a client request and by a 
     282   client to provide authentication information. It uses an extensible, 
     283   case-insensitive token to identify the authentication scheme, 
     284   followed by a comma-separated list of attribute-value pairs which 
     285   carry the parameters necessary for achieving authentication via that 
     286   scheme. 
    286287</t> 
    287 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="challenge"/><iref primary="true" item="Grammar" subitem="credentials"/> 
    288   <x:ref>challenge</x:ref>   = &lt;challenge, defined in <xref target="RFC2617" x:fmt="," x:sec="1.2"/>&gt; 
    289   <x:ref>credentials</x:ref> = &lt;credentials, defined in <xref target="RFC2617" x:fmt="," x:sec="1.2"/>&gt; 
     288<figure><artwork type="abnf2616"><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/> 
     289  auth-scheme    = token 
     290  auth-param     = token "=" ( token / quoted-string ) 
    290291</artwork></figure> 
     292<t> 
     293   The 401 (Unauthorized) response message is used by an origin server 
     294   to challenge the authorization of a user agent. This response &MUST; 
     295   include a WWW-Authenticate header field containing at least one 
     296   challenge applicable to the requested resource. The 407 (Proxy 
     297   Authentication Required) response message is used by a proxy to 
     298   challenge the authorization of a client and &MUST; include a Proxy-Authenticate 
     299   header field containing at least one challenge 
     300   applicable to the proxy for the requested resource. 
     301</t> 
     302<figure><artwork type="abnf2616"><iref item="challenge" primary="true"/> 
     303  <x:ref>challenge</x:ref>   = <x:ref>auth-scheme</x:ref> 1*<x:ref>SP</x:ref> 1#<x:ref>auth-param</x:ref> 
     304</artwork></figure> 
     305<x:note> 
     306  <t> 
     307   <x:h>Note:</x:h> User agents will need to take special care in parsing the WWW-Authenticate 
     308   or Proxy-Authenticate header field value if it contains 
     309   more than one challenge, or if more than one WWW-Authenticate header 
     310   field is provided, since the contents of a challenge can itself 
     311   contain a comma-separated list of authentication parameters. 
     312  </t> 
     313</x:note> 
     314<t> 
     315   The authentication parameter realm is defined for all authentication 
     316   schemes: 
     317</t> 
     318<figure><artwork type="abnf2616"><iref item="realm" primary="true"/><iref item="realm-value" primary="true"/> 
     319  realm       = "realm" "=" realm-value 
     320  realm-value = quoted-string 
     321</artwork></figure> 
     322<t> 
     323   The realm directive (case-insensitive) is required for all 
     324   authentication schemes that issue a challenge. The realm value 
     325   (case-sensitive), in combination with the canonical root URL ( 
     326   the scheme and authority components of the effective request URI; see <xref target="Part1" x:fmt="of" x:rel="#effective.request.uri"/>) of the server being accessed, defines the protection space. 
     327   These realms allow the protected resources on a server to be 
     328   partitioned into a set of protection spaces, each with its own 
     329   authentication scheme and/or authorization database. The realm value 
     330   is a string, generally assigned by the origin server, which can have 
     331   additional semantics specific to the authentication scheme. Note that 
     332   there can be multiple challenges with the same auth-scheme but 
     333   different realms. 
     334</t> 
     335<t> 
     336   A user agent that wishes to authenticate itself with an origin 
     337   server -- usually, but not necessarily, after receiving a 401 
     338   (Unauthorized) -- &MAY; do so by including an Authorization header field 
     339   with the request. A client that wishes to authenticate itself with a 
     340   proxy -- usually, but not necessarily, after receiving a 407 (Proxy 
     341   Authentication Required) -- &MAY; do so by including a Proxy-Authorization 
     342   header field with the request.  Both the Authorization 
     343   field value and the Proxy-Authorization field value consist of 
     344   credentials containing the authentication information of the client 
     345   for the realm of the resource being requested. The user agent &MUST; 
     346   choose to use one of the challenges with the strongest auth-scheme it 
     347   understands and request credentials from the user based upon that 
     348   challenge. 
     349</t> 
     350<figure><artwork type="abnf2616"><iref item="credentials" primary="true"/> 
     351  <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> ( <x:ref>token</x:ref> 
     352                            / <x:ref>quoted-string</x:ref> 
     353                            / #<x:ref>auth-param</x:ref> ) 
     354</artwork></figure> 
     355<x:note> 
     356  <t> 
     357      <x:h>Note:</x:h> many browsers will only recognize Basic and will require 
     358      that it be the first auth-scheme presented. Servers should only 
     359      include Basic if it is minimally acceptable.<cref>Either rephrase and add reference or drop.</cref> 
     360  </t> 
     361</x:note> 
     362<t> 
     363   The protection space determines the domain over which credentials can 
     364   be automatically applied. If a prior request has been authorized, the 
     365   same credentials &MAY; be reused for all other requests within that 
     366   protection space for a period of time determined by the 
     367   authentication scheme, parameters, and/or user preference. Unless 
     368   otherwise defined by the authentication scheme, a single protection 
     369   space cannot extend outside the scope of its server. 
     370</t> 
     371<t> 
     372   If the origin server does not wish to accept the credentials sent 
     373   with a request, it &SHOULD; return a 401 (Unauthorized) response. The 
     374   response &MUST; include a WWW-Authenticate header field containing at 
     375   least one (possibly new) challenge applicable to the requested 
     376   resource. If a proxy does not accept the credentials sent with a 
     377   request, it &SHOULD; return a 407 (Proxy Authentication Required). The 
     378   response &MUST; include a Proxy-Authenticate header field containing a 
     379   (possibly new) challenge applicable to the proxy for the requested 
     380   resource. 
     381</t> 
     382<t> 
     383   The HTTP protocol does not restrict applications to this simple 
     384   challenge-response mechanism for access authentication. Additional 
     385   mechanisms &MAY; be used, such as encryption at the transport level or 
     386   via message encapsulation, and with additional header fields 
     387   specifying authentication information. However, these additional 
     388   mechanisms are not defined by this specification. 
     389</t> 
     390<t> 
     391   Proxies &MUST; be completely transparent regarding user agent 
     392   authentication by origin servers. That is, they &MUST; forward the 
     393   WWW-Authenticate and Authorization headers untouched, and follow the 
     394   rules found in <xref target="header.authorization"/>. Both the Proxy-Authenticate and 
     395   the Proxy-Authorization header fields are hop-by-hop headers (see 
     396   <xref target="Part1" x:fmt="of" x:rel="#end-to-end.and.hop-by-hop.headers"/>). 
     397</t> 
    291398</section> 
    292399 
    293 </section> 
    294  
    295 </section> 
    296  
    297  
    298400<section title="Status Code Definitions" anchor="status.code.definitions"> 
    299401<section title="401 Unauthorized" anchor="status.401"> 
    300402  <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/> 
     
    310412   prior response, and the user agent has already attempted 
    311413   authentication at least once, then the user &SHOULD; be presented the 
    312414   representation that was given in the response, since that representation might 
    313    include relevant diagnostic information. HTTP access authentication 
    314    is explained in "HTTP Authentication: Basic and Digest Access 
    315    Authentication" <xref target="RFC2617"/>. 
     415   include relevant diagnostic information. 
    316416</t> 
    317417</section> 
    318418<section title="407 Proxy Authentication Required" anchor="status.407"> 
     
    320420  <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required" x:for-anchor=""/> 
    321421<t> 
    322422   This code is similar to 401 (Unauthorized), but indicates that the 
    323    client must first authenticate itself with the proxy. The proxy &MUST; 
     423   client ought to first authenticate itself with the proxy. The proxy &MUST; 
    324424   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a 
    325425   challenge applicable to the proxy for the target resource. The 
    326426   client &MAY; repeat the request with a suitable Proxy-Authorization 
    327    header field (<xref target="header.proxy-authorization"/>). HTTP access authentication is explained 
    328    in "HTTP Authentication: Basic and Digest Access Authentication" 
    329    <xref target="RFC2617"/>. 
     427   header field (<xref target="header.proxy-authorization"/>). 
    330428</t> 
    331429</section> 
    332430</section> 
     
    354452  <x:ref>Authorization-v</x:ref> = <x:ref>credentials</x:ref> 
    355453</artwork></figure> 
    356454<t> 
    357    HTTP access authentication is described in "HTTP Authentication: 
    358    Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is 
     455   If a request is 
    359456   authenticated and a realm specified, the same credentials &SHOULD; 
    360457   be valid for all other requests within this realm (assuming that 
    361458   the authentication scheme itself does not require otherwise, such 
     
    410507  <x:ref>Proxy-Authenticate-v</x:ref> = 1#<x:ref>challenge</x:ref> 
    411508</artwork></figure> 
    412509<t> 
    413    The HTTP access authentication process is described in "HTTP 
    414    Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike 
    415    WWW-Authenticate, the Proxy-Authenticate header field applies only to 
     510   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to 
    416511   the current connection and &SHOULD-NOT;  be passed on to downstream 
    417512   clients. However, an intermediate proxy might need to obtain its own 
    418513   credentials by requesting them from the downstream client, which in 
     
    439534  <x:ref>Proxy-Authorization-v</x:ref> = <x:ref>credentials</x:ref> 
    440535</artwork></figure> 
    441536<t> 
    442    The HTTP access authentication process is described in "HTTP 
    443    Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike 
    444    Authorization, the Proxy-Authorization header field applies only to 
     537   Unlike Authorization, the Proxy-Authorization header field applies only to 
    445538   the next outbound proxy that demanded authentication using the Proxy-Authenticate 
    446539   field. When multiple proxies are used in a chain, the 
    447540   Proxy-Authorization header field is consumed by the first outbound 
     
    468561  <x:ref>WWW-Authenticate-v</x:ref> = 1#<x:ref>challenge</x:ref> 
    469562</artwork></figure> 
    470563<t> 
    471    The HTTP access authentication process is described in "HTTP 
    472    Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. User 
    473    agents are advised to take special care in parsing the WWW-Authenticate 
     564   User agents are advised to take special care in parsing the WWW-Authenticate 
    474565   field value as it might contain more than one challenge, 
    475566   or if more than one WWW-Authenticate header field is provided, the 
    476567   contents of a challenge itself can contain a comma-separated list of 
     
    711802  <seriesInfo name="RFC" value="2119"/> 
    712803</reference> 
    713804 
    714 <reference anchor="RFC2617"> 
    715   <front> 
    716     <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title> 
    717     <author initials="J." surname="Franks" fullname="John Franks"> 
    718       <organization>Northwestern University, Department of Mathematics</organization> 
    719       <address><email>john@math.nwu.edu</email></address> 
    720     </author> 
    721     <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"> 
    722       <organization>Verisign Inc.</organization> 
    723       <address><email>pbaker@verisign.com</email></address> 
    724     </author> 
    725     <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"> 
    726       <organization>AbiSource, Inc.</organization> 
    727       <address><email>jeff@AbiSource.com</email></address> 
    728     </author> 
    729     <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"> 
    730       <organization>Agranat Systems, Inc.</organization> 
    731       <address><email>lawrence@agranat.com</email></address> 
    732     </author> 
    733     <author initials="P.J." surname="Leach" fullname="Paul J. Leach"> 
    734       <organization>Microsoft Corporation</organization> 
    735       <address><email>paulle@microsoft.com</email></address> 
    736     </author> 
    737     <author initials="A." surname="Luotonen" fullname="Ari Luotonen"> 
    738       <organization>Netscape Communications Corporation</organization> 
    739     </author> 
    740     <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"> 
    741       <organization>Open Market, Inc.</organization> 
    742       <address><email>stewart@OpenMarket.com</email></address> 
    743     </author> 
    744     <date month="June" year="1999"/> 
    745   </front> 
    746   <seriesInfo name="RFC" value="2617"/> 
    747 </reference> 
    748  
    749805<reference anchor="RFC5234"> 
    750806  <front> 
    751807    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> 
     
    807863  <seriesInfo name="RFC" value="2616"/> 
    808864</reference> 
    809865 
     866<reference anchor="RFC2617"> 
     867  <front> 
     868    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title> 
     869    <author initials="J." surname="Franks" fullname="John Franks"> 
     870      <organization>Northwestern University, Department of Mathematics</organization> 
     871      <address><email>john@math.nwu.edu</email></address> 
     872    </author> 
     873    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"> 
     874      <organization>Verisign Inc.</organization> 
     875      <address><email>pbaker@verisign.com</email></address> 
     876    </author> 
     877    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"> 
     878      <organization>AbiSource, Inc.</organization> 
     879      <address><email>jeff@AbiSource.com</email></address> 
     880    </author> 
     881    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"> 
     882      <organization>Agranat Systems, Inc.</organization> 
     883      <address><email>lawrence@agranat.com</email></address> 
     884    </author> 
     885    <author initials="P.J." surname="Leach" fullname="Paul J. Leach"> 
     886      <organization>Microsoft Corporation</organization> 
     887      <address><email>paulle@microsoft.com</email></address> 
     888    </author> 
     889    <author initials="A." surname="Luotonen" fullname="Ari Luotonen"> 
     890      <organization>Netscape Communications Corporation</organization> 
     891    </author> 
     892    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"> 
     893      <organization>Open Market, Inc.</organization> 
     894      <address><email>stewart@OpenMarket.com</email></address> 
     895    </author> 
     896    <date month="June" year="1999"/> 
     897  </front> 
     898  <seriesInfo name="RFC" value="2617"/> 
     899</reference> 
     900 
    810901<reference anchor='RFC3864'> 
    811902  <front> 
    812903    <title>Registration Procedures for Message Header Fields</title> 
     
    855946<x:ref>WWW-Authenticate-v</x:ref> = *( "," OWS ) challenge *( OWS "," [ OWS 
    856947 challenge ] ) 
    857948 
    858 <x:ref>challenge</x:ref> = &lt;challenge, defined in [RFC2617], Section 1.2&gt; 
    859 <x:ref>credentials</x:ref> = &lt;credentials, defined in [RFC2617], Section 1.2&gt; 
     949<x:ref>auth-param</x:ref> = token "=" ( token / quoted-string ) 
     950<x:ref>auth-scheme</x:ref> = token 
     951 
     952<x:ref>challenge</x:ref> = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS 
     953 auth-param ] ) 
     954<x:ref>credentials</x:ref> = auth-scheme ( token / quoted-string / [ ( "," / 
     955 auth-param ) *( OWS "," [ OWS auth-param ] ) ] ) 
     956 
     957<x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in [Part1], Section 1.2.2&gt; 
     958 
     959realm = "realm=" realm-value 
     960realm-value = quoted-string 
     961 
     962<x:ref>token</x:ref> = &lt;token, defined in [Part1], Section 1.2.2&gt; 
    860963</artwork> 
    861964</figure> 
    862965<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"> 
     
    864967; Proxy-Authenticate defined but not used 
    865968; Proxy-Authorization defined but not used 
    866969; WWW-Authenticate defined but not used 
     970; realm defined but not used 
    867971</artwork></figure></section> 
    868972<?ENDINC p7-auth.abnf-appendix ?> 
    869973 
     
    9921096 
    9931097<section title="Since draft-ietf-httpbis-p7-auth-11" anchor="changes.since.11"> 
    9941098<t> 
    995   None yet. 
     1099  Closed issues: 
     1100  <list style="symbols">  
     1101    <t> 
     1102      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>: 
     1103      "auth-param syntax" 
     1104    </t> 
     1105  </list> 
    9961106</t> 
     1107<t> 
     1108  Partly resolved issues: 
     1109  <list style="symbols">  
     1110    <t> 
     1111      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/237"/>: 
     1112      "absorbing the auth framework from 2617" 
     1113    </t> 
     1114  </list> 
     1115</t> 
    9971116</section> 
    9981117 
    9991118</section>