draft-ietf-httpauth-basicauth-enc-02.txt   draft-ietf-httpauth-basicauth-enc-03.txt 
HTTPAuth Working Group J. Reschke HTTPAuth Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Updates: 2617 (if approved) February 4, 2014 Updates: 2617 (if approved) March 4, 2014
Intended status: Experimental Intended status: Experimental
Expires: August 8, 2014 Expires: September 5, 2014
An Encoding Parameter for HTTP Basic Authentication An Encoding Parameter for HTTP Basic Authentication
draft-ietf-httpauth-basicauth-enc-02 draft-ietf-httpauth-basicauth-enc-03
Abstract Abstract
The "Basic" authentication scheme defined in RFC 2617 does not The "Basic" authentication scheme defined in RFC 2617 does not
properly define how to treat non-ASCII characters. This has led to a properly define how to treat non-ASCII characters. This has led to a
situation where user agent implementations disagree, and servers make situation where user agent implementations disagree, and servers make
different assumptions based on the locales they are running in. different assumptions based on the locales they are running in.
There is little interoperability for the non-ASCII characters in the There is little interoperability for the non-ASCII characters in the
ISO-8859-1 character repertoire, and even less interoperability for ISO-8859-1 character repertoire, and even less interoperability for
any characters beyond that. any characters beyond that.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Discussion of this draft takes place on the HTTPAuth working group Discussion of this draft takes place on the HTTPAuth working group
mailing list (http-auth@ietf.org), which is archived at <http:// mailing list (http-auth@ietf.org), which is archived at <http://
www.ietf.org/mail-archive/web/http-auth/current/maillist.html>. www.ietf.org/mail-archive/web/http-auth/current/maillist.html>.
XML versions, latest edits and the issues list for this document are XML versions, latest edits and the issues list for this document are
available from available from
<http://greenbytes.de/tech/ <http://greenbytes.de/tech/
webdav/#draft-ietf-httpauth-basicauth-enc>. webdav/#draft-ietf-httpauth-basicauth-enc>.
The changes in this draft are summarized in Appendix C.11. The changes in this draft are summarized in Appendix C.12.
The contents of this document will likely be included into the new The contents of this document will likely be included into the new
specification of the "Basic" scheme, see specification of the "Basic" scheme, see
<http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update>. <http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update>.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2014. This Internet-Draft will expire on September 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
3. The 'charset' auth-param . . . . . . . . . . . . . . . . . . . 4 3. The 'charset' auth-param . . . . . . . . . . . . . . . . . . . 4
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Deployment Considerations . . . . . . . . . . . . . . 7 Appendix A. Deployment Considerations . . . . . . . . . . . . . . 7
A.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 7 A.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 7
A.1.1. Alternative approach . . . . . . . . . . . . . . . . . 8 A.1.1. Alternative approach . . . . . . . . . . . . . . . . . 8
A.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 8 A.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. FAQ (to be removed by RFC Editor before Appendix B. FAQ (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 8 publication) . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 39 skipping to change at page 3, line 39
C.2. Since draft-reschke-basicauth-enc-01 . . . . . . . . . . . 9 C.2. Since draft-reschke-basicauth-enc-01 . . . . . . . . . . . 9
C.3. Since draft-reschke-basicauth-enc-02 . . . . . . . . . . . 9 C.3. Since draft-reschke-basicauth-enc-02 . . . . . . . . . . . 9
C.4. Since draft-reschke-basicauth-enc-03 . . . . . . . . . . . 9 C.4. Since draft-reschke-basicauth-enc-03 . . . . . . . . . . . 9
C.5. Since draft-reschke-basicauth-enc-04 . . . . . . . . . . . 9 C.5. Since draft-reschke-basicauth-enc-04 . . . . . . . . . . . 9
C.6. Since draft-reschke-basicauth-enc-05 . . . . . . . . . . . 9 C.6. Since draft-reschke-basicauth-enc-05 . . . . . . . . . . . 9
C.7. Since draft-reschke-basicauth-enc-06 . . . . . . . . . . . 9 C.7. Since draft-reschke-basicauth-enc-06 . . . . . . . . . . . 9
C.8. Since draft-reschke-basicauth-enc-07 . . . . . . . . . . . 9 C.8. Since draft-reschke-basicauth-enc-07 . . . . . . . . . . . 9
C.9. Since draft-reschke-basicauth-enc-08 . . . . . . . . . . . 10 C.9. Since draft-reschke-basicauth-enc-08 . . . . . . . . . . . 10
C.10. Since draft-ietf-httpauth-basicauth-enc-00 . . . . . . . . 10 C.10. Since draft-ietf-httpauth-basicauth-enc-00 . . . . . . . . 10
C.11. Since draft-ietf-httpauth-basicauth-enc-01 . . . . . . . . 10 C.11. Since draft-ietf-httpauth-basicauth-enc-01 . . . . . . . . 10
Appendix D. Open issues (to be removed by RFC Editor prior to C.12. Since draft-ietf-httpauth-basicauth-enc-02 . . . . . . . . 10
Appendix D. Resolved issues (to be removed by RFC Editor
before publication) . . . . . . . . . . . . . . . . . 10
D.1. unorm . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix E. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 10 publication) . . . . . . . . . . . . . . . . . . . . 10
D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 E.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
D.2. unorm . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The "Basic" authentication scheme defined in Section 2 of [RFC2617] The "Basic" authentication scheme defined in Section 2 of [RFC2617]
does not properly define how to treat non-ASCII characters does not properly define how to treat non-ASCII characters
([USASCII]): it uses the Base64 ([RFC4648], Section 4) encoding of ([USASCII]): it uses the Base64 ([RFC4648], Section 4) encoding of
the concatenation of username, separator character, and password the concatenation of username, separator character, and password
without stating which character encoding scheme to use. without stating which character encoding scheme to use.
This has led to a situation where user agent implementations This has led to a situation where user agent implementations
skipping to change at page 4, line 43 skipping to change at page 4, line 43
defined in Section 2 of [RFC6365]. defined in Section 2 of [RFC6365].
3. The 'charset' auth-param 3. The 'charset' auth-param
In challenges, servers MAY use the "charset" authentication parameter In challenges, servers MAY use the "charset" authentication parameter
(case-insensitive) to indicate the character encoding scheme they (case-insensitive) to indicate the character encoding scheme they
expect the user agent to use when generating "user-pass" (a sequence expect the user agent to use when generating "user-pass" (a sequence
of octets) from "userid" and "password" ([RFC2617], Section 2). of octets) from "userid" and "password" ([RFC2617], Section 2).
The only allowed value is "UTF-8", to be matched case-insensitively The only allowed value is "UTF-8", to be matched case-insensitively
(see [RFC2978], Section 2.3), indicating that the server expects the (see [RFC2978], Section 2.3). It indicates that the server expects
UTF-8 character encoding scheme to be used ([RFC3629]). 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. Other values are reserved for future use.
Note: The 'charset' parameter cannot be included when sending Note: The 'charset' parameter cannot be included when sending
credentials (e.g. in the Authorization or Proxy-Authorization credentials (e.g. in the Authorization or Proxy-Authorization
header fields), as the "Basic" scheme uses a single token for header fields), as the "Basic" scheme uses a single token for
credentials ('token68' syntax), not a parameter list ('#auth- credentials ('token68' syntax), not a parameter list ('#auth-
param' syntax); see Section 2.1 of [draft-ietf-httpbis-p7-auth]. param' syntax); see Section 2.1 of [draft-ietf-httpbis-p7-auth].
Note: The name 'charset' has been chosen for consistency with Note: The name 'charset' has been chosen for consistency with
skipping to change at page 6, line 14 skipping to change at page 6, line 18
7. Acknowledgements 7. Acknowledgements
The internationalisation problem has been reported as a Mozilla bug The internationalisation problem has been reported as a Mozilla bug
back in the year 2000 (see back in the year 2000 (see
<https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the <https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the
more recent <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>). 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. It was Andrew Clover's idea to address it using a new auth-param.
Thanks to Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Thanks to Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James
Manger, Yaron Sheffer, and Martin Thomson for providing feedback on Manger, Yaron Sheffer, Michael Sweet, and Martin Thomson for
this document. providing feedback on this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ISO-8859-1] International Organization for [ISO-8859-1] International Organization for
Standardization, "Information Standardization, "Information
technology -- 8-bit single-byte coded technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin graphic character sets -- Part 1: Latin
alphabet No. 1", ISO/IEC 8859-1:1998, alphabet No. 1", ISO/IEC 8859-1:1998,
skipping to change at page 6, line 46 skipping to change at page 6, line 50
Authentication", RFC 2617, June 1999. Authentication", RFC 2617, June 1999.
[RFC2978] Freed, N. and J. Postel, "IANA Charset [RFC2978] Freed, N. and J. Postel, "IANA Charset
Registration Procedures", BCP 19, Registration Procedures", BCP 19,
RFC 2978, October 2000. RFC 2978, October 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC3629] Yergeau, F., "UTF-8, a transformation
format of ISO 10646", STD 63, RFC 3629, format of ISO 10646", STD 63, RFC 3629,
November 2003. November 2003.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode
Format for Network Interchange",
RFC 5198, March 2008.
[RFC6365] Hoffman, P. and J. Klensin, [RFC6365] Hoffman, P. and J. Klensin,
"Terminology Used in "Terminology Used in
Internationalization in the IETF", Internationalization in the IETF",
BCP 166, RFC 6365, September 2011. BCP 166, RFC 6365, September 2011.
[USASCII] American National Standards Institute, [USASCII] American National Standards Institute,
"Coded Character Set -- 7-bit American "Coded Character Set -- 7-bit American
Standard Code for Information Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[draft-ietf-httpbis-p7-auth] Fielding, R., Ed. and J. Reschke, Ed., [draft-ietf-httpbis-p7-auth] Fielding, R., Ed. and J. Reschke, Ed.,
"Hypertext Transfer Protocol "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-25 (work in draft-ietf-httpbis-p7-auth-26 (work in
progress), November 2013. progress), February 2014.
8.2. Informative References 8.2. Informative References
[RFC2831] Leach, P. and C. Newman, "Using Digest [RFC2831] Leach, P. and C. Newman, "Using Digest
Authentication as a SASL Mechanism", Authentication as a SASL Mechanism",
RFC 2831, May 2000. RFC 2831, May 2000.
[RFC4648] Josefsson, S., "The Base16, Base32, and [RFC4648] Josefsson, S., "The Base16, Base32, and
Base64 Data Encodings", RFC 4648, Base64 Data Encodings", RFC 4648,
October 2006. October 2006.
skipping to change at page 10, line 22 skipping to change at page 10, line 22
Use RFC 6365 terminology. Use RFC 6365 terminology.
Rename the parameter to "charset" for consistency with RFC 2831. Rename the parameter to "charset" for consistency with RFC 2831.
C.11. Since draft-ietf-httpauth-basicauth-enc-01 C.11. Since draft-ietf-httpauth-basicauth-enc-01
Update httpbis and XHR references. Add a note about Update httpbis and XHR references. Add a note about
draft-ietf-httpauth-basicauth-update. draft-ietf-httpauth-basicauth-update.
Appendix D. Open issues (to be removed by RFC Editor prior to C.12. Since draft-ietf-httpauth-basicauth-enc-02
publication)
D.1. edit Update httpbis reference. Close issue "unorm".
Type: edit Appendix D. Resolved issues (to be removed by RFC Editor before
publication)
julian.reschke@greenbytes.de (2010-08-11): Umbrella issue for Issues that were either rejected or resolved in this version of this
editorial fixes/enhancements. document.
D.2. unorm D.1. unorm
Type: edit Type: edit
julian.reschke@greenbytes.de (2012-02-02): We need a statement about julian.reschke@greenbytes.de (2012-02-02): We need a statement about
unicode normalization forms. unicode normalization forms.
Resolution: State that the expected normalization form is NFC.
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.
Author's Address Author's Address
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 18 change blocks. 
22 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/