Changeset 2571


Ignore:
Timestamp:
23/01/14 14:25:53 (6 years ago)
Author:
julian.reschke@…
Message:

mention that the auth related header fields by default are sent unsecured and hint at TLS (see #539)

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

Legend:

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

    r2568 r2571  
    653653               a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.
    654654            </p>
    655             <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.
     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.
    656660            </p>
    657661            <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>
     
    661665  token68        = 1*( <a href="#imported.abnf" class="smpl">ALPHA</a> / <a href="#imported.abnf" class="smpl">DIGIT</a> /
    662666                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
    663 </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,
     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,
    664668               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>).
    665669            </p>
    666             <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.
    667             </p>
    668             <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.
     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.
    669673            </p>
    670674            <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> ) ]
    671 </pre><div class="note" id="rfc.section.2.1.p.8">
     675</pre><div class="note" id="rfc.section.2.1.p.9">
    672676               <p><b>Note:</b> Many clients fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported
    673677                  schemes (such as "basic") first.
    674678               </p>
    675679            </div>
    676             <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.
    677             </p>
    678             <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.
    679             </p>
    680             <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
     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
    681685               in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
    682686               the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the
     
    684688            </p>
    685689            <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> ) ]
    686 </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)
     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)
    687691               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.
    688692            </p>
    689             <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
     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
    690694               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.
    691695            </p>
    692             <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>).
    693             </p>
    694             <p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
     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
    695699               can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields
    696700               specifying authentication information. However, such additional mechanisms are not defined by this specification.
    697701            </p>
    698             <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>.
     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>.
    699703            </p>
    700704         </div>
     
    10961100            </td>
    10971101         </tr>
     1102         <tr>
     1103            <td class="reference"><b id="RFC5246">[RFC5246]</b></td>
     1104            <td class="top">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>”, RFC&nbsp;5246, August&nbsp;2008.
     1105            </td>
     1106         </tr>
    10981107      </table>
    10991108      <div class="avoidbreak">
     
    11881197               </li>
    11891198               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/538">http://tools.ietf.org/wg/httpbis/trac/ticket/538</a>&gt;: "add 'stateless' to Abstract"
     1199               </li>
     1200               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/539">http://tools.ietf.org/wg/httpbis/trac/ticket/539</a>&gt;: "mention TLS vs plain text passwords or dict attacks?"
    11901201               </li>
    11911202               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/542">http://tools.ietf.org/wg/httpbis/trac/ticket/542</a>&gt;: "improve introduction of list rule"
     
    12831294                     </ul>
    12841295                  </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>
    12851297               </ul>
    12861298            </li>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r2568 r2571  
    174174</t>
    175175<t>
     176   Challenges and responses are transmitted in header field values, and thus
     177   can easily leak information when not using a secured connection. Depending
     178   on the type of the authentication scheme, it therefore can be necessary to
     179   use a TLS-secured connection ("Transport Layer Security", <xref target="RFC5246"/>).
     180</t>
     181<t>
    176182   Authentication parameters are name=value pairs, where the name token is
    177183   matched case-insensitively,
     
    10181024</reference>
    10191025
     1026<reference anchor='RFC5246'>
     1027   <front>
     1028      <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
     1029      <author initials='T.' surname='Dierks' fullname='T. Dierks'/>
     1030      <author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
     1031         <organization>RTFM, Inc.</organization>
     1032      </author>
     1033      <date year='2008' month='August' />
     1034   </front>
     1035   <seriesInfo name='RFC' value='5246' />
     1036</reference>
     1037
    10201038</references>
    10211039
     
    11541172    </t>
    11551173    <t>
     1174      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/539"/>:
     1175      "mention TLS vs plain text passwords or dict attacks?"
     1176    </t>
     1177    <t>
    11561178      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/542"/>:
    11571179      "improve introduction of list rule"
Note: See TracChangeset for help on using the changeset viewer.