Network Working Group J. Reschke
Internet-Draft greenbytes
Updates: 2617 (if approved) August 16, 2010
Intended status: Standards Track
Expires: February 17, 2011
An Encoding Parameter for HTTP Basic Authentication
draft-reschke-basicauth-enc-01
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 [1], which may be joined by sending a message
with subject "subscribe" to ietf-http-wg-request@w3.org [2].
Discussions of the HTTPbis Working Group are archived at
.
XML versions, latest edits and the issues list for this document are
available from
.
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/.
Reschke Expires February 17, 2011 [Page 1]
Internet-Draft Basic Auth Encoding Parameter August 2010
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 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. The 'encoding' auth-param . . . . . . . . . . . . . . . . . . . 4
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Deployment Considerations . . . . . . . . . . . . . . 6
A.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . . 6
A.1.1. Alternative approach . . . . . . . . . . . . . . . . . 7
A.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 7
Appendix B. FAQ (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . 7
B.1. Why not simply switch the default encoding to UTF-8? . . . 7
B.2. What about Digest? . . . . . . . . . . . . . . . . . . . . 7
Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . 8
C.1. Since draft-reschke-basicauth-enc-00 . . . . . . . . . . . 8
Appendix D. Resolved issues (to be removed by RFC Editor
before publication) . . . . . . . . . . . . . . . . . 8
D.1. paramcase . . . . . . . . . . . . . . . . . . . . . . . . . 8
Reschke Expires February 17, 2011 [Page 2]
Internet-Draft Basic Auth Encoding Parameter August 2010
D.2. credparam . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix E. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . . 8
E.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Reschke Expires February 17, 2011 [Page 3]
Internet-Draft Basic Auth Encoding Parameter August 2010
1. Introduction
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] 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.
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].
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].
3. The 'encoding' auth-param
In challenges, servers MAY use the "encoding" authentication
parameter (case-insensitive) to express the character encoding they
expect the user agent to use.
The only allowed value is "UTF-8", to be matched case-insensitively
(see [RFC2978], Section 2.3), indicating that the server expects the
UTF-8 character encoding to be used ([RFC3629]).
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.
Reschke Expires February 17, 2011 [Page 4]
Internet-Draft Basic Auth Encoding Parameter August 2010
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], 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]) 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], Section 4), and those applicable to the handling of UTF-8
([RFC3629], 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
). It was Andrew
Clover's idea to address it using a new auth-param.
Thanks to Martin Thomson for providing feedback on this document.
Reschke Expires February 17, 2011 [Page 5]
Internet-Draft Basic Auth Encoding Parameter August 2010
8. References
8.1. Normative References
[ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, STD 63, November 2003.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
8.2. Informative References
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
URIs
[1]
[2]
Appendix A. Deployment Considerations
A.1. User Agents
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 already
implement this specification by definition.
Reschke Expires February 17, 2011 [Page 6]
Internet-Draft Basic Auth Encoding Parameter August 2010
Other user agents can keep their default behavior, and switch to
UTF-8 when seeing the new parameter.
A.1.1. Alternative approach
On the other hand, the strategy below may already improve the user-
visible behavior today:
o 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.
o 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 do not expect 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).
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" as well, any attempt to update this scheme may be an uphill
battle hard to win.
Reschke Expires February 17, 2011 [Page 7]
Internet-Draft Basic Auth Encoding Parameter August 2010
Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since draft-reschke-basicauth-enc-00
Add and close issues "credparam" and "paramcase". Rewrite the
deployment considerations.
Appendix D. Resolved issues (to be removed by RFC Editor before
publication)
Issues that were either rejected or resolved in this version of this
document.
D.1. paramcase
Type: change
julian.reschke@greenbytes.de (2010-08-12): Are auth param names case-
sensitive?
Resolution (2010-08-12): Be consistent with "realm" (case-
insensitive). Note that should be clarified in RFC2617bis for auth
params in general.
D.2. credparam
Type: change
julian.reschke@greenbytes.de (2010-08-12): Should "encoding" also be
defined for the credentials (the UA's response)?
Resolution: Disallow (but reserve) encoding in credentials, and
explain why this is the case.
Appendix E. Open issues (to be removed by RFC Editor prior to
publication)
E.1. edit
Type: edit
julian.reschke@greenbytes.de (2010-08-11): Umbrella issue for
editorial fixes/enhancements.
Reschke Expires February 17, 2011 [Page 8]
Internet-Draft Basic Auth Encoding Parameter August 2010
Author's Address
Julian F. Reschke
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Reschke Expires February 17, 2011 [Page 9]