Changeset 23


Ignore:
Timestamp:
12/09/13 10:22:10 (8 years ago)
Author:
julian.reschke@…
Message:

pull in actual scheme definition, and raise related issues; add change log

Location:
draft-ietf-httpauth-basicauth-update/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpauth-basicauth-update/latest/draft-ietf-httpauth-basicauth-update.html

    r22 r23  
    254254  margin-left: 0em;
    255255}
     256ul.ind, ul.ind ul {
     257  list-style: none;
     258  margin-left: 1.5em;
     259  padding-left: 0em;
     260  page-break-before: avoid;
     261}
     262ul.ind li {
     263  font-weight: bold;
     264  line-height: 200%;
     265  margin-left: 0em;
     266}
     267ul.ind li li {
     268  font-weight: normal;
     269  line-height: 150%;
     270  margin-left: 0em;
     271}
     272.avoidbreak {
     273  page-break-inside: avoid;
     274}
    256275.bcp14 {
    257276  font-style: normal;
     
    420439  }
    421440  @bottom-center {
    422        content: "Expires March 15, 2014";
     441       content: "Expires March 16, 2014";
    423442  }
    424443  @bottom-right {
     
    441460      <link rel="Author" href="#rfc.authors">
    442461      <link rel="Copyright" href="#rfc.copyrightnotice">
     462      <link rel="Index" href="#rfc.index">
    443463      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
    444464      <link rel="Chapter" title="2 Notational Conventions" href="#rfc.section.2">
     
    448468      <link rel="Chapter" title="6 Acknowledgements" href="#rfc.section.6">
    449469      <link rel="Chapter" href="#rfc.section.7" title="7 References">
     470      <link rel="Appendix" title="A Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.A">
    450471      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.599, 2013/08/29 10:34:28, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    451472      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    452473      <meta name="dct.creator" content="Reschke, J. F.">
    453474      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpauth-basicauth-update-latest">
    454       <meta name="dct.issued" scheme="ISO8601" content="2013-09-11">
     475      <meta name="dct.issued" scheme="ISO8601" content="2013-09-12">
    455476      <meta name="dct.abstract" content="This document defines the &#34;Basic&#34; Hypertext Transfer Protocol (HTTP) Authentication Scheme.">
    456477      <meta name="description" content="This document defines the &#34;Basic&#34; Hypertext Transfer Protocol (HTTP) Authentication Scheme.">
     
    470491               <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2617">2617</a> (if approved)
    471492               </td>
    472                <td class="right">September 11, 2013</td>
     493               <td class="right">September 12, 2013</td>
    473494            </tr>
    474495            <tr>
     
    477498            </tr>
    478499            <tr>
    479                <td class="left">Expires: March 15, 2014</td>
     500               <td class="left">Expires: March 16, 2014</td>
    480501               <td class="right"></td>
    481502            </tr>
     
    490511      <p>XML versions, latest edits and the issues list for this document are available from &lt;<a href="http://greenbytes.de/tech/webdav/#draft-ietf-httpauth-basicauth-update">http://greenbytes.de/tech/webdav/#draft-ietf-httpauth-basicauth-update</a>&gt;.
    491512      </p>
     513      <p>The changes in this draft are summarized in <a href="#changes.since.rfc2617" title="Since RFC 2617">Appendix&nbsp;A.1</a>.
     514      </p>
    492515      <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
    493516      <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
     
    499522         in progress”.
    500523      </p>
    501       <p>This Internet-Draft will expire on March 15, 2014.</p>
     524      <p>This Internet-Draft will expire on March 16, 2014.</p>
    502525      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    503526      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    529552         </li>
    530553         <li><a href="#rfc.authors">Author's Address</a></li>
     554         <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
     555               <li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.rfc2617">Since RFC 2617</a></li>
     556            </ul>
     557         </li>
     558         <li><a href="#rfc.index">Index</a></li>
    531559      </ul>
    532560      <h2 id="rfc.issues-list"><a href="#rfc.issues-list">Issues list</a></h2>
     
    549577               <td><a href="mailto:julian.reschke@greenbytes.de?subject=draft-ietf-httpauth-basicauth-update-latest,%20edit">julian.reschke@greenbytes.de</a></td>
    550578            </tr>
     579            <tr>
     580               <td><a href="#rfc.issue.enc">enc</a></td>
     581               <td>change</td>
     582               <td>open</td>
     583               <td>2013-09-12</td>
     584               <td><a href="mailto:julian.reschke@greenbytes.de?subject=draft-ietf-httpauth-basicauth-update-latest,%20enc">julian.reschke@greenbytes.de</a></td>
     585            </tr>
     586            <tr>
     587               <td><a href="#rfc.issue.upd">upd</a></td>
     588               <td>change</td>
     589               <td>open</td>
     590               <td>2013-09-12</td>
     591               <td><a href="mailto:julian.reschke@greenbytes.de?subject=draft-ietf-httpauth-basicauth-update-latest,%20upd">julian.reschke@greenbytes.de</a></td>
     592            </tr>
    551593         </tbody>
    552594      </table>
     
    582624      </p>
    583625      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="basic.authentication.scheme" href="#basic.authentication.scheme">The 'Basic' Authentication Scheme</a></h1>
    584       <p id="rfc.section.3.p.1"><span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: Copy from RFC 2617.]</span>
     626      <table class="openissue">
     627         <tr>
     628            <td colspan="3"><a id="rfc.issue.upd" class="open-issue">&nbsp;I&nbsp;</a>&nbsp;<em>upd</em>
     629               &nbsp;
     630               (type: change, status: open)
     631               
     632            </td>
     633         </tr>
     634         <tr>
     635            <td class="top"><a href="mailto:julian.reschke@greenbytes.de?subject=draft-ietf-httpauth-basicauth-update-latest,%20upd"><i>julian.reschke@greenbytes.de</i></a></td>
     636            <td class="topnowrap">2013-09-12</td>
     637            <td class="top">
     638               Update the definition to reflect underlying changes (RFC2616-&gt;httpbis,
     639               RFC2396-&gt;2616, other references).
     640               
     641            </td>
     642         </tr>
     643      </table>
     644      <table class="openissue">
     645         <tr>
     646            <td colspan="3"><a id="rfc.issue.enc" class="open-issue">&nbsp;I&nbsp;</a>&nbsp;<em>enc</em>
     647               &nbsp;
     648               (type: change, status: open)
     649               
     650            </td>
     651         </tr>
     652         <tr>
     653            <td class="top"><a href="mailto:julian.reschke@greenbytes.de?subject=draft-ietf-httpauth-basicauth-update-latest,%20enc"><i>julian.reschke@greenbytes.de</i></a></td>
     654            <td class="topnowrap">2013-09-12</td>
     655            <td class="top">
     656               Fix the encoding issue, by pulling in draft-ietf-httpauth-basicauth-enc.
     657               
     658            </td>
     659         </tr>
     660      </table>
     661      <p id="rfc.section.3.p.1">The "basic" authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password
     662         for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms
     663         on that server. The server will service the request only if it can validate the user-ID and password for the protection space
     664         of the Request-URI. There are no optional authentication parameters.
     665      </p>
     666      <p id="rfc.section.3.p.2">For Basic, the framework above is utilized as follows:</p>
     667      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.c.1"></span><span id="rfc.iref.c.2"></span>   challenge   = "Basic" realm
     668   credentials = "Basic" basic-credentials
     669</pre><p id="rfc.section.3.p.4">Upon receipt of an unauthorized request for a URI within the protection space, the origin server <em class="bcp14">MAY</em> respond with a challenge like the following:
     670      </p>
     671      <div id="rfc.figure.u.2"></div><pre class="text">   WWW-Authenticate: Basic realm="WallyWorld"
     672</pre><p id="rfc.section.3.p.6">where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI. A proxy may respond
     673         with the same challenge using the Proxy-Authenticate header field.
     674      </p>
     675      <p id="rfc.section.3.p.7">To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a
     676         base64 <a href="#RFC2396"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> encoded string in the credentials.
     677      </p>
     678      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.b.1"></span><span id="rfc.iref.b.2"></span><span id="rfc.iref.u.1"></span><span id="rfc.iref.u.2"></span><span id="rfc.iref.p.1"></span>   basic-credentials = base64-user-pass
     679   base64-user-pass  = &lt;base64 <a href="#RFC2045"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> encoding of user-pass,
     680                    except not limited to 76 char/line&gt;
     681   user-pass   = userid ":" password
     682   userid      = *&lt;TEXT excluding ":"&gt;
     683   password    = *TEXT
     684</pre><p id="rfc.section.3.p.9">Userids might be case sensitive.</p>
     685      <p id="rfc.section.3.p.10">If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:</p>
     686      <div id="rfc.figure.u.4"></div><pre class="text">   Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
     687</pre><p id="rfc.section.3.p.12">A client <em class="bcp14">SHOULD</em> assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are
     688         within the protection space specified by the Basic realm value of the current challenge. A client <em class="bcp14">MAY</em> preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another
     689         challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the
     690         Proxy-Authorization header field without receiving another challenge from the proxy server. See <a href="#security.considerations" title="Security Considerations">Section&nbsp;4</a> for security considerations associated with Basic authentication.
    585691      </p>
    586692      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
     
    631737      <table>
    632738         <tr>
     739            <td class="reference"><b id="RFC2045">[RFC2045]</b></td>
     740            <td class="top">Freed, N. and N. Borenstein, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC&nbsp;2045, November&nbsp;1996.
     741            </td>
     742         </tr>
     743         <tr>
    633744            <td class="reference"><b id="RFC2119">[RFC2119]</b></td>
    634745            <td class="top">Bradner, S., “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
     746            </td>
     747         </tr>
     748         <tr>
     749            <td class="reference"><b id="RFC2396">[RFC2396]</b></td>
     750            <td class="top">Berners-Lee, T., Fielding, R., and L. Masinter, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.
    635751            </td>
    636752         </tr>
     
    664780         <address><span class="vcardline"><b>Julian F. Reschke</b></span><span class="vcardline">greenbytes GmbH</span><span class="vcardline">Hafenweg 16</span><span class="vcardline">Muenster, NW&nbsp;48155</span><span class="vcardline">Germany</span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></span></address>
    665781      </div>
     782      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
     783      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.since.rfc2617" href="#changes.since.rfc2617">Since RFC 2617</a></h2>
     784      <p id="rfc.section.A.1.p.1">This draft acts as a baseline for tracking subsequent changes to the specification. As such, it extracts the definition of
     785         "Basic", plus the related Security Considerations, and also adds the IANA registration of the scheme. Changes to the actual
     786         definition will be made in subsequent drafts.
     787      </p>
     788      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
     789      <p class="noprint"><a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.U">U</a>
     790      </p>
     791      <div class="print2col">
     792         <ul class="ind">
     793            <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul>
     794                  <li><tt>base64-user-pass</tt>&nbsp;&nbsp;<a href="#rfc.iref.b.2"><b>3</b></a></li>
     795                  <li><tt>basic-credentials</tt>&nbsp;&nbsp;<a href="#rfc.iref.b.1"><b>3</b></a></li>
     796               </ul>
     797            </li>
     798            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
     799                  <li>challenge&nbsp;&nbsp;<a href="#rfc.iref.c.1">3</a></li>
     800                  <li>credentials&nbsp;&nbsp;<a href="#rfc.iref.c.2">3</a></li>
     801               </ul>
     802            </li>
     803            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
     804                  <li><tt>password</tt>&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>3</b></a></li>
     805               </ul>
     806            </li>
     807            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
     808                  <li><tt>user-pass</tt>&nbsp;&nbsp;<a href="#rfc.iref.u.1"><b>3</b></a></li>
     809                  <li><tt>userid</tt>&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>3</b></a></li>
     810               </ul>
     811            </li>
     812         </ul>
     813      </div>
    666814   </body>
    667815</html>
  • draft-ietf-httpauth-basicauth-update/latest/draft-ietf-httpauth-basicauth-update.xml

    r22 r23  
    6666      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-ietf-httpauth-basicauth-update"/>.
    6767    </t>
    68     <!--<t>
    69       The changes in this draft are summarized in <xref target="changes.since.00"/>.
    70     </t>-->
     68    <t>
     69      The changes in this draft are summarized in <xref target="changes.since.rfc2617"/>.
     70    </t>
    7171  </note>
    7272  </front>
     
    111111
    112112<section title="The 'Basic' Authentication Scheme" anchor="basic.authentication.scheme">
    113 <t>
    114   <cref>Copy from RFC 2617.</cref>
     113<ed:issue name="upd" type="change" status="open">
     114  <ed:item entered-by="julian.reschke@greenbytes.de" date="2013-09-12">
     115    Update the definition to reflect underlying changes (RFC2616->httpbis,
     116    RFC2396->2616, other references).
     117  </ed:item>
     118</ed:issue>
     119<ed:issue name="enc" type="change" status="open">
     120  <ed:item entered-by="julian.reschke@greenbytes.de" date="2013-09-12">
     121    Fix the encoding issue, by pulling in draft-ietf-httpauth-basicauth-enc.
     122  </ed:item>
     123</ed:issue>
     124<t>
     125   The "basic" authentication scheme is based on the model that the
     126   client must authenticate itself with a user-ID and a password for
     127   each realm.  The realm value should be considered an opaque string
     128   which can only be compared for equality with other realms on that
     129   server. The server will service the request only if it can validate
     130   the user-ID and password for the protection space of the Request-URI.
     131   There are no optional authentication parameters.
     132</t>
     133<t>
     134   For Basic, the framework above is utilized as follows:
     135</t>
     136<figure><artwork type="abnf2616"><iref item="challenge"/><iref item="credentials"/>
     137   challenge   = "Basic" realm
     138   credentials = "Basic" basic-credentials
     139</artwork></figure>
     140<t>
     141   Upon receipt of an unauthorized request for a URI within the
     142   protection space, the origin server &MAY; respond with a challenge like
     143   the following:
     144</t>
     145<figure><artwork type="example">
     146   WWW-Authenticate: Basic realm="WallyWorld"
     147</artwork></figure>
     148<t>
     149   where "WallyWorld" is the string assigned by the server to identify
     150   the protection space of the Request-URI. A proxy may respond with the
     151   same challenge using the Proxy-Authenticate header field.
     152</t>
     153<t>
     154   To receive authorization, the client sends the userid and password,
     155   separated by a single colon (":") character, within a base64 <xref target="RFC2396"/>
     156   encoded string in the credentials.
     157</t>
     158<figure><artwork type="abnf2616"><iref item="basic-credentials" primary="true"
     159/><iref item="base64-user-pass" primary="true"
     160/><iref item="user-pass" primary="true"
     161/><iref item="userid" primary="true"
     162/><iref item="password" primary="true"/>
     163   basic-credentials = base64-user-pass
     164   base64-user-pass  = &lt;base64 <xref target="RFC2045"/> encoding of user-pass,
     165                    except not limited to 76 char/line>
     166   user-pass   = userid ":" password
     167   userid      = *&lt;TEXT excluding ":">
     168   password    = *TEXT
     169</artwork></figure>
     170<t>
     171   Userids might be case sensitive.
     172</t>
     173<t>
     174   If the user agent wishes to send the userid "Aladdin" and password
     175   "open sesame", it would use the following header field:
     176</t>
     177<figure><artwork type="example">
     178   Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
     179</artwork></figure>
     180<t>
     181   A client &SHOULD; assume that all paths at or deeper than the depth of
     182   the last symbolic element in the path field of the Request-URI also
     183   are within the protection space specified by the Basic realm value of
     184   the current challenge. A client &MAY; preemptively send the
     185   corresponding Authorization header with requests for resources in
     186   that space without receipt of another challenge from the server.
     187   Similarly, when a client sends a request to a proxy, it may reuse a
     188   userid and password in the Proxy-Authorization header field without
     189   receiving another challenge from the proxy server. See <xref target="security.considerations"/> for
     190   security considerations associated with Basic authentication.
    115191</t>
    116192</section> 
     
    201277<references title="Normative References">
    202278 
     279  <reference anchor='RFC2045'>
     280    <front>
     281      <title abbrev='Internet Message Bodies'>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
     282      <author initials='N.' surname='Freed' fullname='Ned Freed'/>
     283      <author initials='N.S.' surname='Borenstein' fullname='Nathaniel S. Borenstein'/>
     284      <date year='1996' month='November' />
     285    </front>
     286    <seriesInfo name='RFC' value='2045' />
     287  </reference>
     288
    203289  <reference anchor="RFC2119">
    204290    <front>
     
    209295    <seriesInfo name="BCP" value="14"/>
    210296    <seriesInfo name="RFC" value="2119"/>
     297  </reference>
     298
     299  <reference anchor="RFC2396">
     300    <front>
     301      <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
     302      <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"/>
     303      <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"/>
     304      <author initials="L." surname="Masinter" fullname="Larry Masinter"/>
     305      <date month="August" year="1998"/>
     306    </front>
     307    <seriesInfo name="RFC" value="2396"/>
    211308  </reference>
    212309
     
    261358
    262359</references>
     360
     361<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
     362<section title="Since RFC 2617" anchor="changes.since.rfc2617">
     363<t>
     364  This draft acts as a baseline for tracking subsequent changes to the
     365  specification. As such, it extracts the definition of "Basic", plus the related Security
     366  Considerations, and also adds the IANA registration of the scheme.
     367  Changes to the actual definition will be made in subsequent drafts.
     368</t>
     369</section>
     370</section>
     371
    263372  </back>
    264 
    265373</rfc>
Note: See TracChangeset for help on using the changeset viewer.