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.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>
Note: See TracChangeset for help on using the changeset viewer.