Ignore:
Timestamp:
Sep 13, 2010, 7:47:24 AM (9 years ago)
Author:
julian.reschke@…
Message:

Incorporate auth framework from RFC 2617; ack RFC 2617's authors, fix known auth-param erratum (see #195)(see #237)

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p7-auth.xml

    r994 r998  
    1919  <!ENTITY basic-rules                  "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2020  <!ENTITY effective-request-uri        "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     21  <!ENTITY end-to-end.and-hop-by-hop    "<xref target='Part1' x:rel='#end-to-end.and.hop-by-hop.header-fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2122  <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2223]>
    … …  
    207208<section title="Introduction" anchor="introduction">
    208209<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.
     210   This document defines HTTP/1.1 access control and authentication. It
     211   includes the relevant parts of <xref target="RFC2616" x:fmt="none">RFC 2616</xref>
     212   with only minor changes, plus the general framework for HTTP authentication,
     213   as previously defined in "HTTP Authentication: Basic and Digest Access
     214   Authentication" (<xref target="RFC2617"/>).
    216215</t>
    217216<t>
    218217   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.
     218   mechanisms which can be used by a server to challenge a client request and
     219   by a client to provide authentication information. The "basic" and "digest"
     220   authentication schemes continue to be specified in
     221   <xref target="RFC2617" x:fmt="none">RFC 2617</xref>.
    226222</t>
    227223
    … …  
    250246  <x:anchor-alias value="OCTET"/>
    251247  <x:anchor-alias value="VCHAR"/>
     248  <x:anchor-alias value="SP"/>
    252249  <x:anchor-alias value="WSP"/>
    253250<t>
    … …  
    269266
    270267<section title="Core Rules" anchor="core.rules">
    271   <x:anchor-alias value="OWS"/>
    272 <t>
    273   The core rules below are defined in &basic-rules;:
     268   <x:anchor-alias value="quoted-string"/>
     269   <x:anchor-alias value="token"/>
     270   <x:anchor-alias value="OWS"/>
     271<t>
     272   The core rules below are defined in &basic-rules;:
    274273</t>
    275274<figure><artwork type="abnf2616">
    276   <x:ref>OWS</x:ref>         = &lt;OWS, defined in &basic-rules;&gt;
     275  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &basic-rules;&gt;
     276  <x:ref>token</x:ref>         = &lt;token, defined in &basic-rules;&gt;
     277  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt;
    277278</artwork></figure>
    278279</section>
    279 
    280 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
     280</section>
     281</section>
     282
     283<section title="Access Authentication Framework" anchor="access.authentication.framework">
     284  <x:anchor-alias value="auth-scheme"/>
     285  <x:anchor-alias value="auth-param"/>
    281286  <x:anchor-alias value="challenge"/>
    282287  <x:anchor-alias value="credentials"/>
    283288<t>
    284   <x:anchor-alias value="OWS"/>
    285   The ABNF rules below are defined in other specifications:
    286 </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;
     289   HTTP provides a simple challenge-response authentication mechanism
     290   that can be used by a server to challenge a client request and by a
     291   client to provide authentication information. It uses an extensible,
     292   case-insensitive token to identify the authentication scheme,
     293   followed by a comma-separated list of attribute-value pairs which
     294   carry the parameters necessary for achieving authentication via that
     295   scheme.
     296</t>
     297<figure><artwork type="abnf2616"><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/>
     298  auth-scheme    = token
     299  auth-param     = token "=" ( token / quoted-string )
    290300</artwork></figure>
    291 </section>
    292 
    293 </section>
    294 
    295 </section>
    296 
     301<t>
     302   The 401 (Unauthorized) response message is used by an origin server
     303   to challenge the authorization of a user agent. This response &MUST;
     304   include a WWW-Authenticate header field containing at least one
     305   challenge applicable to the requested resource. The 407 (Proxy
     306   Authentication Required) response message is used by a proxy to
     307   challenge the authorization of a client and &MUST; include a Proxy-Authenticate
     308   header field containing at least one challenge
     309   applicable to the proxy for the requested resource.
     310</t>
     311<figure><artwork type="abnf2616"><iref item="challenge" primary="true"/>
     312  <x:ref>challenge</x:ref>   = <x:ref>auth-scheme</x:ref> 1*<x:ref>SP</x:ref> 1#<x:ref>auth-param</x:ref>
     313</artwork></figure>
     314<x:note>
     315  <t>
     316   <x:h>Note:</x:h> User agents will need to take special care in parsing the WWW-Authenticate
     317   or Proxy-Authenticate header field value if it contains
     318   more than one challenge, or if more than one WWW-Authenticate header
     319   field is provided, since the contents of a challenge can itself
     320   contain a comma-separated list of authentication parameters.
     321  </t>
     322</x:note>
     323<t>
     324   The authentication parameter realm is defined for all authentication
     325   schemes:
     326</t>
     327<figure><artwork type="abnf2616"><iref item="realm" primary="true"/><iref item="realm-value" primary="true"/>
     328  realm       = "realm" "=" realm-value
     329  realm-value = quoted-string
     330</artwork></figure>
     331<t>
     332   The realm directive (case-insensitive) is required for all
     333   authentication schemes that issue a challenge. The realm value
     334   (case-sensitive), in combination with the canonical root URL (
     335   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.
     336   These realms allow the protected resources on a server to be
     337   partitioned into a set of protection spaces, each with its own
     338   authentication scheme and/or authorization database. The realm value
     339   is a string, generally assigned by the origin server, which can have
     340   additional semantics specific to the authentication scheme. Note that
     341   there can be multiple challenges with the same auth-scheme but
     342   different realms.
     343</t>
     344<t>
     345   A user agent that wishes to authenticate itself with an origin
     346   server -- usually, but not necessarily, after receiving a 401
     347   (Unauthorized) -- &MAY; do so by including an Authorization header field
     348   with the request. A client that wishes to authenticate itself with a
     349   proxy -- usually, but not necessarily, after receiving a 407 (Proxy
     350   Authentication Required) -- &MAY; do so by including a Proxy-Authorization
     351   header field with the request.  Both the Authorization
     352   field value and the Proxy-Authorization field value consist of
     353   credentials containing the authentication information of the client
     354   for the realm of the resource being requested. The user agent &MUST;
     355   choose to use one of the challenges with the strongest auth-scheme it
     356   understands and request credentials from the user based upon that
     357   challenge.
     358</t>
     359<figure><artwork type="abnf2616"><iref item="credentials" primary="true"/>
     360  <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> ( <x:ref>token</x:ref>
     361                            / <x:ref>quoted-string</x:ref>
     362                            / #<x:ref>auth-param</x:ref> )
     363</artwork></figure>
     364<x:note>
     365  <t>
     366      <x:h>Note:</x:h> many browsers will only recognize Basic and will require
     367      that it be the first auth-scheme presented. Servers should only
     368      include Basic if it is minimally acceptable.<cref>Either rephrase and add reference or drop.</cref>
     369  </t>
     370</x:note>
     371<t>
     372   The protection space determines the domain over which credentials can
     373   be automatically applied. If a prior request has been authorized, the
     374   same credentials &MAY; be reused for all other requests within that
     375   protection space for a period of time determined by the
     376   authentication scheme, parameters, and/or user preference. Unless
     377   otherwise defined by the authentication scheme, a single protection
     378   space cannot extend outside the scope of its server.
     379</t>
     380<t>
     381   If the origin server does not wish to accept the credentials sent
     382   with a request, it &SHOULD; return a 401 (Unauthorized) response. The
     383   response &MUST; include a WWW-Authenticate header field containing at
     384   least one (possibly new) challenge applicable to the requested
     385   resource. If a proxy does not accept the credentials sent with a
     386   request, it &SHOULD; return a 407 (Proxy Authentication Required). The
     387   response &MUST; include a Proxy-Authenticate header field containing a
     388   (possibly new) challenge applicable to the proxy for the requested
     389   resource.
     390</t>
     391<t>
     392   The HTTP protocol does not restrict applications to this simple
     393   challenge-response mechanism for access authentication. Additional
     394   mechanisms &MAY; be used, such as encryption at the transport level or
     395   via message encapsulation, and with additional header fields
     396   specifying authentication information. However, these additional
     397   mechanisms are not defined by this specification.
     398</t>
     399<t>
     400   Proxies &MUST; be completely transparent regarding user agent
     401   authentication by origin servers. That is, they &MUST; forward the
     402   WWW-Authenticate and Authorization headers untouched, and follow the
     403   rules found in <xref target="header.authorization"/>. Both the Proxy-Authenticate and
     404   the Proxy-Authorization header fields are hop-by-hop headers (see
     405   &end-to-end.and-hop-by-hop;).
     406</t>
     407</section>
    297408
    298409<section title="Status Code Definitions" anchor="status.code.definitions">
    … …  
    311422   authentication at least once, then the user &SHOULD; be presented the
    312423   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"/>.
     424   include relevant diagnostic information.
    316425</t>
    317426</section>
    … …  
    321430<t>
    322431   This code is similar to 401 (Unauthorized), but indicates that the
    323    client must first authenticate itself with the proxy. The proxy &MUST;
     432   client ought to first authenticate itself with the proxy. The proxy &MUST;
    324433   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
    325434   challenge applicable to the proxy for the target resource. The
    326435   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"/>.
     436   header field (<xref target="header.proxy-authorization"/>).
    330437</t>
    331438</section>
    … …  
    355462</artwork></figure>
    356463<t>
    357    HTTP access authentication is described in "HTTP Authentication:
    358    Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is
     464   If a request is
    359465   authenticated and a realm specified, the same credentials &SHOULD;
    360466   be valid for all other requests within this realm (assuming that
    … …  
    411517</artwork></figure>
    412518<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
     519   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to
    416520   the current connection and &SHOULD-NOT;  be passed on to downstream
    417521   clients. However, an intermediate proxy might need to obtain its own
    … …  
    440544</artwork></figure>
    441545<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
     546   Unlike Authorization, the Proxy-Authorization header field applies only to
    445547   the next outbound proxy that demanded authentication using the Proxy-Authenticate
    446548   field. When multiple proxies are used in a chain, the
    … …  
    469571</artwork></figure>
    470572<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
     573   User agents are advised to take special care in parsing the WWW-Authenticate
    474574   field value as it might contain more than one challenge,
    475575   or if more than one WWW-Authenticate header field is provided, the
    … …  
    597697<section title="Acknowledgments" anchor="ack">
    598698<t>
    599   <cref anchor="acks">TBD.</cref>
     699  This specification takes over the definition of the HTTP Authentication
     700  Framework, previously defined in <xref target="RFC2616" x:fmt="none">RFC 2617</xref>. We thank to John Franks,
     701  Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence,
     702  Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work
     703  on that specification.
     704</t>
     705<t>
     706  <cref anchor="acks">HTTPbis acknowledgements.</cref>
    600707</t>
    601708</section>
    … …  
    710817  <seriesInfo name="BCP" value="14"/>
    711818  <seriesInfo name="RFC" value="2119"/>
    712 </reference>
    713 
    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"/>
    747819</reference>
    748820
    … …  
    808880</reference>
    809881
     882<reference anchor="RFC2617">
     883  <front>
     884    <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
     885    <author initials="J." surname="Franks" fullname="John Franks">
     886      <organization>Northwestern University, Department of Mathematics</organization>
     887      <address><email>john@math.nwu.edu</email></address>
     888    </author>
     889    <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
     890      <organization>Verisign Inc.</organization>
     891      <address><email>pbaker@verisign.com</email></address>
     892    </author>
     893    <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
     894      <organization>AbiSource, Inc.</organization>
     895      <address><email>jeff@AbiSource.com</email></address>
     896    </author>
     897    <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
     898      <organization>Agranat Systems, Inc.</organization>
     899      <address><email>lawrence@agranat.com</email></address>
     900    </author>
     901    <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
     902      <organization>Microsoft Corporation</organization>
     903      <address><email>paulle@microsoft.com</email></address>
     904    </author>
     905    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
     906      <organization>Netscape Communications Corporation</organization>
     907    </author>
     908    <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
     909      <organization>Open Market, Inc.</organization>
     910      <address><email>stewart@OpenMarket.com</email></address>
     911    </author>
     912    <date month="June" year="1999"/>
     913  </front>
     914  <seriesInfo name="RFC" value="2617"/>
     915</reference>
     916
    810917<reference anchor='RFC3864'>
    811918  <front>
    … …  
    856963 challenge ] )
    857964
    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;
     965<x:ref>auth-param</x:ref> = token "=" ( token / quoted-string )
     966<x:ref>auth-scheme</x:ref> = token
     967
     968<x:ref>challenge</x:ref> = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS
     969 auth-param ] )
     970<x:ref>credentials</x:ref> = auth-scheme ( token / quoted-string / [ ( "," /
     971 auth-param ) *( OWS "," [ OWS auth-param ] ) ] )
     972
     973<x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in [Part1], Section 1.2.2&gt;
     974
     975realm = "realm=" realm-value
     976realm-value = quoted-string
     977
     978<x:ref>token</x:ref> = &lt;token, defined in [Part1], Section 1.2.2&gt;
    860979</artwork>
    861980</figure>
    … …  
    865984; Proxy-Authorization defined but not used
    866985; WWW-Authenticate defined but not used
     986; realm defined but not used
    867987</artwork></figure></section>
    868988<?ENDINC p7-auth.abnf-appendix ?>
    … …  
    9931113<section title="Since draft-ietf-httpbis-p7-auth-11" anchor="changes.since.11">
    9941114<t>
    995   None yet.
     1115  Closed issues:
     1116  <list style="symbols">
     1117    <t>
     1118      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>:
     1119      "auth-param syntax"
     1120    </t>
     1121    <t>
     1122      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/237"/>:
     1123      "absorbing the auth framework from 2617"
     1124    </t>
     1125  </list>
    9961126</t>
    9971127</section>
Note: See TracChangeset for help on using the changeset viewer.