Changeset 2573


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

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

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

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

    r2572 r2573  
    600600         </li>
    601601         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    602                <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></li>
    603                <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#protection.spaces">Protection Spaces</a></li>
     602               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#confidentiality.of.credentials">Confidentiality of Credentials</a></li>
     603               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></li>
     604               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#protection.spaces">Protection Spaces</a></li>
    604605            </ul>
    605606         </li>
     
    653654               a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.
    654655            </p>
    655             <p id="rfc.section.2.1.p.2">Challenges and responses are transmitted in header field values, and thus can easily leak information when not using a secured
    656                connection. Depending on the type of the authentication scheme, it therefore can be necessary to use a TLS-secured connection
    657                ("Transport Layer Security", <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>).
    658             </p>
    659             <p id="rfc.section.2.1.p.3">Authentication parameters are name=value pairs, where the name token is matched case-insensitively, and each parameter name <em class="bcp14">MUST</em> only occur once per challenge.
     656            <p id="rfc.section.2.1.p.2">Authentication parameters are name=value pairs, where the name token is matched case-insensitively, and each parameter name <em class="bcp14">MUST</em> only occur once per challenge.
    660657            </p>
    661658            <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  auth-scheme    = <a href="#imported.abnf" class="smpl">token</a>
     
    665662  token68        = 1*( <a href="#imported.abnf" class="smpl">ALPHA</a> / <a href="#imported.abnf" class="smpl">DIGIT</a> /
    666663                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
    667 </pre><p id="rfc.section.2.1.p.5">The "token68" syntax allows the 66 unreserved URI characters (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding,
     664</pre><p id="rfc.section.2.1.p.4">The "token68" syntax allows the 66 unreserved URI characters (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding,
    668665               with or without padding, but excluding whitespace (<a href="#RFC4648" id="rfc.xref.RFC4648.1"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>).
    669666            </p>
    670             <p id="rfc.section.2.1.p.6">The <a href="#status.401" class="smpl">401 (Unauthorized)</a> response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one challenge applicable to the requested resource.
    671             </p>
    672             <p id="rfc.section.2.1.p.7">The <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing at least one challenge applicable to the proxy for the requested resource.
     667            <p id="rfc.section.2.1.p.5">The <a href="#status.401" class="smpl">401 (Unauthorized)</a> response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one challenge applicable to the requested resource.
     668            </p>
     669            <p id="rfc.section.2.1.p.6">The <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing at least one challenge applicable to the proxy for the requested resource.
    673670            </p>
    674671            <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#challenge.and.response" class="smpl">challenge</a>   = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
    675 </pre><div class="note" id="rfc.section.2.1.p.9">
    676                <p><b>Note:</b> Many clients fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported
     672</pre><div class="note" id="rfc.section.2.1.p.8">
     673               <p><b>Note:</b> Many clients fail to parse a challenge that contains an unknown scheme. A workaround for this problem is to list well-supported
    677674                  schemes (such as "basic") first.
    678675               </p>
    679676            </div>
    680             <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an <a href="#header.authorization" class="smpl">Authorization</a> header field with the request.
    681             </p>
    682             <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field with the request.
    683             </p>
    684             <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
     677            <p id="rfc.section.2.1.p.9">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an <a href="#header.authorization" class="smpl">Authorization</a> header field with the request.
     678            </p>
     679            <p id="rfc.section.2.1.p.10">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field with the request.
     680            </p>
     681            <p id="rfc.section.2.1.p.11">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
    685682               in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
    686683               the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the
    687                user as appropriate.
     684               user as appropriate. Transmission of credentials within header field values implies significant security considerations regarding
     685               the confidentiality of the underlying connection, as described in <a href="#confidentiality.of.credentials" title="Confidentiality of Credentials">Section&nbsp;6.1</a>.
    688686            </p>
    689687            <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
    690 </pre><p id="rfc.section.2.1.p.14">Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password)
     688</pre><p id="rfc.section.2.1.p.13">Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password)
    691689               or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response that contains a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field with at least one (possibly new) challenge applicable to the requested resource.
    692690            </p>
    693             <p id="rfc.section.2.1.p.15">Likewise, upon receipt of a request that requires authentication by proxies that omit credentials or contain invalid or partial
     691            <p id="rfc.section.2.1.p.14">Likewise, upon receipt of a request that requires authentication by proxies that omit credentials or contain invalid or partial
    694692               credentials, a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with a (possibly new) challenge applicable to the proxy.
    695693            </p>
    696             <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    697             </p>
    698             <p id="rfc.section.2.1.p.17">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
     694            <p id="rfc.section.2.1.p.15">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     695            </p>
     696            <p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
    699697               can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields
    700698               specifying authentication information. However, such additional mechanisms are not defined by this specification.
    701699            </p>
    702             <p id="rfc.section.2.1.p.18">A proxy <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
     700            <p id="rfc.section.2.1.p.17">A proxy <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
    703701            </p>
    704702         </div>
     
    987985            on Web application security (e.g., <a href="#OWASP" id="rfc.xref.OWASP.1"><cite title="A Guide to Building Secure Web Applications and Web Services">[OWASP]</cite></a>), including common pitfalls for implementing and using the authentication schemes found in practice.
    988986         </p>
     987         <div id="confidentiality.of.credentials">
     988            <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a href="#confidentiality.of.credentials">Confidentiality of Credentials</a></h2>
     989            <p id="rfc.section.6.1.p.1">The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials; instead,
     990               each authentication scheme defines how the credentials are encoded prior to transmission. While this provides flexibility
     991               for the development of future authentication schemes, it is inadequate for the protection of existing schemes that provide
     992               no confidentiality on their own, or that do not sufficiently protect against replay attacks. Furthermore, if the server expects
     993               credentials that are specific to each individual user, the exchange of those credentials will have the effect of identifying
     994               that user even if the content within credentials remains confidential.
     995            </p>
     996            <p id="rfc.section.6.1.p.2">HTTP depends on the security properties of the underlying transport or session-level connection to provide confidential transmission
     997               of header fields. In other words, if a server limits access to authenticated users using this framework, the server needs
     998               to ensure that the connection is properly secured in accordance with the nature of the authentication scheme used. For example,
     999               services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer
     1000               Security", <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) prior to exchanging any credentials.
     1001            </p>
     1002         </div>
    9891003         <div id="auth.credentials.and.idle.clients">
    990             <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></h2>
    991             <p id="rfc.section.6.1.p.1">Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism
     1004            <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></h2>
     1005            <p id="rfc.section.6.2.p.1">Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism
    9921006               for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials
    9931007               are obtained or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of
    9941008               an authentication scheme definition.
    9951009            </p>
    996             <p id="rfc.section.6.1.p.2">Circumstances under which credential caching can interfere with the application's security model include but are not limited
     1010            <p id="rfc.section.6.2.p.2">Circumstances under which credential caching can interfere with the application's security model include but are not limited
    9971011               to:
    9981012            </p>
     
    10051019               </li>
    10061020            </ul>
    1007             <p id="rfc.section.6.1.p.3">User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials
     1021            <p id="rfc.section.6.2.p.3">User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials
    10081022               under user control.
    10091023            </p>
    10101024         </div>
    10111025         <div id="protection.spaces">
    1012             <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a href="#protection.spaces">Protection Spaces</a></h2>
    1013             <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
     1026            <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a href="#protection.spaces">Protection Spaces</a></h2>
     1027            <p id="rfc.section.6.3.p.1">Authentication schemes that solely rely on the "realm" mechanism for establishing a protection space will expose credentials
    10141028               to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the
    10151029               same authentication credentials for other resources on the same origin server. This makes it possible for a different resource
    10161030               to harvest authentication credentials for other resources.
    10171031            </p>
    1018             <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
     1032            <p id="rfc.section.6.3.p.2">This is of particular concern when an origin server hosts resources for multiple parties under the same canonical root URI
    10191033               (<a href="#protection.space" title="Protection Space (Realm)">Section&nbsp;2.2</a>). Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content
    10201034               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
     
    12941308                     </ul>
    12951309                  </li>
    1296                   <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.1</a>, <a href="#RFC5246"><b>8.2</b></a></li>
     1310                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">6.1</a>, <a href="#RFC5246"><b>8.2</b></a></li>
    12971311               </ul>
    12981312            </li>
  • 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.