One document matched: draft-reschke-basicauth-enc-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
    This XML document is the output of clean-for-DTD.xslt; a tool that strips
    extensions to RFC2629(bis) from documents for processing with xml2rfc.
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-reschke-basicauth-enc-01" category="std" updates="2617">
	<front>
  <title abbrev="Basic Auth Encoding Parameter">An Encoding Parameter for HTTP
  Basic Authentication</title>
  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
    <organization abbrev="greenbytes">greenbytes GmbH</organization>
    <address>
      <postal>
        <street>Hafenweg 16</street>
        <city>Muenster</city><region>NW</region><code>48155</code>
        <country>Germany</country>
      </postal>
      <email>julian.reschke@greenbytes.de</email>	
      <uri>http://greenbytes.de/tech/webdav/</uri>	
    </address>
  </author>

  <date month="August" year="2010" day="16"/>
  
  <abstract>
    <t>
      The "Basic" authentication scheme defined in RFC 2617 does not properly
      define how to treat non-ASCII characters. This has lead 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 characters in the ISO-8859-1 character set, and even less
      interoperability for any characters beyond that.
    </t>
    <t>
      This document defines a backwards-compatible extension to "Basic", 
      specifying the server's character encoding expectation,
      using a new authentication scheme parameter.
    </t>
  </abstract>
  
  <note title="Editorial Note (To be removed by RFC Editor before publication)">
    <t>
      Distribution of this document is unlimited. Although this is not a work
      item of the HTTPbis Working Group, comments should be sent to the 
      Hypertext Transfer Protocol (HTTP) mailing list at <eref target="mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</eref>,
      which may be joined by sending a message with subject 
      "subscribe" to <eref target="mailto:ietf-http-wg-request@w3.org?subject=subscribe">ietf-http-wg-request@w3.org</eref>.
    </t>
    <t>
      Discussions of the HTTPbis Working Group are archived at
      <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.               
    </t> 
    <t>
      XML versions, latest edits and the issues list for this document
      are available from <eref target="http://greenbytes.de/tech/webdav/#draft-reschke-basicauth-enc"/>.
    </t>
  </note>
  </front>

  <middle>






<section title="Introduction" anchor="introduction">
<t>
  The "Basic" authentication scheme defined in Section 2 of <xref target="RFC2617"/> does
  not properly define how to treat non-ASCII characters (<xref target="USASCII"/>): it uses the Base64
  <xref target="RFC4648"/>
  encoding of the concatenation of username, separator character, and password
  without stating which character encoding to use.
</t>
<t>  
  This has lead 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 characters in the ISO-8859-1 character set (<xref target="ISO-8859-1"/>),
  and even less interoperability for any characters beyond that.
</t>
<t>
  This document defines a backwards-compatible extension to "Basic", 
  specifying the server's character encoding expection,
  using a new auth-param as defined in Section 1.2 of <xref target="RFC2617"/>.
</t>
</section>  

<section title="Notational Conventions">
<t>
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
  are to be interpreted as described in <xref target="RFC2119"/>.
</t>
<!--<t>
  This specification uses the ABNF (Augmented Backus-Naur Form) notation defined in
  <xref target="RFC5234"/>. The following core rules are included by
  reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
  ALPHA (letters), DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f) and
  LWSP (linear white space).
</t>-->
</section>  

<section title="The 'encoding' auth-param" anchor="encoding">
<t>
  In challenges, servers MAY use the "encoding" authentication parameter (case-insensitive) to express the
  character encoding they expect the user agent to use.
  
  
</t>
<t>
  The only allowed value is "UTF-8", to be matched case-insensitively 
  (see <xref target="RFC2978"/>, Section 2.3), indicating that
  the server expects the UTF-8 character encoding to be used
  (<xref target="RFC3629"/>).
</t>
<t>  
  Other values are reserved for future use.
</t>

<t>
  For credentials sent by the user agent, the "encoding" parameter is
  reserved for future use and MUST NOT be sent.
</t>
<t>
  The reason for this is that the information that could be included does
  not seem to be useful to the server, but the additional complexity
  of parsing and processing the additional parameter might make this
  extension harder to deploy.
</t>

</section>  

<section title="Examples" anchor="examples">
<figure>
  <preamble>In the example below, the server prompts for authentication in the "foo" realm,
  using Basic authentication, with a preference for the UTF-8 character encoding:</preamble>
  <artwork type="example"><![CDATA[
WWW-Authenticate: Basic realm="foo", encoding="UTF-8"
]]></artwork>
  <postamble>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 notation.</postamble>
