Network Working Group                                         J. Reschke
Internet-Draft                                                greenbytes
Updates: 2617 (if approved)                              August 11, 2010
Intended status: Standards Track
Expires: February 12, 2011


          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 [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
   <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/.



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









Reschke                 Expires February 12, 2011               [Page 2]


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

   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], Section 2.3), indicating that the server expects the
   UTF-8 character encoding to be used ([RFC3629]).

   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.



Reschke                 Expires February 12, 2011               [Page 3]


Internet-Draft        Basic Auth Encoding Parameter          August 2010


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

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




Reschke                 Expires February 12, 2011               [Page 4]


Internet-Draft        Basic Auth Encoding Parameter          August 2010


   [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]  <mailto:ietf-http-wg@w3.org>

   [2]  <mailto:ietf-http-wg-request@w3.org?subject=subscribe>

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:

   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.







Reschke                 Expires February 12, 2011               [Page 5]


Internet-Draft        Basic Auth Encoding Parameter          August 2010


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

   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 12, 2011               [Page 6]