One document matched: draft-ietf-httpauth-basicauth-enc-02.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-ietf-httpauth-basicauth-enc-02" category="exp" 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 year="2014" month="February" day="4"/>
<area>Security</area>
<workgroup>HTTPAuth Working Group</workgroup>
<abstract>
<t>
The "Basic" 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.
</t>
<t>
This document defines a backwards-compatible extension to "Basic",
specifying the server's character encoding scheme expectation,
using a new authentication scheme parameter.
</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor before publication)">
<t>
Discussion of this draft takes place on the HTTPAuth working group
mailing list (http-auth@ietf.org), which is archived at
<eref target="http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html"/>.
</t>
<t>
XML versions, latest edits and the issues list for this document
are available from <eref target="http://greenbytes.de/tech/webdav/#draft-ietf-httpauth-basicauth-enc"/>.
</t>
<t>
The changes in this draft are summarized in <xref target="changes.since.01"/>.
</t>
<t>
The contents of this document will likely be included into the new specification
of the "Basic" scheme, see <eref target="http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update"/>.
</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"/>, Section 4)
encoding of the concatenation of username, separator character, and password
without stating which character encoding scheme to use.
</t>
<t>
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 (<xref target="USASCII"/>, <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 scheme expectation,
using a new auth-param
for use in the Proxy-Authenticate and WWW-Authenticate header fields,
as defined in <xref target="draft-ietf-httpbis-p7-auth"/>.
</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>
The terms (character) repertoire and
character encoding scheme are defined in
Section 2 of <xref target="RFC6365"/>.
</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 'charset' auth-param" anchor="charset">
<t>
In challenges, servers MAY use the "charset" authentication parameter
(case-insensitive) to indicate the character encoding scheme they expect the user
agent to use when generating "user-pass" (a sequence of octets) from "userid"
and "password" (<xref target="RFC2617"/>, Section 2).
</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 scheme to be used
(<xref target="RFC3629"/>).
</t>
<t>
Other values are reserved for future use.
</t>
<t><list>
<t>
Note: The 'charset' parameter cannot be included when sending
credentials (e.g. in the Authorization or Proxy-Authorization header fields),
as the "Basic" scheme uses a single token for credentials
('token68' syntax), not a parameter list ('#auth-param' syntax); see
Section 2.1 of <xref target="draft-ietf-httpbis-p7-auth"/>.
</t>
</list></t>
<t><list>
<t>
Note: The name 'charset' has been chosen for consistency with
Section 2.1.1 of <xref target="RFC2831"/>. A better name would have
been 'accept-charset', as it is not about the message it appears in, but
the server's expectation.
</t>
</list></t>
</section>
<section title="Example" anchor="example">
<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 scheme:</preamble>
<artwork type="example"><![CDATA[
WWW-Authenticate: Basic realm="foo", charset="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 scheme 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"/>, Section 4) 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>
<t>
Or, for proxy authentication:
</t>
<figure><artwork type="example"><![CDATA[
Proxy-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"/>
and also the more recent <eref target="https://bugzilla.mozilla.org/show_bug.cgi?id=656213"/>).
It was Andrew Clover's idea to address it using a new auth-param.
</t>
<t>
Thanks to Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Manger,
Yaron Sheffer, and 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="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
</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>
<reference anchor="RFC6365">
<front>
<title>Terminology Used in Internationalization in the IETF</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"/>
<author initials="J." surname="Klensin" fullname="J. Klensin"/>
<date year="2011" month="September"/>
</front>
<seriesInfo name="BCP" value="166"/>
<seriesInfo name="RFC" value="6365"/>
</reference>
<reference anchor="draft-ietf-httpbis-p7-auth">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
<author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
<organization abbrev="Adobe">Adobe Systems Incorporated</organization>
<address><email>fielding@gbiv.com</email></address>
</author>
<author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
<organization abbrev="greenbytes">greenbytes GmbH</organization>
<address><email>julian.reschke@greenbytes.de</email></address>
</author>
<date month="November" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-25"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2831">
<front>
<title>Using Digest Authentication as a SASL Mechanism</title>
<author initials="P." surname="Leach" fullname="P. Leach"/>
<author initials="C." surname="Newman" fullname="C. Newman"/>
<date year="2000" month="May"/>
</front>
<seriesInfo name="RFC" value="2831"/>
</reference>
<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>
<reference anchor="XHR" target="http://www.w3.org/TR/2014/WD-XMLHttpRequest-20140130/">
<front>
<title>XMLHttpRequest Level 1</title>
<author fullname="Anne van Kesteren" surname="van Kesteren" initials="A."/>
<author fullname="Hallvord Steen" surname="Steen" initials="H."/>
<author fullname="Julian Aubourg" surname="Aubourg" initials="J."/>
<author fullname="Jungkee Song" surname="Song" initials="J."/>
<date year="2014" month="January" day="30"/>
</front>
<seriesInfo name="W3C Working Draft" value="WD-XMLHttpRequest-20140130"/>
<annotation>
Latest version available at
<eref target="http://www.w3.org/TR/XMLHttpRequest/"/>.
</annotation>
</reference>
</references>
<section title="Deployment Considerations">
<section title="User Agents">
<t>
User agents not implementing this specification should continue to work as
before, ignoring the new parameter.
</t>
<t>
User agents which already default to the UTF-8 encoding implement
this specification by definition.
Note that some user agents also have different defaults depending
on whether the request originates from page navigation as opposed to a
script-driven request using XMLHttpRequest <xref target="XHR"/>.
</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 scheme based
on the user's credentials: if they do not need any characters outside
the ISO-8859-1 character repertoire, 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>
<t>
Note that there's a risk if the site blocks an account after multiple login
failures (for instance, when it doesn't reset the counter after a successful
login).
</t>
</section>
</section>
<section title="Origin Servers">
<t>
Origin servers that do not support 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 or as badly 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>
The Digest scheme has similar issues with respect to internationalization.
The HTTPAuth Working Group is chartered to address this problem as well,
and the solution might be very similar.
</t>
</section>
<section title="Will existing UAs ignore the parameter?">
<t>
It appears they will. See <eref target="http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1"/>
and <eref target="http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2"/>.
</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 title="Since draft-reschke-basicauth-enc-01">
<t>
Note more recent Mozilla bugzilla entry; add behavior of existing UAs
to FAQ (with pointer to test cases).
</t>
</section>
<section title="Since draft-reschke-basicauth-enc-02">
<t>
Add and resolve issue "xhrutf8".
</t>
</section>
<section title="Since draft-reschke-basicauth-enc-03">
<t>
Add and resolve issue "proxy".
</t>
</section>
<section title="Since draft-reschke-basicauth-enc-04">
<t>
Add and resolve issues "paramname" and "sentparam".
Add issues
"terminology" and
"unorm".
Update HTTPbis reference.
</t>
</section>
<section title="Since draft-reschke-basicauth-enc-05">
<t>
Update HTTPbis reference.
</t>
</section>
<section title="Since draft-reschke-basicauth-enc-06">
<t>
Update HTTPbis and XHR references.
</t>
</section>
<section title="Since draft-reschke-basicauth-enc-07">
<t>
"b64token" -> "token68" (ABNF term changed in HTTPbis P7).
Change contact information from HTTPbis WG to HTTPAUTH WG.
Add issue parmname2831.
Changed intended status to "experimental".
</t>
</section>
<section title="Since draft-reschke-basicauth-enc-08" anchor="changes.since.old.08">
<t>
Made it a draft of the IETF HTTPauth Working Group.
</t>
</section>
<section title="Since draft-ietf-httpauth-basicauth-enc-00" anchor="changes.since.00">
<t>
Clarify what encoding step the charset selection applies to.
</t>
<t>
Use RFC 6365 terminology.
</t>
<t>
Rename the parameter to "charset" for consistency with RFC 2831.
</t>
</section>
<section title="Since draft-ietf-httpauth-basicauth-enc-01" anchor="changes.since.01">
<t>
Update httpbis and XHR references. Add a note about draft-ietf-httpauth-basicauth-update.
</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 title="unorm"><t>
Type: edit</t><t>julian.reschke@greenbytes.de (2012-02-02):
We need a statement about unicode normalization forms.
</t></section></section></back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:36:16 |