Changeset 2455


Ignore:
Timestamp:
Oct 31, 2013, 5:59:09 AM (6 years ago)
Author:
julian.reschke@…
Message:

rephrase parsing considerations for *-Authenticate, also have them only once (#516)

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

Legend:

Unmodified
Added
Removed

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

    r2452 r2455  
    445445  }
    446446  @bottom-center {
    447        content: "Expires May 3, 2014";
     447       content: "Expires May 4, 2014";
    448448  }
    449449  @bottom-right {
    … …  
    485485      <meta name="dct.creator" content="Reschke, J. F.">
    486486      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    487       <meta name="dct.issued" scheme="ISO8601" content="2013-10-30">
     487      <meta name="dct.issued" scheme="ISO8601" content="2013-10-31">
    488488      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    489489      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
    … …  
    513513            <tr>
    514514               <td class="left">Intended status: Standards Track</td>
    515                <td class="right">October 30, 2013</td>
     515               <td class="right">October 31, 2013</td>
    516516            </tr>
    517517            <tr>
    518                <td class="left">Expires: May 3, 2014</td>
     518               <td class="left">Expires: May 4, 2014</td>
    519519               <td class="right"></td>
    520520            </tr>
    … …  
    543543            in progress”.
    544544         </p>
    545          <p>This Internet-Draft will expire on May 3, 2014.</p>
     545         <p>This Internet-Draft will expire on May 4, 2014.</p>
    546546      </div>
    547547      <div id="rfc.copyrightnotice">
    … …  
    665665            <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> ) ]
    666666</pre><div class="note" id="rfc.section.2.1.p.8">
    667                <p><b>Note:</b> User agents will need to take special care in parsing the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field values because they can contain more than one challenge, or if more than one of each is provided, since the contents
    668                   of a challenge can itself contain a comma-separated list of authentication parameters.
    669                </p>
    670             </div>
    671             <div class="note" id="rfc.section.2.1.p.9">
    672667               <p><b>Note:</b> Many clients fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported
    673668                  schemes (such as "basic") first.
    674669               </p>
    675670            </div>
    676             <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.
    677             </p>
    678             <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.
    679             </p>
    680             <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
     671            <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.
     672            </p>
     673            <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.
     674            </p>
     675            <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
    681676               in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting
    682677               the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the
    … …  
    684679            </p>
    685680            <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.14">Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password)
     681</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)
    687682               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.
    688683            </p>
    689             <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
     684            <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
    690685               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.
    691686            </p>
    692             <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>).
    693             </p>
    694             <p id="rfc.section.2.1.p.17">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
     687            <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>).
     688            </p>
     689            <p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
    695690               can be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying
    696691               authentication information. However, such additional mechanisms are not defined by this specification.
    697692            </p>
    698             <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>.
     693            <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>.
    699694            </p>
    700695         </div>
    … …  
    795790            </p>
    796791            <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    797 </pre><p id="rfc.section.4.4.p.4">User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one
    798                challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a
    799                comma-separated list of authentication parameters.
     792</pre><p id="rfc.section.4.4.p.4">User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and
     793               each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur
     794               multiple times.
    800795            </p>
    801796            <div id="rfc.figure.u.8"></div>
    … …  
    11611156               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/513">http://tools.ietf.org/wg/httpbis/trac/ticket/513</a>&gt;: "APPSDIR review of draft-ietf-httpbis-p7-auth-24"
    11621157               </li>
     1158               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/516">http://tools.ietf.org/wg/httpbis/trac/ticket/516</a>&gt;: "note about WWW-A parsing potentially misleading"
     1159               </li>
    11631160            </ul>
    11641161            <p id="rfc.section.D.1.p.2">Partly resolved issues: </p>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r2452 r2455  
    204204<x:note>
    205205  <t>
    206      &Note; User agents will need to take special care in parsing the
    207      <x:ref>WWW-Authenticate</x:ref> and <x:ref>Proxy-Authenticate</x:ref>
    208      header field values because they can contain more than one challenge, or
    209      if more than one of each is provided, since the contents of a challenge
    210      can itself contain a comma-separated list of authentication parameters.
    211   </t>
    212 </x:note>
    213 <x:note>
    214   <t>
    215206     &Note; Many clients fail to parse challenges containing unknown
    216207     schemes. A workaround for this problem is to list well-supported schemes
    … …  
    457448</artwork></figure>
    458449<t>
    459    User agents are advised to take special care in parsing the WWW-Authenticate
    460    field value as it might contain more than one challenge,
    461    or if more than one WWW-Authenticate header field is provided, the
    462    contents of a challenge itself can contain a comma-separated list of
    463    authentication parameters.
     450   User agents are advised to take special care in parsing the field value, as
     451   it might contain more than one challenge, and each challenge can contain a
     452   comma-separated list of authentication parameters. Furthermore, the header
     453   field itself can occur multiple times.
    464454</t>
    465455<figure>
    … …  
    11051095      "APPSDIR review of draft-ietf-httpbis-p7-auth-24"
    11061096    </t>
     1097    <t>
     1098      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/516"/>:
     1099      "note about WWW-A parsing potentially misleading"
     1100    </t>
    11071101  </list>
    11081102</t>
Note: See TracChangeset for help on using the changeset viewer.