Ignore:
Timestamp:
28/04/13 15:38:27 (8 years ago)
Author:
julian.reschke@…
Message:

Apply many editorial suggestions (see #463)

File:
1 edited

Legend:

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

    r2218 r2229  
    3131  <!ENTITY status.403                   "<xref target='Part2' x:rel='#status.403' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3232  <!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'/>">
    3335]>
    3436<?rfc toc="yes" ?>
     
    160162   HTTP provides a simple challenge-response authentication framework
    161163   that can be used by a server to challenge a client request and by a
    162    client to provide authentication information. It uses an extensible,
    163    case-insensitive token to identify the authentication scheme, followed
     164   client to provide authentication information. It uses a case-insensitive
     165   token as a means to identify the authentication scheme, followed
    164166   by additional information necessary for achieving authentication via that
    165167   scheme. The latter can either be a comma-separated list of parameters or a
     
    231233   Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value
    232234   contain the client's credentials for the realm of the resource being
    233    requested, based upon a challenge received from the server (possibly at
     235   requested, based upon a challenge received in a response (possibly at
    234236   some point in the past). When creating their values, the user agent ought to
    235237   do so by selecting the challenge with what it considers to be the most
     
    291293   authentication scheme and/or authorization database. The realm value
    292294   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 but
     295   additional semantics specific to the authentication scheme. Note that a
     296   response can have multiple challenges with the same auth-scheme but
    295297   different realms.
    296298</t>
     
    301303   protection space for a period of time determined by the
    302304   authentication scheme, parameters, and/or user preference. Unless
    303    otherwise defined by the authentication scheme, a single protection
     305   specifically allowed by the authentication scheme, a single protection
    304306   space cannot extend outside the scope of its server.
    305307</t>
     
    362364    <t>
    363365      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.
    365367      New schemes thus ought to use the "auth-param" syntax instead, because
    366368      otherwise future extensions will be impossible.
     
    404406      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
    405407      the User Agent, and therefore have the same effect on HTTP caches as the
    406       "private" Cache-Control response directive, within the scope of the
    407       request they appear in.
     408      "private" Cache-Control response directive (&caching-rsd-private;),
     409      within the scope of the request they appear in.
    408410    </t>
    409411    <t>
     
    411413      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
    412414      header field) will need to explicitly disallow caching, by mandating the use of
    413       either Cache-Control request directives (e.g., "no-store") or response
    414       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").
    415417    </t>
    416418    </x:lt>
     
    435437   If the request included authentication credentials, then the 401 response
    436438   indicates that authorization has been refused for those credentials.
    437    The client &MAY; repeat the request with a new or replaced
     439   The user agent &MAY; repeat the request with a new or replaced
    438440   <x:ref>Authorization</x:ref> header field (<xref target="header.authorization"/>).
    439441   If the 401 response contains the same challenge as the prior response, and
     
    470472<t>
    471473   The "Authorization" header field allows a user agent to authenticate
    472    itself with a server &mdash; usually, but not necessarily, after receiving a <x:ref>401
     474   itself with an origin server &mdash; usually, but not necessarily, after receiving a <x:ref>401
    473475   (Unauthorized)</x:ref> response. Its value consists of credentials containing
    474476   information of the user agent for the realm of the resource being
     
    525527   The "Proxy-Authorization" header field allows the client to
    526528   identify itself (or its user) to a proxy that requires
    527    authentication. Its value consists of
    528    credentials containing the authentication information of the user
    529    agent for the proxy and/or realm of the resource 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.
    530532</t>
    531533<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
     
    718720<t>
    719721  Authentication schemes that solely rely on the "realm" mechanism for
    720   establishing a protection space will expose credentials to all resources on a
    721   server. Clients that have successfully made authenticated requests with a
    722   resource can use the same authentication credentials for other resources on
    723   the same server. This makes it possible for a different resource to harvest
    724   authentication credentials for other resources.
    725 </t>
    726 <t>
    727   This is of particular concern when a server hosts resources for multiple
     722  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
    728730  parties under the same canonical root URI (<xref target="protection.space"/>).
    729731  Possible mitigation strategies include restricting direct access to
    730732  authentication credentials (i.e., not making the content of the
    731733  <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.
    733735</t>
    734736</section>
     
    11701172      "terminology: mechanism vs framework vs scheme"
    11711173    </t>
     1174    <t>
     1175      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/463"/>:
     1176      "Editorial suggestions"
     1177    </t>
    11721178  </list>
    11731179</t>
Note: See TracChangeset for help on using the changeset viewer.