An Encoding Parameter for HTTP Basic Authentication

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.¶

This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding scheme 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 5, 2014.¶

Copyright (c) 2014 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.¶

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 scheme to use.¶

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 ([USASCII], [ISO-8859-1]), and even less interoperability for any characters beyond that.¶

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 [draft-ietf-httpbis-p7-auth].¶

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 [RFC2119].¶

The terms (character) repertoire and character encoding scheme are defined in Section 2 of [RFC6365].¶

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" ([RFC2617], Section 2).¶

The only allowed value is "UTF-8", to be matched case-insensitively (see [RFC2978], Section 2.3). It indicates that the server expects user name and password to be converted to Unicode Normalization Form C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets using the UTF-8 character encoding scheme ([RFC3629]).¶

Other values are reserved for future use.¶

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:

WWW-Authenticate: Basic realm="foo", charset="UTF-8"

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.

This document does not introduce any new security considerations beyond those defined for the "Basic" authentication scheme ([RFC2617], Section 4), and those applicable to the handling of UTF-8 ([RFC3629], Section 10).¶

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.¶

Thanks to Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Manger, Yaron Sheffer, Michael Sweet, and Martin Thomson for providing feedback on this document.¶