Changeset 30


Ignore:
Timestamp:
25/09/13 13:02:15 (8 years ago)
Author:
julian.reschke@…
Message:

Update to latest version of rfc2629.xslt

Files:
2 edited

Legend:

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

    r18 r30  
    108108body {
    109109  color: black;
    110   font-family: verdana, helvetica, arial, sans-serif;
    111   font-size: 10pt;
     110  font-family: cambria, helvetica, arial, sans-serif;
     111  font-size: 11pt;
    112112  margin-right: 2em;
    113113}
     
    134134}
    135135h1 {
    136   font-size: 14pt;
     136  font-size: 130%;
    137137  line-height: 21pt;
    138138  page-break-after: avoid;
     
    141141  page-break-before: always;
    142142}
    143 h1 a {
    144   color: #333333;
    145 }
    146143h2 {
    147   font-size: 12pt;
     144  font-size: 120%;
    148145  line-height: 15pt;
    149146  page-break-after: avoid;
    150147}
    151148h3, h4, h5, h6 {
    152   font-size: 10pt;
     149  font-size: 110%;
    153150  page-break-after: avoid;
    154151}
    155 h2 a, h3 a, h4 a, h5 a, h6 a {
     152h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    156153  color: black;
    157154}
     
    211208  border-spacing: 1px;
    212209  width: 95%;
    213   font-size: 10pt;
     210  font-size: 11pt;
    214211  color: white;
    215212}
     
    244241  line-height: 150%;
    245242  font-weight: bold;
    246   font-size: 10pt;
    247243  margin-left: 0em;
    248244}
     
    250246  line-height: normal;
    251247  font-weight: normal;
    252   font-size: 9pt;
     248  font-size: 10pt;
    253249  margin-left: 0em;
    254250}
     
    258254ul p {
    259255  margin-left: 0em;
     256}
     257.title, .filename, h1, h2, h3, h4 {
     258  font-family: candara, helvetica, arial, sans-serif;
     259}
     260samp, tt, code, pre {
     261  font: consolas, monospace;
    260262}
    261263.bcp14 {
     
    278280  font-weight: bold;
    279281  text-align: center;
    280   font-size: 9pt;
     282  font-size: 10pt;
    281283}
    282284.filename {
    283285  color: #333333;
     286  font-size: 75%;
    284287  font-weight: bold;
    285   font-size: 12pt;
    286288  line-height: 21pt;
    287289  text-align: center;
     
    297299}
    298300.title {
    299   color: #990000;
    300   font-size: 18pt;
     301  color: green;
     302  font-size: 150%;
    301303  line-height: 18pt;
    302304  font-weight: bold;
     
    304306  margin-top: 36pt;
    305307}
    306 .vcardline {
    307   display: block;
    308 }
    309308.warning {
    310   font-size: 14pt;
     309  font-size: 130%;
    311310  background-color: yellow;
    312311}
     
    331330  border: solid;
    332331  border-width: 1px;
    333   font-size: 7pt;
     332  font-size: 8pt;
    334333}
    335334.closed-issue {
     
    393392    background-color: white;
    394393    vertical-align: top;
    395     font-size: 12pt;
     394    font-size: 110%;
    396395  }
    397396
     
    425424  }
    426425  @bottom-center {
    427        content: "Expires March 15, 2014";
     426       content: "Expires March 29, 2014";
    428427  }
    429428  @bottom-right {
     
    457456      <link rel="Appendix" title="B FAQ (to be removed by RFC Editor before publication)" href="#rfc.section.B">
    458457      <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C">
    459       <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/">
     458      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.603, 2013/09/18 20:22:25, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    460459      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    461460      <meta name="dct.creator" content="Reschke, J. F.">
    462461      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpauth-basicauth-enc-latest">
    463       <meta name="dct.issued" scheme="ISO8601" content="2013-09-11">
     462      <meta name="dct.issued" scheme="ISO8601" content="2013-09-25">
    464463      <meta name="dct.abstract" content="The &#34;Basic&#34; authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has led to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character repertoire, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to &#34;Basic&#34;, specifying the server's character encoding scheme expectation, using a new authentication scheme parameter.">
    465464      <meta name="description" content="The &#34;Basic&#34; authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has led to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character repertoire, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to &#34;Basic&#34;, specifying the server's character encoding scheme expectation, using a new authentication scheme parameter.">
     
    479478               <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2617">2617</a> (if approved)
    480479               </td>
    481                <td class="right">September 11, 2013</td>
     480               <td class="right">September 25, 2013</td>
    482481            </tr>
    483482            <tr>
     
    486485            </tr>
    487486            <tr>
    488                <td class="left">Expires: March 15, 2014</td>
     487               <td class="left">Expires: March 29, 2014</td>
    489488               <td class="right"></td>
    490489            </tr>
     
    508507      <p>The changes in this draft are summarized in <a href="#changes.since.00" title="Since draft-ietf-httpauth-basicauth-enc-00">Appendix&nbsp;C.10</a>.
    509508      </p>
    510       <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
    511       <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
    512       <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
    513          working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
    514       </p>
    515       <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    516          documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    517          in progress”.
    518       </p>
    519       <p>This Internet-Draft will expire on March 15, 2014.</p>
    520       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    521       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    522       <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
    523          and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
    524          text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
    525          BSD License.
    526       </p>
     509      <div id="rfc.status">
     510         <h1><a href="#rfc.status">Status of This Memo</a></h1>
     511         <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
     512         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
     513            working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
     514         </p>
     515         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
     516            documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
     517            in progress”.
     518         </p>
     519         <p>This Internet-Draft will expire on March 29, 2014.</p>
     520      </div>
     521      <div id="rfc.copyrightnotice">
     522         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     523         <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     524         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
     525            and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
     526            text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
     527            BSD License.
     528         </p>
     529      </div>
    527530      <hr class="noprint">
    528531      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
     
    632635         </tr>
    633636      </table>
    634       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    635       <p id="rfc.section.1.p.1">The "Basic" authentication scheme defined in <a href="http://tools.ietf.org/html/rfc2617#section-2">Section 2</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> does not properly define how to treat non-ASCII characters (<a href="#USASCII"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>): it uses the Base64 (<a href="#RFC4648"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>, <a href="http://tools.ietf.org/html/rfc4648#section-4">Section 4</a>) encoding of the concatenation of username, separator character, and password without stating which character encoding scheme
    636          to use.
    637       </p>
    638       <p id="rfc.section.1.p.2">This has led to a situation where user agent implementations disagree, and servers make different assumptions based on the
    639          locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character repertoire
    640          (<a href="#USASCII"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>, <a href="#ISO-8859-1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>), and even less interoperability for any characters beyond that.
    641       </p>
    642       <p id="rfc.section.1.p.3">This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding scheme expectation,
    643          using a new auth-param for use in the Proxy-Authenticate and WWW-Authenticate header fields, as defined in <a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>.
    644       </p>
    645       <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;Notational Conventions
    646       </h1>
    647       <p id="rfc.section.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    648          in this document are to be interpreted as described in <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    649       </p>
    650       <p id="rfc.section.2.p.2">The terms (character) <dfn>repertoire</dfn> and <dfn>character encoding scheme</dfn> are defined in <a href="http://tools.ietf.org/html/rfc6365#section-2">Section 2</a> of <a href="#RFC6365"><cite title="Terminology Used in Internationalization in the IETF">[RFC6365]</cite></a>.
    651       </p>
    652       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="charset" href="#charset">The 'charset' auth-param</a></h1>
    653       <p id="rfc.section.3.p.1">In challenges, servers <em class="bcp14">MAY</em> use the "charset" authentication parameter (case-insensitive) to indicate the character encoding scheme they expect the user
    654          agent to use when generating "user-pass" (a sequence of octets) from "userid" and "password" (<a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="http://tools.ietf.org/html/rfc2617#section-2">Section 2</a>).
    655       </p>
    656       <p id="rfc.section.3.p.2">The only allowed value is "UTF-8", to be matched case-insensitively (see <a href="#RFC2978"><cite title="IANA Charset Registration Procedures">[RFC2978]</cite></a>, <a href="http://tools.ietf.org/html/rfc2978#section-2.3">Section 2.3</a>), indicating that the server expects the UTF-8 character encoding scheme to be used (<a href="#RFC3629"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>).
    657       </p>
    658       <p id="rfc.section.3.p.3">Other values are reserved for future use.</p>
    659       <div class="note" id="rfc.section.3.p.4">
    660          <p><b>Note:</b> The 'charset' parameter cannot be included when sending credentials (e.g. in the Authorization or Proxy-Authorization header
    661             fields), as the "Basic" scheme uses a single token for credentials ('token68' syntax), not a parameter list ('#auth-param'
    662             syntax); see <a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-23#section-2.1">Section 2.1</a> of <a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>.
    663          </p>
    664       </div>
    665       <div class="note" id="rfc.section.3.p.5">
    666          <p><b>Note:</b> The name 'charset' has been chosen for consistency with <a href="http://tools.ietf.org/html/rfc2831#section-2.1.1">Section 2.1.1</a> of <a href="#RFC2831"><cite title="Using Digest Authentication as a SASL Mechanism">[RFC2831]</cite></a>. A better name would have been 'accept-charset', as it is not about the message it appears in, but the server's expectation.
    667          </p>
    668       </div>
    669       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="example" href="#example">Example</a></h1>
    670       <div id="rfc.figure.u.1"></div>
    671       <p>In the example below, the server prompts for authentication in the "foo" realm, using Basic authentication, with a preference
    672          for the UTF-8 character encoding scheme:
    673       </p><pre class="text">WWW-Authenticate: Basic realm="foo", charset="UTF-8"
     637      <div id="introduction">
     638         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1>
     639         <p id="rfc.section.1.p.1">The "Basic" authentication scheme defined in <a href="http://tools.ietf.org/html/rfc2617#section-2">Section 2</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> does not properly define how to treat non-ASCII characters (<a href="#USASCII"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>): it uses the Base64 (<a href="#RFC4648"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>, <a href="http://tools.ietf.org/html/rfc4648#section-4">Section 4</a>) encoding of the concatenation of username, separator character, and password without stating which character encoding scheme
     640            to use.
     641         </p>
     642         <p id="rfc.section.1.p.2">This has led to a situation where user agent implementations disagree, and servers make different assumptions based on the
     643            locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character repertoire
     644            (<a href="#USASCII"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>, <a href="#ISO-8859-1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>), and even less interoperability for any characters beyond that.
     645         </p>
     646         <p id="rfc.section.1.p.3">This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding scheme expectation,
     647            using a new auth-param for use in the Proxy-Authenticate and WWW-Authenticate header fields, as defined in <a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>.
     648         </p>
     649      </div>
     650      <div>
     651         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;Notational Conventions
     652         </h1>
     653         <p id="rfc.section.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     654            in this document are to be interpreted as described in <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
     655         </p>
     656         <p id="rfc.section.2.p.2">The terms (character) <dfn>repertoire</dfn> and <dfn>character encoding scheme</dfn> are defined in <a href="http://tools.ietf.org/html/rfc6365#section-2">Section 2</a> of <a href="#RFC6365"><cite title="Terminology Used in Internationalization in the IETF">[RFC6365]</cite></a>.
     657         </p>
     658      </div>
     659      <div id="charset">
     660         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#charset">The 'charset' auth-param</a></h1>
     661         <p id="rfc.section.3.p.1">In challenges, servers <em class="bcp14">MAY</em> use the "charset" authentication parameter (case-insensitive) to indicate the character encoding scheme they expect the user
     662            agent to use when generating "user-pass" (a sequence of octets) from "userid" and "password" (<a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="http://tools.ietf.org/html/rfc2617#section-2">Section 2</a>).
     663         </p>
     664         <p id="rfc.section.3.p.2">The only allowed value is "UTF-8", to be matched case-insensitively (see <a href="#RFC2978"><cite title="IANA Charset Registration Procedures">[RFC2978]</cite></a>, <a href="http://tools.ietf.org/html/rfc2978#section-2.3">Section 2.3</a>), indicating that the server expects the UTF-8 character encoding scheme to be used (<a href="#RFC3629"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>).
     665         </p>
     666         <p id="rfc.section.3.p.3">Other values are reserved for future use.</p>
     667         <div class="note" id="rfc.section.3.p.4">
     668            <p><b>Note:</b> The 'charset' parameter cannot be included when sending credentials (e.g. in the Authorization or Proxy-Authorization header
     669               fields), as the "Basic" scheme uses a single token for credentials ('token68' syntax), not a parameter list ('#auth-param'
     670               syntax); see <a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-23#section-2.1">Section 2.1</a> of <a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>.
     671            </p>
     672         </div>
     673         <div class="note" id="rfc.section.3.p.5">
     674            <p><b>Note:</b> The name 'charset' has been chosen for consistency with <a href="http://tools.ietf.org/html/rfc2831#section-2.1.1">Section 2.1.1</a> of <a href="#RFC2831"><cite title="Using Digest Authentication as a SASL Mechanism">[RFC2831]</cite></a>. A better name would have been 'accept-charset', as it is not about the message it appears in, but the server's expectation.
     675            </p>
     676         </div>
     677      </div>
     678      <div id="example">
     679         <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#example">Example</a></h1>
     680         <div id="rfc.figure.u.1"></div>
     681         <p>In the example below, the server prompts for authentication in the "foo" realm, using Basic authentication, with a preference
     682            for the UTF-8 character encoding scheme:
     683         </p><pre class="text">WWW-Authenticate: Basic realm="foo", charset="UTF-8"
    674684</pre><p>Note that the parameter value can be either a token or a quoted string; in this case the server chose to use the quoted-string
    675          notation.
    676       </p>
    677       <p id="rfc.section.4.p.2">The user's name is "test", and his password is the string "123" followed by the Unicode character U+00A3 (POUND SIGN). Following <a href="http://tools.ietf.org/html/rfc2617#section-1.2">Section 1.2</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, but using the character encoding scheme UTF-8, the user-pass, converted to a sequence of octets, is:
    678       </p>
    679       <div id="rfc.figure.u.2"></div><pre class="text"> 't' 'e' 's' 't' ':' '1' '2' '3' pound
     685            notation.
     686         </p>
     687         <p id="rfc.section.4.p.2">The user's name is "test", and his password is the string "123" followed by the Unicode character U+00A3 (POUND SIGN). Following <a href="http://tools.ietf.org/html/rfc2617#section-1.2">Section 1.2</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, but using the character encoding scheme UTF-8, the user-pass, converted to a sequence of octets, is:
     688         </p>
     689         <div id="rfc.figure.u.2"></div><pre class="text"> 't' 'e' 's' 't' ':' '1' '2' '3' pound
    680690 74  65  73  74  3A  31  32  33  C2  A3 
    681691</pre><p id="rfc.section.4.p.4">Encoding this octet sequence in Base64 (<a href="#RFC4648"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>, <a href="http://tools.ietf.org/html/rfc4648#section-4">Section 4</a>) yields:
    682       </p>
    683       <div id="rfc.figure.u.3"></div><pre class="text">  dGVzdDoxMjPCow==
     692         </p>
     693         <div id="rfc.figure.u.3"></div><pre class="text">  dGVzdDoxMjPCow==
    684694</pre><p id="rfc.section.4.p.6">Thus the Authorization header field would be:</p>
    685       <div id="rfc.figure.u.4"></div><pre class="text">  Authorization: Basic dGVzdDoxMjPCow==
     695         <div id="rfc.figure.u.4"></div><pre class="text">  Authorization: Basic dGVzdDoxMjPCow==
    686696</pre><p id="rfc.section.4.p.8">Or, for proxy authentication:</p>
    687       <div id="rfc.figure.u.5"></div><pre class="text">  Proxy-Authorization: Basic dGVzdDoxMjPCow==
    688 </pre><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    689       <p id="rfc.section.5.p.1">This document does not introduce any new security considerations beyond those defined for the "Basic" authentication scheme
    690          (<a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="http://tools.ietf.org/html/rfc2617#section-4">Section 4</a>), and those applicable to the handling of UTF-8 (<a href="#RFC3629"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>, <a href="http://tools.ietf.org/html/rfc3629#section-10">Section 10</a>).
    691       </p>
    692       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1>
    693       <p id="rfc.section.6.p.1">There are no IANA Considerations related to this specification.</p>
    694       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;Acknowledgements
    695       </h1>
    696       <p id="rfc.section.7.p.1">The internationalisation problem has been reported as a Mozilla bug back in the year 2000 (see &lt;<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=41489">https://bugzilla.mozilla.org/show_bug.cgi?id=41489</a>&gt; and also the more recent &lt;<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=656213">https://bugzilla.mozilla.org/show_bug.cgi?id=656213</a>&gt;). It was Andrew Clover's idea to address it using a new auth-param.
    697       </p>
    698       <p id="rfc.section.7.p.2">Thanks to Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Manger, Yaron Sheffer, and Martin Thomson for providing
    699          feedback on this document.
    700       </p>
     697         <div id="rfc.figure.u.5"></div><pre class="text">  Proxy-Authorization: Basic dGVzdDoxMjPCow==
     698</pre></div>
     699      <div id="security.considerations">
     700         <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1>
     701         <p id="rfc.section.5.p.1">This document does not introduce any new security considerations beyond those defined for the "Basic" authentication scheme
     702            (<a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="http://tools.ietf.org/html/rfc2617#section-4">Section 4</a>), and those applicable to the handling of UTF-8 (<a href="#RFC3629"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>, <a href="http://tools.ietf.org/html/rfc3629#section-10">Section 10</a>).
     703         </p>
     704      </div>
     705      <div id="iana.considerations">
     706         <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1>
     707         <p id="rfc.section.6.p.1">There are no IANA Considerations related to this specification.</p>
     708      </div>
     709      <div>
     710         <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;Acknowledgements
     711         </h1>
     712         <p id="rfc.section.7.p.1">The internationalisation problem has been reported as a Mozilla bug back in the year 2000 (see &lt;<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=41489">https://bugzilla.mozilla.org/show_bug.cgi?id=41489</a>&gt; and also the more recent &lt;<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=656213">https://bugzilla.mozilla.org/show_bug.cgi?id=656213</a>&gt;). It was Andrew Clover's idea to address it using a new auth-param.
     713         </p>
     714         <p id="rfc.section.7.p.2">Thanks to Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Manger, Yaron Sheffer, and Martin Thomson for providing
     715            feedback on this document.
     716         </p>
     717      </div>
    701718      <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
    702719      </h1>
     
    764781      <div class="avoidbreak">
    765782         <h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
    766          <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>
    767       </div>
    768       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Deployment Considerations
    769       </h1>
    770       <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;User Agents
    771       </h2>
    772       <p id="rfc.section.A.1.p.1">User agents not implementing this specification should continue to work as before, ignoring the new parameter.</p>
    773       <p id="rfc.section.A.1.p.2">User agents which already default to the UTF-8 encoding implement this specification by definition. Note that some user agents
    774          also have different defaults depending on whether the request originates from page navigation as opposed to a script-driven
    775          request using XMLHttpRequest <a href="#XHR"><cite title="XMLHttpRequest">[XHR]</cite></a>.
    776       </p>
    777       <p id="rfc.section.A.1.p.3">Other user agents can keep their default behavior, and switch to UTF-8 when seeing the new parameter.</p>
    778       <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;Alternative approach
    779       </h3>
    780       <p id="rfc.section.A.1.1.p.1">On the other hand, the strategy below may already improve the user-visible behavior today: </p>
    781       <ul>
    782          <li>In the first authentication request, choose the character encoding scheme based on the user's credentials: if they do not
    783             need any characters outside the ISO-8859-1 character repertoire, default to ISO-8859-1, otherwise use UTF-8.
    784          </li>
    785          <li>If the first attempt failed and the encoding used was ISO-8859-1, retry once with UTF-8 encoding instead.</li>
    786       </ul>
    787       <p id="rfc.section.A.1.1.p.2">Note that there's a risk if the site blocks an account after multiple login failures (for instance, when it doesn't reset
    788          the counter after a successful login).
    789       </p>
    790       <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;Origin Servers
    791       </h2>
    792       <p id="rfc.section.A.2.p.1">Origin servers that do not support non-ASCII characters in credentials do not require any changes.</p>
    793       <p id="rfc.section.A.2.p.2">Origin servers that need to support non-ASCII characters, but can't use the UTF-8 encoding will not be affected; they will
    794          continue to function as well or as badly as before.
    795       </p>
    796       <p id="rfc.section.A.2.p.3">Finally, origin servers that need to support non-ASCII characters and can use the UTF-8 encoding can opt in as described above.
    797          In the worst case, they'll continue to see either broken credentials or no credentials at all (depending on how legacy clients
    798          handle characters they can not encode).
    799       </p>
    800       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="faq" href="#faq">FAQ (to be removed by RFC Editor before publication)</a></h1>
    801       <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;Why not simply switch the default encoding to UTF-8?
    802       </h2>
    803       <p id="rfc.section.B.1.p.1">There are sites in use today that default to a locale encoding, such as ISO-8859-1, and expect user agents to use that encoding.
    804          These sites will break if the user agent uses a different encoding, such as UTF-8.
    805       </p>
    806       <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;What about Digest?
    807       </h2>
    808       <p id="rfc.section.B.2.p.1">The Digest scheme has similar issues with respect to internationalization. The HTTPAuth Working Group is chartered to address
    809          this problem as well, and the solution might be very similar.
    810       </p>
    811       <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Will existing UAs ignore the parameter?
    812       </h2>
    813       <p id="rfc.section.B.3.p.1">It appears they will. See &lt;<a href="http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1">http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1</a>&gt; and &lt;<a href="http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2">http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2</a>&gt;.
    814       </p>
    815       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
    816       <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a>&nbsp;Since draft-reschke-basicauth-enc-00
    817       </h2>
    818       <p id="rfc.section.C.1.p.1">Add and close issues "credparam" and "paramcase". Rewrite the deployment considerations.</p>
    819       <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a>&nbsp;Since draft-reschke-basicauth-enc-01
    820       </h2>
    821       <p id="rfc.section.C.2.p.1">Note more recent Mozilla bugzilla entry; add behavior of existing UAs to FAQ (with pointer to test cases).</p>
    822       <h2 id="rfc.section.C.3"><a href="#rfc.section.C.3">C.3</a>&nbsp;Since draft-reschke-basicauth-enc-02
    823       </h2>
    824       <p id="rfc.section.C.3.p.1">Add and resolve issue "xhrutf8".</p>
    825       <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;Since draft-reschke-basicauth-enc-03
    826       </h2>
    827       <p id="rfc.section.C.4.p.1">Add and resolve issue "proxy".</p>
    828       <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a>&nbsp;Since draft-reschke-basicauth-enc-04
    829       </h2>
    830       <p id="rfc.section.C.5.p.1">Add and resolve issues "<a href="http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.paramname" id="rfc.issue.paramname">paramname</a>" and "<a href="http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.sentparam" id="rfc.issue.sentparam">sentparam</a>". Add issues "<a href="http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.terminology" id="rfc.issue.terminology">terminology</a>" and "<a href="#rfc.issue.unorm">unorm</a>". Update HTTPbis reference.
    831       </p>
    832       <h2 id="rfc.section.C.6"><a href="#rfc.section.C.6">C.6</a>&nbsp;Since draft-reschke-basicauth-enc-05
    833       </h2>
    834       <p id="rfc.section.C.6.p.1">Update HTTPbis reference.</p>
    835       <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a>&nbsp;Since draft-reschke-basicauth-enc-06
    836       </h2>
    837       <p id="rfc.section.C.7.p.1">Update HTTPbis and XHR references.</p>
    838       <h2 id="rfc.section.C.8"><a href="#rfc.section.C.8">C.8</a>&nbsp;Since draft-reschke-basicauth-enc-07
    839       </h2>
    840       <p id="rfc.section.C.8.p.1">"b64token" -&gt; "token68" (ABNF term changed in HTTPbis P7). Change contact information from HTTPbis WG to HTTPAUTH WG. Add
    841          issue <a href="http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.parmname2831" id="rfc.issue.parmname2831">parmname2831</a>. Changed intended status to "experimental".
    842       </p>
    843       <h2 id="rfc.section.C.9"><a href="#rfc.section.C.9">C.9</a>&nbsp;<a id="changes.since.old.08" href="#changes.since.old.08">Since draft-reschke-basicauth-enc-08</a></h2>
    844       <p id="rfc.section.C.9.p.1">Made it a draft of the IETF HTTPauth Working Group.</p>
    845       <h2 id="rfc.section.C.10"><a href="#rfc.section.C.10">C.10</a>&nbsp;<a id="changes.since.00" href="#changes.since.00">Since draft-ietf-httpauth-basicauth-enc-00</a></h2>
    846       <p id="rfc.section.C.10.p.1">Clarify what encoding step the charset selection applies to.</p>
    847       <p id="rfc.section.C.10.p.2">Use RFC 6365 terminology.</p>
    848       <p id="rfc.section.C.10.p.3">Rename the parameter to "charset" for consistency with RFC 2831.</p>
    849       <h2 id="rfc.section.C.11"><a href="#rfc.section.C.11">C.11</a>&nbsp;<a id="changes.since.01" href="#changes.since.01">Since draft-ietf-httpauth-basicauth-enc-01</a></h2>
    850       <p id="rfc.section.C.11.p.1">Update httpbis reference.</p>
     783         <p><b>Julian F. Reschke</b><br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW&nbsp;48155<br>Germany<br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p>
     784      </div>
     785      <div>
     786         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Deployment Considerations
     787         </h1>
     788         <div>
     789            <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;User Agents
     790            </h2>
     791            <p id="rfc.section.A.1.p.1">User agents not implementing this specification should continue to work as before, ignoring the new parameter.</p>
     792            <p id="rfc.section.A.1.p.2">User agents which already default to the UTF-8 encoding implement this specification by definition. Note that some user agents
     793               also have different defaults depending on whether the request originates from page navigation as opposed to a script-driven
     794               request using XMLHttpRequest <a href="#XHR"><cite title="XMLHttpRequest">[XHR]</cite></a>.
     795            </p>
     796            <p id="rfc.section.A.1.p.3">Other user agents can keep their default behavior, and switch to UTF-8 when seeing the new parameter.</p>
     797            <div>
     798               <h3 id="rfc.section.A.1.1"><a href="#rfc.section.A.1.1">A.1.1</a>&nbsp;Alternative approach
     799               </h3>
     800               <p id="rfc.section.A.1.1.p.1">On the other hand, the strategy below may already improve the user-visible behavior today: </p>
     801               <ul>
     802                  <li>In the first authentication request, choose the character encoding scheme based on the user's credentials: if they do not
     803                     need any characters outside the ISO-8859-1 character repertoire, default to ISO-8859-1, otherwise use UTF-8.
     804                  </li>
     805                  <li>If the first attempt failed and the encoding used was ISO-8859-1, retry once with UTF-8 encoding instead.</li>
     806               </ul>
     807               <p id="rfc.section.A.1.1.p.2">Note that there's a risk if the site blocks an account after multiple login failures (for instance, when it doesn't reset
     808                  the counter after a successful login).
     809               </p>
     810            </div>
     811         </div>
     812         <div>
     813            <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;Origin Servers
     814            </h2>
     815            <p id="rfc.section.A.2.p.1">Origin servers that do not support non-ASCII characters in credentials do not require any changes.</p>
     816            <p id="rfc.section.A.2.p.2">Origin servers that need to support non-ASCII characters, but can't use the UTF-8 encoding will not be affected; they will
     817               continue to function as well or as badly as before.
     818            </p>
     819            <p id="rfc.section.A.2.p.3">Finally, origin servers that need to support non-ASCII characters and can use the UTF-8 encoding can opt in as described above.
     820               In the worst case, they'll continue to see either broken credentials or no credentials at all (depending on how legacy clients
     821               handle characters they can not encode).
     822            </p>
     823         </div>
     824      </div>
     825      <div id="faq">
     826         <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a href="#faq">FAQ (to be removed by RFC Editor before publication)</a></h1>
     827         <div>
     828            <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;Why not simply switch the default encoding to UTF-8?
     829            </h2>
     830            <p id="rfc.section.B.1.p.1">There are sites in use today that default to a locale encoding, such as ISO-8859-1, and expect user agents to use that encoding.
     831               These sites will break if the user agent uses a different encoding, such as UTF-8.
     832            </p>
     833         </div>
     834         <div>
     835            <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;What about Digest?
     836            </h2>
     837            <p id="rfc.section.B.2.p.1">The Digest scheme has similar issues with respect to internationalization. The HTTPAuth Working Group is chartered to address
     838               this problem as well, and the solution might be very similar.
     839            </p>
     840         </div>
     841         <div>
     842            <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Will existing UAs ignore the parameter?
     843            </h2>
     844            <p id="rfc.section.B.3.p.1">It appears they will. See &lt;<a href="http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1">http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1</a>&gt; and &lt;<a href="http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2">http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2</a>&gt;.
     845            </p>
     846         </div>
     847      </div>
     848      <div id="change.log">
     849         <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
     850         <div>
     851            <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a>&nbsp;Since draft-reschke-basicauth-enc-00
     852            </h2>
     853            <p id="rfc.section.C.1.p.1">Add and close issues "credparam" and "paramcase". Rewrite the deployment considerations.</p>
     854         </div>
     855         <div>
     856            <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a>&nbsp;Since draft-reschke-basicauth-enc-01
     857            </h2>
     858            <p id="rfc.section.C.2.p.1">Note more recent Mozilla bugzilla entry; add behavior of existing UAs to FAQ (with pointer to test cases).</p>
     859         </div>
     860         <div>
     861            <h2 id="rfc.section.C.3"><a href="#rfc.section.C.3">C.3</a>&nbsp;Since draft-reschke-basicauth-enc-02
     862            </h2>
     863            <p id="rfc.section.C.3.p.1">Add and resolve issue "xhrutf8".</p>
     864         </div>
     865         <div>
     866            <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;Since draft-reschke-basicauth-enc-03
     867            </h2>
     868            <p id="rfc.section.C.4.p.1">Add and resolve issue "proxy".</p>
     869         </div>
     870         <div>
     871            <h2 id="rfc.section.C.5"><a href="#rfc.section.C.5">C.5</a>&nbsp;Since draft-reschke-basicauth-enc-04
     872            </h2>
     873            <p id="rfc.section.C.5.p.1">Add and resolve issues "<a href="http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.paramname" id="rfc.issue.paramname">paramname</a>" and "<a href="http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.sentparam" id="rfc.issue.sentparam">sentparam</a>". Add issues "<a href="http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.terminology" id="rfc.issue.terminology">terminology</a>" and "<a href="#rfc.issue.unorm">unorm</a>". Update HTTPbis reference.
     874            </p>
     875         </div>
     876         <div>
     877            <h2 id="rfc.section.C.6"><a href="#rfc.section.C.6">C.6</a>&nbsp;Since draft-reschke-basicauth-enc-05
     878            </h2>
     879            <p id="rfc.section.C.6.p.1">Update HTTPbis reference.</p>
     880         </div>
     881         <div>
     882            <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a>&nbsp;Since draft-reschke-basicauth-enc-06
     883            </h2>
     884            <p id="rfc.section.C.7.p.1">Update HTTPbis and XHR references.</p>
     885         </div>
     886         <div>
     887            <h2 id="rfc.section.C.8"><a href="#rfc.section.C.8">C.8</a>&nbsp;Since draft-reschke-basicauth-enc-07
     888            </h2>
     889            <p id="rfc.section.C.8.p.1">"b64token" -&gt; "token68" (ABNF term changed in HTTPbis P7). Change contact information from HTTPbis WG to HTTPAUTH WG. Add
     890               issue <a href="http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.parmname2831" id="rfc.issue.parmname2831">parmname2831</a>. Changed intended status to "experimental".
     891            </p>
     892         </div>
     893         <div id="changes.since.old.08">
     894            <h2 id="rfc.section.C.9"><a href="#rfc.section.C.9">C.9</a>&nbsp;<a href="#changes.since.old.08">Since draft-reschke-basicauth-enc-08</a></h2>
     895            <p id="rfc.section.C.9.p.1">Made it a draft of the IETF HTTPauth Working Group.</p>
     896         </div>
     897         <div id="changes.since.00">
     898            <h2 id="rfc.section.C.10"><a href="#rfc.section.C.10">C.10</a>&nbsp;<a href="#changes.since.00">Since draft-ietf-httpauth-basicauth-enc-00</a></h2>
     899            <p id="rfc.section.C.10.p.1">Clarify what encoding step the charset selection applies to.</p>
     900            <p id="rfc.section.C.10.p.2">Use RFC 6365 terminology.</p>
     901            <p id="rfc.section.C.10.p.3">Rename the parameter to "charset" for consistency with RFC 2831.</p>
     902         </div>
     903         <div id="changes.since.01">
     904            <h2 id="rfc.section.C.11"><a href="#rfc.section.C.11">C.11</a>&nbsp;<a href="#changes.since.01">Since draft-ietf-httpauth-basicauth-enc-01</a></h2>
     905            <p id="rfc.section.C.11.p.1">Update httpbis reference.</p>
     906         </div>
     907      </div>
    851908   </body>
    852909</html>
  • draft-ietf-httpauth-basicauth-update/latest/draft-ietf-httpauth-basicauth-update.html

    r29 r30  
    106106body {
    107107  color: black;
    108   font-family: verdana, helvetica, arial, sans-serif;
    109   font-size: 10pt;
     108  font-family: cambria, helvetica, arial, sans-serif;
     109  font-size: 11pt;
    110110  margin-right: 2em;
    111111}
     
    129129}
    130130h1 {
    131   font-size: 14pt;
     131  font-size: 130%;
    132132  line-height: 21pt;
    133133  page-break-after: avoid;
     
    136136  page-break-before: always;
    137137}
    138 h1 a {
    139   color: #333333;
    140 }
    141138h2 {
    142   font-size: 12pt;
     139  font-size: 120%;
    143140  line-height: 15pt;
    144141  page-break-after: avoid;
    145142}
    146143h3, h4, h5, h6 {
    147   font-size: 10pt;
     144  font-size: 110%;
    148145  page-break-after: avoid;
    149146}
    150 h2 a, h3 a, h4 a, h5 a, h6 a {
     147h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    151148  color: black;
    152149}
     
    206203  border-spacing: 1px;
    207204  width: 95%;
    208   font-size: 10pt;
     205  font-size: 11pt;
    209206  color: white;
    210207}
     
    239236  line-height: 150%;
    240237  font-weight: bold;
    241   font-size: 10pt;
    242238  margin-left: 0em;
    243239}
     
    245241  line-height: normal;
    246242  font-weight: normal;
    247   font-size: 9pt;
     243  font-size: 10pt;
    248244  margin-left: 0em;
    249245}
     
    253249ul p {
    254250  margin-left: 0em;
     251}
     252.title, .filename, h1, h2, h3, h4 {
     253  font-family: candara, helvetica, arial, sans-serif;
     254}
     255samp, tt, code, pre {
     256  font: consolas, monospace;
    255257}
    256258ul.ind, ul.ind ul {
     
    292294  font-weight: bold;
    293295  text-align: center;
    294   font-size: 9pt;
     296  font-size: 10pt;
    295297}
    296298.filename {
    297299  color: #333333;
    298   font-weight: bold;
    299   font-size: 12pt;
     300  font-size: 75%;
     301  font-weight: bold;
    300302  line-height: 21pt;
    301303  text-align: center;
     
    311313}
    312314.title {
    313   color: #990000;
    314   font-size: 18pt;
     315  color: green;
     316  font-size: 150%;
    315317  line-height: 18pt;
    316318  font-weight: bold;
     
    318320  margin-top: 36pt;
    319321}
    320 .vcardline {
    321   display: block;
    322 }
    323322.warning {
    324   font-size: 14pt;
     323  font-size: 130%;
    325324  background-color: yellow;
    326325}
     
    345344  border: solid;
    346345  border-width: 1px;
    347   font-size: 7pt;
     346  font-size: 8pt;
    348347}
    349348.closed-issue {
     
    407406    background-color: white;
    408407    vertical-align: top;
    409     font-size: 12pt;
     408    font-size: 110%;
    410409  }
    411410
     
    468467      <link rel="Chapter" href="#rfc.section.6" title="6 References">
    469468      <link rel="Appendix" title="A Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.A">
    470       <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/">
     469      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.603, 2013/09/18 20:22:25, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    471470      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    472471      <meta name="dct.creator" content="Reschke, J. F.">
     
    512511      <p>The changes in this draft are summarized in <a href="#changes.since.00" title="Since draft-ietf-httpauth-basicauth-update-00">Appendix&nbsp;A.2</a>.
    513512      </p>
    514       <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
    515       <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
    516       <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
    517          working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
    518       </p>
    519       <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    520          documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    521          in progress”.
    522       </p>
    523       <p>This Internet-Draft will expire on March 29, 2014.</p>
    524       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    525       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    526       <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
    527          and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
    528          text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
    529          BSD License.
    530       </p>
    531       <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
    532          10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
    533          allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
    534          controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
    535          works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
    536          it into languages other than English.
    537       </p>
     513      <div id="rfc.status">
     514         <h1><a href="#rfc.status">Status of This Memo</a></h1>
     515         <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
     516         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
     517            working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
     518         </p>
     519         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
     520            documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
     521            in progress”.
     522         </p>
     523         <p>This Internet-Draft will expire on March 29, 2014.</p>
     524      </div>
     525      <div id="rfc.copyrightnotice">
     526         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     527         <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     528         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
     529            and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
     530            text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
     531            BSD License.
     532         </p>
     533         <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
     534            10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
     535            allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
     536            controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
     537            works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
     538            it into languages other than English.
     539         </p>
     540      </div>
    538541      <hr class="noprint">
    539542      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
     
    615618         </tr>
    616619      </table>
    617       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    618       <p id="rfc.section.1.p.1">This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme (<a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>). This scheme is not considered to be a secure method of user authentication unless used in conjunction with some external
    619          secure system such as TLS (Transport Layer Security, <a href="#RFC5246"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>), as the user name and password are passed over the network as cleartext.
    620       </p>
    621       <p id="rfc.section.1.p.2">The "Basic" scheme previously was defined in <a href="http://tools.ietf.org/html/rfc2617#section-2">Section 2</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. This document updates the definition, and also addresses internationalization issues.
    622       </p>
    623       <p id="rfc.section.1.p.3">Other documents updating RFC 2617 are "Hypertext Transfer Protocol (HTTP/1.1): Authentication" (<a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>, defining the authentication framework) and "HTTP Digest Update" (<a href="#draft-ietf-httpauth-digest-update"><cite title="HTTP Digest Update">[draft-ietf-httpauth-digest-update]</cite></a>, updating the definition of the '"Digest" authentication scheme).
    624       </p>
    625       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="notational.conventions" href="#notational.conventions">Notational Conventions</a></h2>
    626       <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    627          in this document are to be interpreted as described in <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    628       </p>
    629       <h3 id="rfc.section.1.1.1"><a href="#rfc.section.1.1.1">1.1.1</a>&nbsp;<a id="syntax.notation" href="#syntax.notation">Syntax Notation</a></h3>
    630       <p id="rfc.section.1.1.1.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>.
    631       </p>
    632       <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="basic.authentication.scheme" href="#basic.authentication.scheme">The 'Basic' Authentication Scheme</a></h1>
    633       <table class="openissue">
    634          <tr>
    635             <td colspan="3"><a id="rfc.issue.upd" class="open-issue">&nbsp;I&nbsp;</a>&nbsp;<em>upd</em>
    636                &nbsp;
    637                (type: change, status: open)
    638                
    639             </td>
    640          </tr>
    641          <tr>
    642             <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>
    643             <td class="topnowrap">2013-09-12</td>
    644             <td class="top">
    645                Update the definition to reflect underlying changes (RFC2616-&gt;httpbis,
    646                RFC2396-&gt;2616, other references).
    647                
    648             </td>
    649          </tr>
    650       </table>
    651       <table class="openissue">
    652          <tr>
    653             <td colspan="3"><a id="rfc.issue.enc" class="open-issue">&nbsp;I&nbsp;</a>&nbsp;<em>enc</em>
    654                &nbsp;
    655                (type: change, status: open)
    656                
    657             </td>
    658          </tr>
    659          <tr>
    660             <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>
    661             <td class="topnowrap">2013-09-12</td>
    662             <td class="top">
    663                Fix the encoding issue, by pulling in draft-ietf-httpauth-basicauth-enc.
    664                
    665             </td>
    666          </tr>
    667       </table>
    668       <p id="rfc.section.2.p.1">The "basic" authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password
    669          for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms
    670          on that server. The server will service the request only if it can validate the user-ID and password for the protection space
    671          of the Request-URI. There are no optional authentication parameters.
    672       </p>
    673       <p id="rfc.section.2.p.2">For Basic, the framework above is utilized as follows:</p>
    674       <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
     620      <div id="introduction">
     621         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1>
     622         <p id="rfc.section.1.p.1">This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme (<a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>). This scheme is not considered to be a secure method of user authentication unless used in conjunction with some external
     623            secure system such as TLS (Transport Layer Security, <a href="#RFC5246"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>), as the user name and password are passed over the network as cleartext.
     624         </p>
     625         <p id="rfc.section.1.p.2">The "Basic" scheme previously was defined in <a href="http://tools.ietf.org/html/rfc2617#section-2">Section 2</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. This document updates the definition, and also addresses internationalization issues.
     626         </p>
     627         <p id="rfc.section.1.p.3">Other documents updating RFC 2617 are "Hypertext Transfer Protocol (HTTP/1.1): Authentication" (<a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>, defining the authentication framework) and "HTTP Digest Update" (<a href="#draft-ietf-httpauth-digest-update"><cite title="HTTP Digest Update">[draft-ietf-httpauth-digest-update]</cite></a>, updating the definition of the '"Digest" authentication scheme).
     628         </p>
     629         <div id="notational.conventions">
     630            <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#notational.conventions">Notational Conventions</a></h2>
     631            <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     632               in this document are to be interpreted as described in <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
     633            </p>
     634            <div id="syntax.notation">
     635               <h3 id="rfc.section.1.1.1"><a href="#rfc.section.1.1.1">1.1.1</a>&nbsp;<a href="#syntax.notation">Syntax Notation</a></h3>
     636               <p id="rfc.section.1.1.1.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>.
     637               </p>
     638            </div>
     639         </div>
     640      </div>
     641      <div id="basic.authentication.scheme">
     642         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#basic.authentication.scheme">The 'Basic' Authentication Scheme</a></h1>
     643         <table class="openissue">
     644            <tr>
     645               <td colspan="3"><a id="rfc.issue.upd" class="open-issue">&nbsp;I&nbsp;</a>&nbsp;<em>upd</em>
     646                  &nbsp;
     647                  (type: change, status: open)
     648                 
     649               </td>
     650            </tr>
     651            <tr>
     652               <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>
     653               <td class="topnowrap">2013-09-12</td>
     654               <td class="top">
     655                  Update the definition to reflect underlying changes (RFC2616-&gt;httpbis,
     656                  RFC2396-&gt;2616, other references).
     657                 
     658               </td>
     659            </tr>
     660         </table>
     661         <table class="openissue">
     662            <tr>
     663               <td colspan="3"><a id="rfc.issue.enc" class="open-issue">&nbsp;I&nbsp;</a>&nbsp;<em>enc</em>
     664                  &nbsp;
     665                  (type: change, status: open)
     666                 
     667               </td>
     668            </tr>
     669            <tr>
     670               <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>
     671               <td class="topnowrap">2013-09-12</td>
     672               <td class="top">
     673                  Fix the encoding issue, by pulling in draft-ietf-httpauth-basicauth-enc.
     674                 
     675               </td>
     676            </tr>
     677         </table>
     678         <p id="rfc.section.2.p.1">The "basic" authentication scheme is based on the model that the client must authenticate itself with a user-ID and a password
     679            for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms
     680            on that server. The server will service the request only if it can validate the user-ID and password for the protection space
     681            of the Request-URI. There are no optional authentication parameters.
     682         </p>
     683         <p id="rfc.section.2.p.2">For Basic, the framework above is utilized as follows:</p>
     684         <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
    675685   credentials = "Basic" basic-credentials
    676686</pre><p id="rfc.section.2.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:
    677       </p>
    678       <div id="rfc.figure.u.2"></div><pre class="text">   WWW-Authenticate: Basic realm="WallyWorld"
     687         </p>
     688         <div id="rfc.figure.u.2"></div><pre class="text">   WWW-Authenticate: Basic realm="WallyWorld"
    679689</pre><p id="rfc.section.2.p.6">where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI. A proxy may respond
    680          with the same challenge using the Proxy-Authenticate header field.
    681       </p>
    682       <p id="rfc.section.2.p.7">To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a
    683          base64 encoded string in the credentials (<a href="#RFC4648"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>, <a href="http://tools.ietf.org/html/rfc4648#section-4">Section 4</a>).
    684       </p>
    685       <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
     690            with the same challenge using the Proxy-Authenticate header field.
     691         </p>
     692         <p id="rfc.section.2.p.7">To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a
     693            base64 encoded string in the credentials (<a href="#RFC4648"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>, <a href="http://tools.ietf.org/html/rfc4648#section-4">Section 4</a>).
     694         </p>
     695         <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
    686696   base64-user-pass  = &lt;base64 encoded user-pass&gt;
    687697                     ; <a href="#RFC4648"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a> encoding of user-pass,
     
    691701   password    = *TEXT
    692702</pre><p id="rfc.section.2.p.9">Userids might be case sensitive.</p>
    693       <p id="rfc.section.2.p.10">If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:</p>
    694       <div id="rfc.figure.u.4"></div><pre class="text">   Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
     703         <p id="rfc.section.2.p.10">If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:</p>
     704         <div id="rfc.figure.u.4"></div><pre class="text">   Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    695705</pre><p id="rfc.section.2.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
    696          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
    697          challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the
    698          Proxy-Authorization header field without receiving another challenge from the proxy server. See <a href="#security.considerations" title="Security Considerations">Section&nbsp;3</a> for security considerations associated with Basic authentication.
    699       </p>
    700       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    701       <p id="rfc.section.3.p.1">The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity,
    702          which is transmitted in cleartext across the physical network used as the carrier. HTTP does not prevent the addition of enhancements
    703          (such as schemes to use one-time passwords) to Basic authentication.
    704       </p>
    705       <p id="rfc.section.3.p.2">The most serious flaw in Basic authentication is that it results in the essentially cleartext transmission of the user's password
    706          over the physical network. Many other authentication schemes address this problem.
    707       </p>
    708       <p id="rfc.section.3.p.3">Because Basic authentication involves the cleartext transmission of passwords it <em class="bcp14">SHOULD NOT</em> be used (without enhancements) to protect sensitive or valuable information.
    709       </p>
    710       <p id="rfc.section.3.p.4">A common use of Basic authentication is for identification purposes — requiring the user to provide a user name and password
    711          as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this
    712          way it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major
    713          concern. This is only correct if the server issues both user name and password to the users and in particular does not allow
    714          the user to choose his or her own password. The danger arises because naive users frequently reuse a single password to avoid
    715          the task of maintaining multiple passwords.
    716       </p>
    717       <p id="rfc.section.3.p.5">If a server permits users to select their own passwords, then the threat is not only unauthorized access to documents on the
    718          server but also unauthorized access to any other resources on other systems that the user protects with the same password.
    719          Furthermore, in the server's password database, many of the passwords may also be users' passwords for other sites. The owner
    720          or administrator of such a system could therefore expose all users of the system to the risk of unauthorized access to all
    721          those sites if this information is not maintained in a secure fashion.
    722       </p>
    723       <p id="rfc.section.3.p.6">Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting
    724          to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or
    725          gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not
    726          possible with Digest Authentication. Server implementers <em class="bcp14">SHOULD</em> guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous
    727          for a server to simply turn over a connection to a gateway. That gateway can then use the persistent connection mechanism
    728          to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable
    729          by the client.
    730       </p>
    731       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1>
    732       <p id="rfc.section.4.p.1">IANA maintains the registry of HTTP Authentication Schemes (<a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>) at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
    733       </p>
    734       <p id="rfc.section.4.p.2">The entry for the "Basic" Authentication Scheme shall be updated with a pointer to this specification.</p>
    735       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;Acknowledgements
    736       </h1>
    737       <p id="rfc.section.5.p.1">This specification takes over the definition of the "Basic" HTTP Authentication Scheme, previously defined in RFC 2617. We
    738          thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence
    739          C. Stewart for their work on that specification, from which significant amounts of text was borrowed. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements.
    740       </p>
     706            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
     707            challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the
     708            Proxy-Authorization header field without receiving another challenge from the proxy server. See <a href="#security.considerations" title="Security Considerations">Section&nbsp;3</a> for security considerations associated with Basic authentication.
     709         </p>
     710      </div>
     711      <div id="security.considerations">
     712         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1>
     713         <p id="rfc.section.3.p.1">The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity,
     714            which is transmitted in cleartext across the physical network used as the carrier. HTTP does not prevent the addition of enhancements
     715            (such as schemes to use one-time passwords) to Basic authentication.
     716         </p>
     717         <p id="rfc.section.3.p.2">The most serious flaw in Basic authentication is that it results in the essentially cleartext transmission of the user's password
     718            over the physical network. Many other authentication schemes address this problem.
     719         </p>
     720         <p id="rfc.section.3.p.3">Because Basic authentication involves the cleartext transmission of passwords it <em class="bcp14">SHOULD NOT</em> be used (without enhancements) to protect sensitive or valuable information.
     721         </p>
     722         <p id="rfc.section.3.p.4">A common use of Basic authentication is for identification purposes — requiring the user to provide a user name and password
     723            as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this
     724            way it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major
     725            concern. This is only correct if the server issues both user name and password to the users and in particular does not allow
     726            the user to choose his or her own password. The danger arises because naive users frequently reuse a single password to avoid
     727            the task of maintaining multiple passwords.
     728         </p>
     729         <p id="rfc.section.3.p.5">If a server permits users to select their own passwords, then the threat is not only unauthorized access to documents on the
     730            server but also unauthorized access to any other resources on other systems that the user protects with the same password.
     731            Furthermore, in the server's password database, many of the passwords may also be users' passwords for other sites. The owner
     732            or administrator of such a system could therefore expose all users of the system to the risk of unauthorized access to all
     733            those sites if this information is not maintained in a secure fashion.
     734         </p>
     735         <p id="rfc.section.3.p.6">Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting
     736            to a host containing information protected by Basic authentication when, in fact, he is connecting to a hostile server or
     737            gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not
     738            possible with Digest Authentication. Server implementers <em class="bcp14">SHOULD</em> guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous
     739            for a server to simply turn over a connection to a gateway. That gateway can then use the persistent connection mechanism
     740            to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable
     741            by the client.
     742         </p>
     743      </div>
     744      <div id="iana.considerations">
     745         <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#iana.considerations">IANA Considerations</a></h1>
     746         <p id="rfc.section.4.p.1">IANA maintains the registry of HTTP Authentication Schemes (<a href="#draft-ietf-httpbis-p7-auth"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[draft-ietf-httpbis-p7-auth]</cite></a>) at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
     747         </p>
     748         <p id="rfc.section.4.p.2">The entry for the "Basic" Authentication Scheme shall be updated with a pointer to this specification.</p>
     749      </div>
     750      <div>
     751         <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;Acknowledgements
     752         </h1>
     753         <p id="rfc.section.5.p.1">This specification takes over the definition of the "Basic" HTTP Authentication Scheme, previously defined in RFC 2617. We
     754            thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence
     755            C. Stewart for their work on that specification, from which significant amounts of text was borrowed. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements.
     756         </p>
     757      </div>
    741758      <h1 id="rfc.references"><a id="rfc.section.6" href="#rfc.section.6">6.</a> References
    742759      </h1>
     
    786803      <div class="avoidbreak">
    787804         <h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
    788          <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>
    789       </div>
    790       <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>
    791       <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>
    792       <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
    793          "Basic", plus the related Security Considerations, and also adds the IANA registration of the scheme. Changes to the actual
    794          definition will be made in subsequent drafts.
    795       </p>
    796       <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.since.00" href="#changes.since.00">Since draft-ietf-httpauth-basicauth-update-00</a></h2>
    797       <p id="rfc.section.A.2.p.1">Fixed Base64 reference to point to an actual definition of Base64.</p>
    798       <p id="rfc.section.A.2.p.2">Update HTTPbis reference.</p>
     805         <p><b>Julian F. Reschke</b><br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW&nbsp;48155<br>Germany<br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p>
     806      </div>
     807      <div id="change.log">
     808         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
     809         <div id="changes.since.rfc2617">
     810            <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a href="#changes.since.rfc2617">Since RFC 2617</a></h2>
     811            <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
     812               "Basic", plus the related Security Considerations, and also adds the IANA registration of the scheme. Changes to the actual
     813               definition will be made in subsequent drafts.
     814            </p>
     815         </div>
     816         <div id="changes.since.00">
     817            <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a href="#changes.since.00">Since draft-ietf-httpauth-basicauth-update-00</a></h2>
     818            <p id="rfc.section.A.2.p.1">Fixed Base64 reference to point to an actual definition of Base64.</p>
     819            <p id="rfc.section.A.2.p.2">Update HTTPbis reference.</p>
     820         </div>
     821      </div>
    799822      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    800823      <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>
Note: See TracChangeset for help on using the changeset viewer.