Changeset 2573 for draft-ietf-httpbis/latest/p7-auth.html

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:

• draft-ietf-httpbis/latest/p7-auth.html (modified) (6 diffs)

draft-ietf-httpbis/latest/p7-auth.html

@@ -600 +600 @@
          </li>
          <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
-               <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>
-               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#protection.spaces">Protection Spaces</a></li>
+               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#confidentiality.of.credentials">Confidentiality of Credentials</a></li>
+               <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>
+               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#protection.spaces">Protection Spaces</a></li>
             </ul>
          </li>
@@ -653 +654 @@
                a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.
             </p>
-            <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
-               connection. Depending on the type of the authentication scheme, it therefore can be necessary to use a TLS-secured connection
-               ("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>).
-            </p>
-            <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.
+            <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.
             </p>
             <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>
@@ -665 +662 @@
   token68        = 1*( <a href="#imported.abnf" class="smpl">ALPHA</a> / <a href="#imported.abnf" class="smpl">DIGIT</a> /
                        "-" / "." / "_" / "~" / "+" / "/" ) *"=" 
-</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,
+</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,
                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>).
             </p>
-            <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.
-            </p>
-            <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.
+            <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.
+            </p>
+            <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.
             </p>
             <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> ) ]
-</pre><div class="note" id="rfc.section.2.1.p.9">
-               <p><b>Note:</b> Many clients fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported
+</pre><div class="note" id="rfc.section.2.1.p.8">
+               <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
                   schemes (such as "basic") first. 
                </p> 
             </div>
-            <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.
-            </p>
-            <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.
-            </p>
-            <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
+            <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.
+            </p>
+            <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.
+            </p>
+            <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
                in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
                the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the
-               user as appropriate.
+               user as appropriate. Transmission of credentials within header field values implies significant security considerations regarding
+               the confidentiality of the underlying connection, as described in <a href="#confidentiality.of.credentials" title="Confidentiality of Credentials">Section&nbsp;6.1</a>.
             </p>
             <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> ) ]
-</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)
+</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)
                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.
             </p>
-            <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
+            <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
                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.
             </p>
-            <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>).
-            </p>
-            <p id="rfc.section.2.1.p.17">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
+            <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>).
+            </p>
+            <p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
                can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields
                specifying authentication information. However, such additional mechanisms are not defined by this specification.
             </p>
-            <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>.
+            <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>.
             </p>
          </div>
@@ -987 +985 @@
             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.
          </p>
+         <div id="confidentiality.of.credentials">
+            <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>
+            <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,
+               each authentication scheme defines how the credentials are encoded prior to transmission. While this provides flexibility
+               for the development of future authentication schemes, it is inadequate for the protection of existing schemes that provide
+               no confidentiality on their own, or that do not sufficiently protect against replay attacks. Furthermore, if the server expects
+               credentials that are specific to each individual user, the exchange of those credentials will have the effect of identifying
+               that user even if the content within credentials remains confidential.
+            </p>
+            <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
+               of header fields. In other words, if a server limits access to authenticated users using this framework, the server needs
+               to ensure that the connection is properly secured in accordance with the nature of the authentication scheme used. For example,
+               services that depend on individual user authentication often require a connection to be secured with TLS ("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>) prior to exchanging any credentials.
+            </p>
+         </div>
          <div id="auth.credentials.and.idle.clients">
-            <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>
-            <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
+            <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>
+            <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
                for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials
                are obtained or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of
                an authentication scheme definition.
             </p>
-            <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
+            <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
                to: 
             </p>
@@ -1005 +1019 @@
                </li>
             </ul>
-            <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
+            <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
                under user control.
             </p>
          </div>
          <div id="protection.spaces">
-            <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a href="#protection.spaces">Protection Spaces</a></h2>
-            <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
+            <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a href="#protection.spaces">Protection Spaces</a></h2>
+            <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
                to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the
                same authentication credentials for other resources on the same origin server. This makes it possible for a different resource
                to harvest authentication credentials for other resources.
             </p>
-            <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
+            <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
                (<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
                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
@@ -1294 +1308 @@
                      </ul>
                   </li>
-                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">2.1</a>, <a href="#RFC5246"><b>8.2</b></a></li>
+                  <li><em>RFC5246</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5246.1">6.1</a>, <a href="#RFC5246"><b>8.2</b></a></li>
                </ul>
             </li>