idnits 2.17.1
draft-reschke-basicauth-enc-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([2], [1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
-- The draft header indicates that this document updates RFC2617, but the
abstract doesn't seem to directly say this. It does mention RFC2617
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC2617, updated by this document, for
RFC5378 checks: 1997-12-01)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (January 25, 2012) is 4474 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1'
** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
RFC 7616, RFC 7617)
-- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII'
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Reschke
3 Internet-Draft greenbytes
4 Updates: 2617 (if approved) January 25, 2012
5 Intended status: Standards Track
6 Expires: July 28, 2012
8 An Encoding Parameter for HTTP Basic Authentication
9 draft-reschke-basicauth-enc-03
11 Abstract
13 The "Basic" authentication scheme defined in RFC 2617 does not
14 properly define how to treat non-ASCII characters. This has lead to
15 a situation where user agent implementations disagree, and servers
16 make different assumptions based on the locales they are running in.
17 There is little interoperability for characters in the ISO-8859-1
18 character set, and even less interoperability for any characters
19 beyond that.
21 This document defines a backwards-compatible extension to "Basic",
22 specifying the server's character encoding expectation, using a new
23 authentication scheme parameter.
25 Editorial Note (To be removed by RFC Editor before publication)
27 Distribution of this document is unlimited. Although this is not a
28 work item of the HTTPbis Working Group, comments should be sent to
29 the Hypertext Transfer Protocol (HTTP) mailing list at
30 ietf-http-wg@w3.org [1], which may be joined by sending a message
31 with subject "subscribe" to ietf-http-wg-request@w3.org [2].
33 Discussions of the HTTPbis Working Group are archived at
34 .
36 XML versions, latest edits and the issues list for this document are
37 available from
38 .
40 Status of This Memo
42 This Internet-Draft is submitted in full conformance with the
43 provisions of BCP 78 and BCP 79.
45 Internet-Drafts are working documents of the Internet Engineering
46 Task Force (IETF). Note that other groups may also distribute
47 working documents as Internet-Drafts. The list of current Internet-
48 Drafts is at http://datatracker.ietf.org/drafts/current/.
50 Internet-Drafts are draft documents valid for a maximum of six months
51 and may be updated, replaced, or obsoleted by other documents at any
52 time. It is inappropriate to use Internet-Drafts as reference
53 material or to cite them other than as "work in progress."
55 This Internet-Draft will expire on July 28, 2012.
57 Copyright Notice
59 Copyright (c) 2012 IETF Trust and the persons identified as the
60 document authors. All rights reserved.
62 This document is subject to BCP 78 and the IETF Trust's Legal
63 Provisions Relating to IETF Documents
64 (http://trustee.ietf.org/license-info) in effect on the date of
65 publication of this document. Please review these documents
66 carefully, as they describe your rights and restrictions with respect
67 to this document. Code Components extracted from this document must
68 include Simplified BSD License text as described in Section 4.e of
69 the Trust Legal Provisions and are provided without warranty as
70 described in the Simplified BSD License.
72 Table of Contents
74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
75 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4
76 3. The 'encoding' auth-param . . . . . . . . . . . . . . . . . . . 4
77 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
78 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
83 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
84 Appendix A. Deployment Considerations . . . . . . . . . . . . . . 7
85 A.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . . 7
86 A.1.1. Alternative approach . . . . . . . . . . . . . . . . . 7
87 A.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 7
88 Appendix B. FAQ (to be removed by RFC Editor before
89 publication) . . . . . . . . . . . . . . . . . . . . . 8
90 B.1. Why not simply switch the default encoding to UTF-8? . . . 8
91 B.2. What about Digest? . . . . . . . . . . . . . . . . . . . . 8
92 B.3. Will existing UAs ignore the parameter? . . . . . . . . . . 8
93 Appendix C. Change Log (to be removed by RFC Editor before
94 publication) . . . . . . . . . . . . . . . . . . . . . 8
95 C.1. Since draft-reschke-basicauth-enc-00 . . . . . . . . . . . 8
96 C.2. Since draft-reschke-basicauth-enc-01 . . . . . . . . . . . 8
97 C.3. Since draft-reschke-basicauth-enc-02 . . . . . . . . . . . 8
99 Appendix D. Open issues (to be removed by RFC Editor prior to
100 publication) . . . . . . . . . . . . . . . . . . . . . 8
101 D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
103 1. Introduction
105 The "Basic" authentication scheme defined in Section 2 of [RFC2617]
106 does not properly define how to treat non-ASCII characters
107 ([USASCII]): it uses the Base64 ([RFC4648], Section 4) encoding of
108 the concatenation of username, separator character, and password
109 without stating which character encoding to use.
111 This has lead to a situation where user agent implementations
112 disagree, and servers make different assumptions based on the locales
113 they are running in. There is little interoperability for characters
114 in the ISO-8859-1 character set ([ISO-8859-1]), and even less
115 interoperability for any characters beyond that.
117 This document defines a backwards-compatible extension to "Basic",
118 specifying the server's character encoding expectation, using a new
119 auth-param as defined in Section 1.2 of [RFC2617].
121 2. Notational Conventions
123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
125 document are to be interpreted as described in [RFC2119].
127 3. The 'encoding' auth-param
129 In challenges, servers MAY use the "encoding" authentication
130 parameter (case-insensitive) to express the character encoding they
131 expect the user agent to use.
133 The only allowed value is "UTF-8", to be matched case-insensitively
134 (see [RFC2978], Section 2.3), indicating that the server expects the
135 UTF-8 character encoding to be used ([RFC3629]).
137 Other values are reserved for future use.
139 For credentials sent by the user agent, the "encoding" parameter is
140 reserved for future use and MUST NOT be sent.
142 The reason for this is that the information that could be included
143 does not seem to be useful to the server, but the additional
144 complexity of parsing and processing the additional parameter might
145 make this extension harder to deploy.
147 4. Examples
149 In the example below, the server prompts for authentication in the
150 "foo" realm, using Basic authentication, with a preference for the
151 UTF-8 character encoding:
153 WWW-Authenticate: Basic realm="foo", encoding="UTF-8"
155 Note that the parameter value can be either a token or a quoted
156 string; in this case the server chose to use the quoted-string
157 notation.
159 The user's name is "test", and his password is the string "123"
160 followed by the Unicode character U+00A3 (POUND SIGN). Following
161 Section 1.2 of [RFC2617], but using the character encoding UTF-8, the
162 user-pass, converted to a sequence of octets, is:
164 't' 'e' 's' 't' ':' '1' '2' '3' pound
165 74 65 73 74 3A 31 32 33 C2 A3
167 Encoding this octet sequence in Base64 ([RFC4648], Section 4) yields:
169 dGVzdDoxMjPCow==
171 Thus the Authorization header field would be:
173 Authorization: Basic dGVzdDoxMjPCow==
175 5. Security Considerations
177 This document does not introduce any new security considerations
178 beyond those defined for the "Basic" authentication scheme
179 ([RFC2617], Section 4), and those applicable to the handling of UTF-8
180 ([RFC3629], Section 10).
182 6. IANA Considerations
184 There are no IANA Considerations related to this specification.
186 7. Acknowledgements
188 The internationalisation problem has been reported as a Mozilla bug
189 back in the year 2000 (see
190 and also the
191 more recent ).
192 It was Andrew Clover's idea to address it using a new auth-param.
194 Thanks to Martin Thomson for providing feedback on this document.
196 8. References
198 8.1. Normative References
200 [ISO-8859-1] International Organization for Standardization,
201 "Information technology -- 8-bit single-byte coded
202 graphic character sets -- Part 1: Latin alphabet No.
203 1", ISO/IEC 8859-1:1998, 1998.
205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
206 Requirement Levels", BCP 14, RFC 2119, March 1997.
208 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
209 S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
210 Authentication: Basic and Digest Access
211 Authentication", RFC 2617, June 1999.
213 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
214 Procedures", BCP 19, RFC 2978, October 2000.
216 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
217 10646", STD 63, RFC 3629, November 2003.
219 [USASCII] American National Standards Institute, "Coded Character
220 Set -- 7-bit American Standard Code for Information
221 Interchange", ANSI X3.4, 1986.
223 8.2. Informative References
225 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
226 Encodings", RFC 4648, October 2006.
228 [XHR] van Kesteren, A., "XMLHttpRequest Level 2", W3C Working
229 Draft WD-XMLHttpRequest2-20110816, August 2011, .
232 Latest version available at
233 .
235 URIs
237 [1]
239 [2]
241 Appendix A. Deployment Considerations
243 A.1. User Agents
245 User agents not implementing this specifications should continue to
246 work as before, ignoring the new parameter.
248 User agents which already default to the UTF-8 encoding already
249 implement this specification by definition. Note that some user
250 agents already have different defaults depending on whether the
251 request originates from page navigation as opposed to a script-driven
252 request using XMLHttpRequest [XHR].
254 Other user agents can keep their default behavior, and switch to
255 UTF-8 when seeing the new parameter.
257 A.1.1. Alternative approach
259 On the other hand, the strategy below may already improve the user-
260 visible behavior today:
262 o In the first authentication request, choose the character encoding
263 based on the user's credentials: if they do not need any
264 characters outside the ISO-8859-1 character set, default to ISO-
265 8859-1, otherwise use UTF-8.
267 o If the first attempt failed and the encoding used was ISO-8859-1,
268 retry once with UTF-8 encoding instead.
270 Note that there's a risk if the site blocks an account after multiple
271 login failures (for instance, when it doesn't reset the counter after
272 a successful login).
274 A.2. Origin Servers
276 Origin servers that do not support non-ASCII characters in
277 credentials do not require any changes.
279 Origin servers that need to support non-ASCII characters, but can't
280 use the UTF-8 encoding will not be affected; they will continue to
281 function as well as before.
283 Finally, origin servers that need to support non-ASCII characters and
284 can use the UTF-8 encoding can opt in as described above. In the
285 worst case, they'll continue to see either broken credentials or no
286 credentials at all (depending on how legacy clients handle characters
287 they can not encode).
289 Appendix B. FAQ (to be removed by RFC Editor before publication)
291 B.1. Why not simply switch the default encoding to UTF-8?
293 There are sites in use today that default to a locale encoding, such
294 as ISO-8859-1, and expect user agents to use that encoding. These
295 sites will break if the user agent uses a different encoding, such as
296 UTF-8.
298 B.2. What about Digest?
300 Although the solution proposed in this document may be applicable to
301 "Digest" as well, any attempt to update this scheme may be an uphill
302 battle hard to win.
304 B.3. Will existing UAs ignore the parameter?
306 It appears they will. See
307 and
308 .
310 Appendix C. Change Log (to be removed by RFC Editor before publication)
312 C.1. Since draft-reschke-basicauth-enc-00
314 Add and close issues "credparam" and "paramcase". Rewrite the
315 deployment considerations.
317 C.2. Since draft-reschke-basicauth-enc-01
319 Note more recent Mozilla bugzilla entry; add behavior of existing UAs
320 to FAQ (with pointer to test cases).
322 C.3. Since draft-reschke-basicauth-enc-02
324 Add and resolve issue "xhrutf8".
326 Appendix D. Open issues (to be removed by RFC Editor prior to
327 publication)
329 D.1. edit
331 Type: edit
333 julian.reschke@greenbytes.de (2010-08-11): Umbrella issue for
334 editorial fixes/enhancements.
336 Author's Address
338 Julian F. Reschke
339 greenbytes GmbH
340 Hafenweg 16
341 Muenster, NW 48155
342 Germany
344 EMail: julian.reschke@greenbytes.de
345 URI: http://greenbytes.de/tech/webdav/