</figure>
<t>
  The user's name is "test", and his password is the string "123" followed by
  the Unicode character U+00A3 (POUND SIGN). Following Section 1.2 of <xref target="RFC2617"/>, but using the character encoding UTF-8, the user-pass, 
  converted to a sequence of octets, is:
</t>
<figure><artwork type="example"><![CDATA[
 't' 'e' 's' 't' ':' '1' '2' '3' pound
 74  65  73  74  3A  31  32  33  C2  A3  
]]></artwork></figure>
<t>
  Encoding this octet sequence in Base64 (<xref target="RFC4648"/>) yields:
</t>
<figure><artwork type="example"><![CDATA[
  dGVzdDoxMjPCow==
]]></artwork></figure>
<t>
  Thus the Authorization header field would be:
</t>
<figure><artwork type="example"><![CDATA[
  Authorization: Basic dGVzdDoxMjPCow==
]]></artwork></figure>
</section>  

<section title="Security Considerations" anchor="security.considerations">
<t>
  This document does not introduce any new security considerations beyond
  those defined for the "Basic" authentication scheme (<xref target="RFC2617"/>, Section 4), and those
  applicable to the handling of UTF-8 (<xref target="RFC3629"/>, Section 10).
</t>
</section>  

<section title="IANA Considerations" anchor="iana.considerations">
<t>
  There are no IANA Considerations related to this specification.
</t>
</section>  

<section title="Acknowledgements">
<t>
  The internationalisation problem has been reported as a Mozilla bug back
  in the year 2000 (see <eref target="https://bugzilla.mozilla.org/show_bug.cgi?id=41489"/>).
  It was Andrew Clover's idea to address it using a new auth-param.
</t>
<t>
  Thanks to Martin Thomson for providing feedback on this document.
</t>
</section>  
  </middle>
  <back>
  
<references title="Normative References">
  
  <reference anchor="RFC2119">
    <front>
      <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
      <author initials="S." surname="Bradner" fullname="Scott Bradner">
        <organization>Harvard University</organization>
        <address><email>sob@harvard.edu</email></address>
      </author>
      <date month="March" year="1997"/>
    </front>
    <seriesInfo name="BCP" value="14"/>
    <seriesInfo name="RFC" value="2119"/>
  </reference>

  <reference anchor="RFC2978">
    <front>
      <title>IANA Charset Registration Procedures</title>
      <author initials="N." surname="Freed" fullname="N. Freed"/>
      <author initials="J." surname="Postel" fullname="J. Postel"/>
      <date year="2000" month="October"/>
    </front>
    <seriesInfo name="BCP" value="19"/>
    <seriesInfo name="RFC" value="2978"/>
  </reference>

  <reference anchor="RFC3629">
    <front>
      <title>UTF-8, a transformation format of ISO 10646</title>
      <author initials="F." surname="Yergeau" fullname="F. Yergeau">
        <organization>Alis Technologies</organization>
        <address><email>fyergeau@alis.com</email></address>
      </author>
      <date month="November" year="2003"/>
    </front>
    <seriesInfo name="RFC" value="3629"/>
    <seriesInfo name="STD" value="63"/>
  </reference>

<!--  <reference anchor="RFC5234">
    <front>
      <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
      <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
        <organization>Brandenburg InternetWorking</organization>
        <address>
          <phone>+1.408.246.8253</phone>
          <email>dcrocker@bbiw.net</email>
        </address>  
      </author>
      <author initials="P." surname="Overell" fullname="Paul Overell">
        <organization>THUS plc.</organization>
        <address>
          <email>paul.overell@thus.net</email>
        </address>
      </author>
      <date month="January" year="2008"/>
    </front>
    <seriesInfo name="STD" value="68"/>
    <seriesInfo name="RFC" value="5234"/>
  </reference>-->

  <reference anchor="ISO-8859-1">
    <front>
      <title>Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1</title>
      <author>
        <organization>International Organization for Standardization</organization>
      </author>
      <date year="1998"/>
    </front>
    <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
  </reference>

  <reference anchor="USASCII">
    <front>
      <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
      <author>
        <organization>American National Standards Institute</organization>
      </author>
      <date year="1986"/>
    </front>
    <seriesInfo name="ANSI" value="X3.4"/>
  </reference>

  <reference anchor="RFC2617">
    <front>
      <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
      <author initials="J." surname="Franks" fullname="John Franks">
        <organization>Northwestern University, Department of Mathematics</organization>
        <address><email>john@math.nwu.edu</email></address>
      </author>
      <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
        <organization>Verisign Inc.</organization>
        <address><email>pbaker@verisign.com</email></address>
      </author>
      <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
        <organization>AbiSource, Inc.</organization>
        <address><email>jeff@AbiSource.com</email></address>
      </author>
      <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
        <organization>Agranat Systems, Inc.</organization>
        <address><email>lawrence@agranat.com</email></address>
      </author>
      <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
        <organization>Microsoft Corporation</organization>
        <address><email>paulle@microsoft.com</email></address>
      </author>
      <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
        <organization>Netscape Communications Corporation</organization>
      </author>
      <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
        <organization>Open Market, Inc.</organization>
        <address><email>stewart@OpenMarket.com</email></address>
      </author>
      <date month="June" year="1999"/>
    </front>
    <seriesInfo name="RFC" value="2617"/>
  </reference>

