idnits 2.17.1 draft-reschke-basicauth-enc-08.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 ([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 (May 8, 2013) is 3999 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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) May 8, 2013 5 Intended status: Experimental 6 Expires: November 9, 2013 8 An Encoding Parameter for HTTP Basic Authentication 9 draft-reschke-basicauth-enc-08 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 the non-ASCII characters in the 18 ISO-8859-1 character set, and even less interoperability for any 19 characters 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 HTTPAUTH Working Group, comments should be sent to 29 the HTTPAUTH WG's mailing list at http-auth@ietf.org [1], which may 30 be joined using the form at 31 . 33 Discussions of the HTTPAUTH Working Group are archived at . 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 November 9, 2013. 57 Copyright Notice 59 Copyright (c) 2013 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 'accept-charset' 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 . . . . . . . . . . . . . . . . . . 7 84 Appendix A. Deployment Considerations . . . . . . . . . . . . . . 7 85 A.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 7 86 A.1.1. Alternative approach . . . . . . . . . . . . . . . . . 7 87 A.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . 9 97 C.3. Since draft-reschke-basicauth-enc-02 . . . . . . . . . . . 9 98 C.4. Since draft-reschke-basicauth-enc-03 . . . . . . . . . . . 9 99 C.5. Since draft-reschke-basicauth-enc-04 . . . . . . . . . . . 9 100 C.6. Since draft-reschke-basicauth-enc-05 . . . . . . . . . . . 9 101 C.7. Since draft-reschke-basicauth-enc-06 . . . . . . . . . . . 9 102 C.8. Since draft-reschke-basicauth-enc-07 . . . . . . . . . . . 9 103 Appendix D. Open issues (to be removed by RFC Editor prior to 104 publication) . . . . . . . . . . . . . . . . . . . . 9 105 D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 106 D.2. unorm . . . . . . . . . . . . . . . . . . . . . . . . . . 9 107 D.3. terminology . . . . . . . . . . . . . . . . . . . . . . . 10 108 D.4. parmname2831 . . . . . . . . . . . . . . . . . . . . . . . 10 110 1. Introduction 112 The "Basic" authentication scheme defined in Section 2 of [RFC2617] 113 does not properly define how to treat non-ASCII characters 114 ([USASCII]): it uses the Base64 ([RFC4648], Section 4) encoding of 115 the concatenation of username, separator character, and password 116 without stating which character encoding to use. 118 This has lead to a situation where user agent implementations 119 disagree, and servers make different assumptions based on the locales 120 they are running in. There is little interoperability for the non- 121 ASCII characters in the ISO-8859-1 character set ([USASCII], 122 [ISO-8859-1]), and even less interoperability for any characters 123 beyond that. 125 This document defines a backwards-compatible extension to "Basic", 126 specifying the server's character encoding expectation, using a new 127 auth-param for use in the Proxy-Authenticate and WWW-Authenticate 128 header fields, as defined in [draft-ietf-httpbis-p7-auth]. 130 2. Notational Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. The 'accept-charset' auth-param 138 In challenges, servers MAY use the "accept-charset" authentication 139 parameter (case-insensitive) to express the character encoding they 140 expect the user agent to use. 142 The only allowed value is "UTF-8", to be matched case-insensitively 143 (see [RFC2978], Section 2.3), indicating that the server expects the 144 UTF-8 character encoding to be used ([RFC3629]). 146 Other values are reserved for future use. 148 Note: The 'accept-charset' parameter cannot be included when 149 sending credentials (e.g. in the Authorization or Proxy- 150 Authorization header fields), as the "Basic" scheme uses a single 151 token for credentials ('token68' syntax), not a parameter list 152 ('#auth-param' syntax); see Section 2.1 of 153 [draft-ietf-httpbis-p7-auth]. 155 4. Examples 157 In the example below, the server prompts for authentication in the 158 "foo" realm, using Basic authentication, with a preference for the 159 UTF-8 character encoding: 161 WWW-Authenticate: Basic realm="foo", accept-charset="UTF-8" 163 Note that the parameter value can be either a token or a quoted 164 string; in this case the server chose to use the quoted-string 165 notation. 167 The user's name is "test", and his password is the string "123" 168 followed by the Unicode character U+00A3 (POUND SIGN). Following 169 Section 1.2 of [RFC2617], but using the character encoding UTF-8, the 170 user-pass, converted to a sequence of octets, is: 172 't' 'e' 's' 't' ':' '1' '2' '3' pound 173 74 65 73 74 3A 31 32 33 C2 A3 175 Encoding this octet sequence in Base64 ([RFC4648], Section 4) yields: 177 dGVzdDoxMjPCow== 179 Thus the Authorization header field would be: 181 Authorization: Basic dGVzdDoxMjPCow== 183 Or, for proxy authentication: 185 Proxy-Authorization: Basic dGVzdDoxMjPCow== 187 5. Security Considerations 189 This document does not introduce any new security considerations 190 beyond those defined for the "Basic" authentication scheme 191 ([RFC2617], Section 4), and those applicable to the handling of UTF-8 192 ([RFC3629], Section 10). 194 6. IANA Considerations 196 There are no IANA Considerations related to this specification. 198 7. Acknowledgements 200 The internationalisation problem has been reported as a Mozilla bug 201 back in the year 2000 (see 202 and also the 203 more recent ). 204 It was Andrew Clover's idea to address it using a new auth-param. 206 Thanks to Bjoern Hoehrmann, Amos Jeffries, James Manger, and Martin 207 Thomson for providing feedback on this document. 209 8. References 211 8.1. Normative References 213 [ISO-8859-1] International Organization for 214 Standardization, "Information 215 technology -- 8-bit single-byte coded 216 graphic character sets -- Part 1: Latin 217 alphabet No. 1", ISO/IEC 8859-1:1998, 218 1998. 220 [RFC2119] Bradner, S., "Key words for use in RFCs 221 to Indicate Requirement Levels", 222 BCP 14, RFC 2119, March 1997. 224 [RFC2617] Franks, J., Hallam-Baker, P., 225 Hostetler, J., Lawrence, S., Leach, P., 226 Luotonen, A., and L. Stewart, "HTTP 227 Authentication: Basic and Digest Access 228 Authentication", RFC 2617, June 1999. 230 [RFC2978] Freed, N. and J. Postel, "IANA Charset 231 Registration Procedures", BCP 19, 232 RFC 2978, October 2000. 234 [RFC3629] Yergeau, F., "UTF-8, a transformation 235 format of ISO 10646", STD 63, RFC 3629, 236 November 2003. 238 [USASCII] American National Standards Institute, 239 "Coded Character Set -- 7-bit American 240 Standard Code for Information 241 Interchange", ANSI X3.4, 1986. 243 [draft-ietf-httpbis-p7-auth] Fielding, R., Ed. and J. Reschke, Ed., 244 "Hypertext Transfer Protocol 245 (HTTP/1.1): Authentication", 246 draft-ietf-httpbis-p7-auth-22 (work in 247 progress), February 2013. 249 8.2. Informative References 251 [RFC4648] Josefsson, S., "The Base16, Base32, and 252 Base64 Data Encodings", RFC 4648, 253 October 2006. 255 [XHR] Aubourg, J., Song, J., and H. Steen, 256 "XMLHttpRequest", W3C Working Draft WD- 257 XMLHttpRequest-20121206, December 2012, 258 . 261 Latest version available at 262 . 264 URIs 266 [1] 268 Appendix A. Deployment Considerations 270 A.1. User Agents 272 User agents not implementing this specifications should continue to 273 work as before, ignoring the new parameter. 275 User agents which already default to the UTF-8 encoding implement 276 this specification by definition. Note that some user agents also 277 have different defaults depending on whether the request originates 278 from page navigation as opposed to a script-driven request using 279 XMLHttpRequest [XHR]. 281 Other user agents can keep their default behavior, and switch to 282 UTF-8 when seeing the new parameter. 284 A.1.1. Alternative approach 286 On the other hand, the strategy below may already improve the user- 287 visible behavior today: 289 o In the first authentication request, choose the character encoding 290 based on the user's credentials: if they do not need any 291 characters outside the ISO-8859-1 character set, default to ISO- 292 8859-1, otherwise use UTF-8. 294 o If the first attempt failed and the encoding used was ISO-8859-1, 295 retry once with UTF-8 encoding instead. 297 Note that there's a risk if the site blocks an account after multiple 298 login failures (for instance, when it doesn't reset the counter after 299 a successful login). 301 A.2. Origin Servers 303 Origin servers that do not support non-ASCII characters in 304 credentials do not require any changes. 306 Origin servers that need to support non-ASCII characters, but can't 307 use the UTF-8 encoding will not be affected; they will continue to 308 function as well as before. 310 Finally, origin servers that need to support non-ASCII characters and 311 can use the UTF-8 encoding can opt in as described above. In the 312 worst case, they'll continue to see either broken credentials or no 313 credentials at all (depending on how legacy clients handle characters 314 they can not encode). 316 Appendix B. FAQ (to be removed by RFC Editor before publication) 318 B.1. Why not simply switch the default encoding to UTF-8? 320 There are sites in use today that default to a locale encoding, such 321 as ISO-8859-1, and expect user agents to use that encoding. These 322 sites will break if the user agent uses a different encoding, such as 323 UTF-8. 325 B.2. What about Digest? 327 Although the solution proposed in this document may be applicable to 328 "Digest" as well, any attempt to update this scheme may be an uphill 329 battle hard to win. 331 B.3. Will existing UAs ignore the parameter? 333 It appears they will. See 334 and 335 . 337 Appendix C. Change Log (to be removed by RFC Editor before publication) 339 C.1. Since draft-reschke-basicauth-enc-00 341 Add and close issues "credparam" and "paramcase". Rewrite the 342 deployment considerations. 344 C.2. Since draft-reschke-basicauth-enc-01 346 Note more recent Mozilla bugzilla entry; add behavior of existing UAs 347 to FAQ (with pointer to test cases). 349 C.3. Since draft-reschke-basicauth-enc-02 351 Add and resolve issue "xhrutf8". 353 C.4. Since draft-reschke-basicauth-enc-03 355 Add and resolve issue "proxy". 357 C.5. Since draft-reschke-basicauth-enc-04 359 Add and resolve issues "paramname" and "sentparam". Add issues 360 "terminology" and "unorm". Update HTTPbis reference. 362 C.6. Since draft-reschke-basicauth-enc-05 364 Update HTTPbis reference. 366 C.7. Since draft-reschke-basicauth-enc-06 368 Update HTTPbis and XHR references. 370 C.8. Since draft-reschke-basicauth-enc-07 372 "b64token" -> "token68" (ABNF term changed in HTTPbis P7). Change 373 contact information from HTTPbis WG to HTTPAUTH WG. Add issue 374 parmname2831. Changed intended status to "experimental". 376 Appendix D. Open issues (to be removed by RFC Editor prior to 377 publication) 379 D.1. edit 381 Type: edit 383 julian.reschke@greenbytes.de (2010-08-11): Umbrella issue for 384 editorial fixes/enhancements. 386 D.2. unorm 388 Type: edit 390 julian.reschke@greenbytes.de (2012-02-02): We need a statement about 391 unicode normalization forms. 393 D.3. terminology 395 Type: edit 397 julian.reschke@greenbytes.de (2012-02-02): Try to be consistent with 398 the terminology defined in RFC 6365. 400 D.4. parmname2831 402 In Section 3: 404 Type: change 406 julian.reschke@greenbytes.de (2012-05-08): RFC 2831 (Digest SASL 407 Mechanism) defines a *very* similar parameter but calls it "charset". 408 We may want to be consistent with that. 410 Author's Address 412 Julian F. Reschke 413 greenbytes GmbH 414 Hafenweg 16 415 Muenster, NW 48155 416 Germany 418 EMail: julian.reschke@greenbytes.de 419 URI: http://greenbytes.de/tech/webdav/