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 I ↓characters in the ISO-8859-1 character set, and even less interoperability for any characters beyond that.
This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding expectation, using a new authentication scheme parameter.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.
This Internet-Draft will expire on September 12, 2012.
Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 email@example.com, which may be joined by sending a message with subject "subscribe" to firstname.lastname@example.org.
Discussions of the HTTPbis Working Group are archived at <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
XML versions, latest edits and the issues list for this document are available from <http://greenbytes.de/tech/webdav/#draft-reschke-basicauth-enc>.
|I edit (type: edit, status: open)|
|email@example.com||2010-08-11||Umbrella issue for editorial fixes/enhancements.|
|Associated changes in this document: <#rfc.change.edit.1>, 1, 1, 1, 7, 7, C.|
|I unorm (type: edit, status: open)|
|firstname.lastname@example.org||2012-02-02||We need a statement about unicode normalization forms.|
|I terminology (type: edit, status: open)|
|email@example.com||2012-02-02||Try to be consistent with the terminology defined in RFC 6365.|
|I sentparam (type: change, status: closed)|
|James.H.Manger@team.telstra.com||2011-01-30||The text about not including the 'encoding' parameter when sending the password is a bit confusing [section 3]. (...) My guess is that the spec intended to say that including the encoding information *would* be useful, but it cannot be added easily. This is a good illustration of the 3rd dot point from "2.3.1 Considerations for new Authentication Schemes" [draft-ietf-httpbis-p7-auth-18#section-2.3.1]: "b64token ... can only be used once ... future extensions will be impossible".|
|Associated changes in this document: 3, 8.1.|
|I paramname (type: change, status: closed)|
|firstname.lastname@example.org||2012-01-30||... (in part due to the name, `useUTF8` or `use-utf-8="yes" or some such would have been clearer)|
|2012-03-11||Resolution: Switch to "accept-charset", so this is similar to the HTML form attribute.|
|Associated changes in this document: 3, 3, 4.|
The "Basic" authentication scheme defined in Section 2 of [RFC2617] does not properly define how to treat non-ASCII characters ([USASCII]): it uses the Base64 ([RFC4648], Section 4) encoding of the concatenation of username, separator character, and password without stating which character encoding to use.¶
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 (↑↓[ISO-8859-1]), and even less interoperability for any characters beyond that.¶
Other values are reserved for future use.¶
For credentials sent by the user agent, the "encoding" parameter is reserved for future use and MUST NOT be sent.
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.
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:
WWW-Authenticate: Basic realm="foo", ↑
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.
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 [RFC2617], but using the character encoding UTF-8, the user-pass, converted to a sequence of octets, is:¶
't' 'e' 's' 't' ':' '1' '2' '3' pound 74 65 73 74 3A 31 32 33 C2 A3
Thus the Authorization header field would be:¶
Authorization: Basic dGVzdDoxMjPCow==
Or, for proxy authentication:¶
Proxy-Authorization: Basic dGVzdDoxMjPCow==
There are no IANA Considerations related to this specification.¶
The internationalisation problem has been reported as a Mozilla bug back in the year 2000 (see <https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the more recent <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>). It was Andrew Clover's idea to address it using a new auth-param.¶
User agents not implementing this specifications should continue to work as before, ignoring the new parameter.¶
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 [XHR].¶
Other user agents can keep their default behavior, and switch to UTF-8 when seeing the new parameter.¶
On the other hand, the strategy below may already improve the user-visible behavior today: ¶
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).¶
Origin servers that do not support non-ASCII characters in credentials do not require any changes.¶
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.¶
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).¶
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.¶
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.¶
It appears they will. See <http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1> and <http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2>.¶
Add and close issues "credparam" and "paramcase". Rewrite the deployment considerations.¶
Note more recent Mozilla bugzilla entry; add behavior of existing UAs to FAQ (with pointer to test cases).¶
Add and resolve issue "xhrutf8".¶
Add and resolve issue "proxy".¶