</references>
  
<references title="Informative References">

<reference anchor="RFC4648">
  <front>
    <title>The Base16, Base32, and Base64 Data Encodings</title>
    <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
    <date year="2006" month="October"/>
  </front>
  <seriesInfo value="4648" name="RFC"/>
</reference>


</references>


<section title="Deployment Considerations">

<section title="User Agents">

<t>
  User agents not implementing this specifications should continue to work as
  before, ignoring the new parameter.
</t>
<t>
  User agents which already default to the UTF-8 encoding already implement
  this specification by definition.
</t>
<t>
  Other user agents can keep their default behavior, and switch to UTF-8
  when seeing the new parameter.
</t>

<section title="Alternative approach">
<t>
  On the other hand, the strategy below may already improve the user-visible
  behavior today:
  <list style="symbols">
    <t>
      In the first authentication request, choose the character encoding based
      on the user's credentials: if they do not need any characters outside
      the ISO-8859-1 character set, default to ISO-8859-1, otherwise use
      UTF-8.
    </t>
    <t>
      If the first attempt failed and the encoding used was ISO-8859-1, retry
      once with UTF-8 encoding instead.
    </t>
  </list>
</t>
</section>


</section>

<section title="Origin Servers">

<t>
  Origin servers that do not expect non-ASCII characters in credentials do not
  require any changes.
</t>
<t>
  Origin servers that need to support non-ASCII characters, but can't use
  the UTF-8 encoding will not be affected; they will continue to function
  as well as before.
</t>
<t>
  Finally, origin servers that need to support non-ASCII characters and can
  use the UTF-8 encoding can opt in as described above. In the worst case,
  they'll continue to see either broken credentials or no credentials at
  all (depending on how legacy clients handle characters they can not
  encode). 
</t>

</section>

</section>

<section title="FAQ (to be removed by RFC Editor before publication)" anchor="faq">

<section title="Why not simply switch the default encoding to UTF-8?">
<t>
  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. These sites
  will break if the user agent uses a different encoding, such as UTF-8.
</t>
</section>

<section title="What about Digest?">
<t>
  Although the solution proposed in this document may be applicable to
  "Digest" as well, any attempt to update this scheme may be an uphill
  battle hard to win. 
</t>
</section>



</section>


<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
<section title="Since draft-reschke-basicauth-enc-00">
<t>
  Add and close issues "credparam" and "paramcase".
  Rewrite the deployment considerations.
</t>
</section>
</section>



  <section title="Resolved issues (to be removed by RFC Editor before publication)"><t>
          Issues that were either rejected or resolved in this version of this
          document.
        </t><section title="paramcase"><t>
      Type: change</t><t>julian.reschke@greenbytes.de (2010-08-12): 
    Are auth param names case-sensitive?
  </t><t>Resolution (2010-08-12): 
    Be consistent with "realm" (case-insensitive). Note that should be clarified
    in RFC2617bis for auth params in general.
  </t></section><section title="credparam"><t>
      Type: change</t><t>julian.reschke@greenbytes.de (2010-08-12): 
    Should "encoding" also be defined for the credentials (the UA's response)?
  </t><t>Resolution: 
    Disallow (but reserve) encoding in credentials, and explain why this is
    the case.
  </t></section></section><section title="Open issues (to be removed by RFC Editor prior to publication)"><section title="edit"><t>
      Type: edit</t><t>julian.reschke@greenbytes.de (2010-08-11): 
    Umbrella issue for editorial fixes/enhancements.
  </t></section></section></back>

</rfc>