An Encoding Parameter for HTTP Basic Authentication
draft-reschke-basicauth-enc-00

Abstract

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.

This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding expectation, using a new authentication scheme parameter.

Editorial Note (To be removed by RFC Editor before publication)

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 ietf-http-wg@w3.org, which may be joined by sending a message with subject "subscribe" to ietf-http-wg-request@w3.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.

Status of This Memo

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 February 12, 2011.

Copyright Notice

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

Table of Contents

1.  Introduction
2.  Notational Conventions
3.  The 'encoding' auth-param
4.  Examples
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Deployment Considerations
    A.1.  User Agents
    A.2.  Origin Servers
Appendix B.  FAQ (to be removed by RFC Editor before publication)
    B.1.  Why not simply switch the default encoding to UTF-8?
    B.2.  What about Digest?
    B.3.  What about a parameter for the credentials?

1.  Introduction

The "Basic" authentication scheme defined in Section 2 of [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) does not properly define how to treat non-ASCII characters ([USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.)): it uses the Base64 [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) 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] (International Organization for Standardization, “Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1,” 1998.)), and even less interoperability for any characters beyond that.

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 [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.).

2.  Notational Conventions

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  The 'encoding' auth-param

Servers MAY use the "encoding" authentication parameter to express the character encoding they expect the user agent to use. [case-sens] (Are parameter names case-sensitive?) [also-cred] (Should this also work as a parameter on the credentials? See Appendix B.3.)

The only allowed value is "UTF-8", to be matched case-insensitively (see [RFC2978] (Freed, N. and J. Postel, “IANA Charset Registration Procedures,” October 2000.), Section 2.3), indicating that the server expects the UTF-8 character encoding to be used ([RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.)).

Other values are reserved for future use.

4.  Examples

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", encoding="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.

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] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.), 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

Encoding this octet sequence in Base64 ([RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.)) yields:

  dGVzdDoxMjPCow==

Thus the Authorization header field would be:

  Authorization: Basic dGVzdDoxMjPCow==

5.  Security Considerations

This document does not introduce any new security considerations beyond those defined for the "Basic" authentication scheme ([RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.), Section 4), and those applicable to the handling of UTF-8 ([RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.), Section 10).

6.  IANA Considerations

There are no IANA Considerations related to this specification.

7.  Acknowledgements

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). It was Andrew Clover's idea to address it using a new auth-param.

Thanks to Martin Thomson for providing feedback on this document.

8.  References

8.1. Normative References

8.2. Informative References

Appendix A.  Deployment Considerations

A.1.  User Agents

User agents which already default to UTF-8 do not need to be changed at all. 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:

• 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.
• If the first attempt failed and the encoding used was ISO-8859-1, retry once with UTF-8 encoding instead.

A.2.  Origin Servers

Origin servers that expect ISO-8859-1 encoding do not require any changes. Other servers that already expect UTF-8 can add the new parameter without any risk of breaking existing user agents. [testme] (We may want to confirm this with test cases.)

Appendix B.  FAQ (to be removed by RFC Editor before publication)

B.1.  Why not simply switch the default encoding to UTF-8?

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.

B.2.  What about Digest?

Although the solution proposed in this document may be applicable to "Digest" is well, any attempt to update this scheme may be an uphill battle hard to win.

B.3.  What about a parameter for the credentials?

Defining a parameter on the credentials would make it easier for the server to find out what the client is sending. As far as clients only send the credentials parameter when the server opted-in through the challenge, there should be no interop issue.

This sounds like a nice-to-have, but doesn't seem to be really needed. Feedback appreciated.

Author's Address