Ignore:
Timestamp:
23/01/14 21:04:36 (8 years ago)
Author:
fielding@…
Message:

(editorial) move and expand on discussion of confidentiality of credentials in its own security considerations section; see #539

File:
1 edited

Legend:

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

    r2572 r2573  
    175175</t>
    176176<t>
    177    Challenges and responses are transmitted in header field values, and thus
    178    can easily leak information when not using a secured connection. Depending
    179    on the type of the authentication scheme, it therefore can be necessary to
    180    use a TLS-secured connection ("Transport Layer Security", <xref target="RFC5246"/>).
    181 </t>
    182 <t>
    183177   Authentication parameters are name=value pairs, where the name token is
    184178   matched case-insensitively,
     
    216210<x:note>
    217211  <t>
    218      &Note; Many clients fail to parse challenges containing unknown
    219      schemes. A workaround for this problem is to list well-supported schemes
     212     &Note; Many clients fail to parse a challenge that contains an unknown
     213     scheme. A workaround for this problem is to list well-supported schemes
    220214     (such as "basic") first.<!-- see http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2 -->
    221215  </t>
     
    234228</t>
    235229<t>
    236    Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value
    237    contain the client's credentials for the realm of the resource being
    238    requested, based upon a challenge received in a response (possibly at
    239    some point in the past). When creating their values, the user agent ought to
    240    do so by selecting the challenge with what it considers to be the most
    241    secure auth-scheme that it understands, obtaining credentials from the user
    242    as appropriate.
     230   Both the <x:ref>Authorization</x:ref> field value and the
     231   <x:ref>Proxy-Authorization</x:ref> field value contain the client's
     232   credentials for the realm of the resource being requested, based upon a
     233   challenge received in a response (possibly at some point in the past).
     234   When creating their values, the user agent ought to do so by selecting the
     235   challenge with what it considers to be the most secure auth-scheme that it
     236   understands, obtaining credentials from the user as appropriate.
     237   Transmission of credentials within header field values implies significant
     238   security considerations regarding the confidentiality of the underlying
     239   connection, as described in
     240   <xref target="confidentiality.of.credentials"/>.
    243241</t>
    244242<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="credentials"/>
     
    266264<t>
    267265   HTTP does not restrict applications to this simple challenge-response
    268    framework for access authentication. Additional mechanisms can be used, such
    269    as authentication at the transport level or via message encapsulation, and
    270    with additional header fields specifying authentication information. However,
    271    such additional mechanisms are not defined by this specification.
     266   framework for access authentication. Additional mechanisms can be used,
     267   such as authentication at the transport level or via message encapsulation,
     268   and with additional header fields specifying authentication information.
     269   However, such additional mechanisms are not defined by this specification.
    272270</t>
    273271<t>
     
    702700   schemes found in practice.
    703701</t>
     702
     703<section title="Confidentiality of Credentials" anchor="confidentiality.of.credentials">
     704<t>
     705   The HTTP authentication framework does not define a single mechanism for
     706   maintaining the confidentiality of credentials; instead, each
     707   authentication scheme defines how the credentials are encoded prior to
     708   transmission. While this provides flexibility for the development of future
     709   authentication schemes, it is inadequate for the protection of existing
     710   schemes that provide no confidentiality on their own, or that do not
     711   sufficiently protect against replay attacks. Furthermore, if the server
     712   expects credentials that are specific to each individual user, the exchange
     713   of those credentials will have the effect of identifying that user even if
     714   the content within credentials remains confidential.
     715</t>
     716<t>
     717   HTTP depends on the security properties of the underlying transport or
     718   session-level connection to provide confidential transmission of header
     719   fields. In other words, if a server limits access to authenticated users
     720   using this framework, the server needs to ensure that the connection is
     721   properly secured in accordance with the nature of the authentication
     722   scheme used. For example, services that depend on individual user
     723   authentication often require a connection to be secured with TLS
     724   ("Transport Layer Security", <xref target="RFC5246"/>) prior to exchanging
     725   any credentials.
     726</t>
     727</section>
    704728
    705729<section title="Authentication Credentials and Idle Clients" anchor="auth.credentials.and.idle.clients">
Note: See TracChangeset for help on using the changeset viewer.