idnits 2.17.1 draft-ietf-httpauth-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 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 (March 4, 2014) is 3706 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) -- Obsolete informational reference (is this intentional?): RFC 2831 (Obsoleted by RFC 6331) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAuth Working Group J. Reschke 3 Internet-Draft greenbytes 4 Updates: 2617 (if approved) March 4, 2014 5 Intended status: Experimental 6 Expires: September 5, 2014 8 An Encoding Parameter for HTTP Basic Authentication 9 draft-ietf-httpauth-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 led to a 15 situation where user agent implementations disagree, and servers make 16 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 repertoire, and even less interoperability for 19 any characters beyond that. 21 This document defines a backwards-compatible extension to "Basic", 22 specifying the server's character encoding scheme expectation, using 23 a new authentication scheme parameter. 25 Editorial Note (To be removed by RFC Editor before publication) 27 Discussion of this draft takes place on the HTTPAuth working group 28 mailing list (http-auth@ietf.org), which is archived at . 31 XML versions, latest edits and the issues list for this document are 32 available from 33 . 36 The changes in this draft are summarized in Appendix C.12. 38 The contents of this document will likely be included into the new 39 specification of the "Basic" scheme, see 40 . 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on September 5, 2014. 59 Copyright Notice 61 Copyright (c) 2014 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 78 3. The 'charset' auth-param . . . . . . . . . . . . . . . . . . . 4 79 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 86 Appendix A. Deployment Considerations . . . . . . . . . . . . . . 7 87 A.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 7 88 A.1.1. Alternative approach . . . . . . . . . . . . . . . . . 8 89 A.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 8 90 Appendix B. FAQ (to be removed by RFC Editor before 91 publication) . . . . . . . . . . . . . . . . . . . . 8 92 B.1. Why not simply switch the default encoding to UTF-8? . . . 8 93 B.2. What about Digest? . . . . . . . . . . . . . . . . . . . . 8 94 B.3. Will existing UAs ignore the parameter? . . . . . . . . . 9 95 Appendix C. Change Log (to be removed by RFC Editor before 96 publication) . . . . . . . . . . . . . . . . . . . . 9 97 C.1. Since draft-reschke-basicauth-enc-00 . . . . . . . . . . . 9 98 C.2. Since draft-reschke-basicauth-enc-01 . . . . . . . . . . . 9 99 C.3. Since draft-reschke-basicauth-enc-02 . . . . . . . . . . . 9 100 C.4. Since draft-reschke-basicauth-enc-03 . . . . . . . . . . . 9 101 C.5. Since draft-reschke-basicauth-enc-04 . . . . . . . . . . . 9 102 C.6. Since draft-reschke-basicauth-enc-05 . . . . . . . . . . . 9 103 C.7. Since draft-reschke-basicauth-enc-06 . . . . . . . . . . . 9 104 C.8. Since draft-reschke-basicauth-enc-07 . . . . . . . . . . . 9 105 C.9. Since draft-reschke-basicauth-enc-08 . . . . . . . . . . . 10 106 C.10. Since draft-ietf-httpauth-basicauth-enc-00 . . . . . . . . 10 107 C.11. Since draft-ietf-httpauth-basicauth-enc-01 . . . . . . . . 10 108 C.12. Since draft-ietf-httpauth-basicauth-enc-02 . . . . . . . . 10 109 Appendix D. Resolved issues (to be removed by RFC Editor 110 before publication) . . . . . . . . . . . . . . . . . 10 111 D.1. unorm . . . . . . . . . . . . . . . . . . . . . . . . . . 10 112 Appendix E. Open issues (to be removed by RFC Editor prior to 113 publication) . . . . . . . . . . . . . . . . . . . . 10 114 E.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 116 1. Introduction 118 The "Basic" authentication scheme defined in Section 2 of [RFC2617] 119 does not properly define how to treat non-ASCII characters 120 ([USASCII]): it uses the Base64 ([RFC4648], Section 4) encoding of 121 the concatenation of username, separator character, and password 122 without stating which character encoding scheme to use. 124 This has led to a situation where user agent implementations 125 disagree, and servers make different assumptions based on the locales 126 they are running in. There is little interoperability for the non- 127 ASCII characters in the ISO-8859-1 character repertoire ([USASCII], 128 [ISO-8859-1]), and even less interoperability for any characters 129 beyond that. 131 This document defines a backwards-compatible extension to "Basic", 132 specifying the server's character encoding scheme expectation, using 133 a new auth-param for use in the Proxy-Authenticate and WWW- 134 Authenticate header fields, as defined in 135 [draft-ietf-httpbis-p7-auth]. 137 2. Notational Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 The terms (character) repertoire and character encoding scheme are 144 defined in Section 2 of [RFC6365]. 146 3. The 'charset' auth-param 148 In challenges, servers MAY use the "charset" authentication parameter 149 (case-insensitive) to indicate the character encoding scheme they 150 expect the user agent to use when generating "user-pass" (a sequence 151 of octets) from "userid" and "password" ([RFC2617], Section 2). 153 The only allowed value is "UTF-8", to be matched case-insensitively 154 (see [RFC2978], Section 2.3). It indicates that the server expects 155 user name and password to be converted to Unicode Normalization Form 156 C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets 157 using the UTF-8 character encoding scheme ([RFC3629]). 159 Other values are reserved for future use. 161 Note: The 'charset' parameter cannot be included when sending 162 credentials (e.g. in the Authorization or Proxy-Authorization 163 header fields), as the "Basic" scheme uses a single token for 164 credentials ('token68' syntax), not a parameter list ('#auth- 165 param' syntax); see Section 2.1 of [draft-ietf-httpbis-p7-auth]. 167 Note: The name 'charset' has been chosen for consistency with 168 Section 2.1.1 of [RFC2831]. A better name would have been 169 'accept-charset', as it is not about the message it appears in, 170 but the server's expectation. 172 4. Example 174 In the example below, the server prompts for authentication in the 175 "foo" realm, using Basic authentication, with a preference for the 176 UTF-8 character encoding scheme: 178 WWW-Authenticate: Basic realm="foo", charset="UTF-8" 180 Note that the parameter value can be either a token or a quoted 181 string; in this case the server chose to use the quoted-string 182 notation. 184 The user's name is "test", and his password is the string "123" 185 followed by the Unicode character U+00A3 (POUND SIGN). Following 186 Section 1.2 of [RFC2617], but using the character encoding scheme 187 UTF-8, the user-pass, converted to a sequence of octets, is: 189 't' 'e' 's' 't' ':' '1' '2' '3' pound 190 74 65 73 74 3A 31 32 33 C2 A3 192 Encoding this octet sequence in Base64 ([RFC4648], Section 4) yields: 194 dGVzdDoxMjPCow== 196 Thus the Authorization header field would be: 198 Authorization: Basic dGVzdDoxMjPCow== 200 Or, for proxy authentication: 202 Proxy-Authorization: Basic dGVzdDoxMjPCow== 204 5. Security Considerations 206 This document does not introduce any new security considerations 207 beyond those defined for the "Basic" authentication scheme 208 ([RFC2617], Section 4), and those applicable to the handling of UTF-8 209 ([RFC3629], Section 10). 211 6. IANA Considerations 213 There are no IANA Considerations related to this specification. 215 7. Acknowledgements 217 The internationalisation problem has been reported as a Mozilla bug 218 back in the year 2000 (see 219 and also the 220 more recent ). 221 It was Andrew Clover's idea to address it using a new auth-param. 223 Thanks to Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James 224 Manger, Yaron Sheffer, Michael Sweet, and Martin Thomson for 225 providing feedback on this document. 227 8. References 229 8.1. Normative References 231 [ISO-8859-1] International Organization for 232 Standardization, "Information 233 technology -- 8-bit single-byte coded 234 graphic character sets -- Part 1: Latin 235 alphabet No. 1", ISO/IEC 8859-1:1998, 236 1998. 238 [RFC2119] Bradner, S., "Key words for use in RFCs 239 to Indicate Requirement Levels", 240 BCP 14, RFC 2119, March 1997. 242 [RFC2617] Franks, J., Hallam-Baker, P., 243 Hostetler, J., Lawrence, S., Leach, P., 244 Luotonen, A., and L. Stewart, "HTTP 245 Authentication: Basic and Digest Access 246 Authentication", RFC 2617, June 1999. 248 [RFC2978] Freed, N. and J. Postel, "IANA Charset 249 Registration Procedures", BCP 19, 250 RFC 2978, October 2000. 252 [RFC3629] Yergeau, F., "UTF-8, a transformation 253 format of ISO 10646", STD 63, RFC 3629, 254 November 2003. 256 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode 257 Format for Network Interchange", 258 RFC 5198, March 2008. 260 [RFC6365] Hoffman, P. and J. Klensin, 261 "Terminology Used in 262 Internationalization in the IETF", 263 BCP 166, RFC 6365, September 2011. 265 [USASCII] American National Standards Institute, 266 "Coded Character Set -- 7-bit American 267 Standard Code for Information 268 Interchange", ANSI X3.4, 1986. 270 [draft-ietf-httpbis-p7-auth] Fielding, R., Ed. and J. Reschke, Ed., 271 "Hypertext Transfer Protocol 272 (HTTP/1.1): Authentication", 273 draft-ietf-httpbis-p7-auth-26 (work in 274 progress), February 2014. 276 8.2. Informative References 278 [RFC2831] Leach, P. and C. Newman, "Using Digest 279 Authentication as a SASL Mechanism", 280 RFC 2831, May 2000. 282 [RFC4648] Josefsson, S., "The Base16, Base32, and 283 Base64 Data Encodings", RFC 4648, 284 October 2006. 286 [XHR] van Kesteren, A., Steen, H., Aubourg, 287 J., and J. Song, "XMLHttpRequest Level 288 1", W3C Working Draft WD- 289 XMLHttpRequest-20140130, January 2014, 290 . 293 Latest version available at 294 . 296 Appendix A. Deployment Considerations 298 A.1. User Agents 300 User agents not implementing this specification should continue to 301 work as before, ignoring the new parameter. 303 User agents which already default to the UTF-8 encoding implement 304 this specification by definition. Note that some user agents also 305 have different defaults depending on whether the request originates 306 from page navigation as opposed to a script-driven request using 307 XMLHttpRequest [XHR]. 309 Other user agents can keep their default behavior, and switch to 310 UTF-8 when seeing the new parameter. 312 A.1.1. Alternative approach 314 On the other hand, the strategy below may already improve the user- 315 visible behavior today: 317 o In the first authentication request, choose the character encoding 318 scheme based on the user's credentials: if they do not need any 319 characters outside the ISO-8859-1 character repertoire, default to 320 ISO-8859-1, otherwise use UTF-8. 322 o If the first attempt failed and the encoding used was ISO-8859-1, 323 retry once with UTF-8 encoding instead. 325 Note that there's a risk if the site blocks an account after multiple 326 login failures (for instance, when it doesn't reset the counter after 327 a successful login). 329 A.2. Origin Servers 331 Origin servers that do not support non-ASCII characters in 332 credentials do not require any changes. 334 Origin servers that need to support non-ASCII characters, but can't 335 use the UTF-8 encoding will not be affected; they will continue to 336 function as well or as badly as before. 338 Finally, origin servers that need to support non-ASCII characters and 339 can use the UTF-8 encoding can opt in as described above. In the 340 worst case, they'll continue to see either broken credentials or no 341 credentials at all (depending on how legacy clients handle characters 342 they can not encode). 344 Appendix B. FAQ (to be removed by RFC Editor before publication) 346 B.1. Why not simply switch the default encoding to UTF-8? 348 There are sites in use today that default to a locale encoding, such 349 as ISO-8859-1, and expect user agents to use that encoding. These 350 sites will break if the user agent uses a different encoding, such as 351 UTF-8. 353 B.2. What about Digest? 355 The Digest scheme has similar issues with respect to 356 internationalization. The HTTPAuth Working Group is chartered to 357 address this problem as well, and the solution might be very similar. 359 B.3. Will existing UAs ignore the parameter? 361 It appears they will. See 362 and 363 . 365 Appendix C. Change Log (to be removed by RFC Editor before publication) 367 C.1. Since draft-reschke-basicauth-enc-00 369 Add and close issues "credparam" and "paramcase". Rewrite the 370 deployment considerations. 372 C.2. Since draft-reschke-basicauth-enc-01 374 Note more recent Mozilla bugzilla entry; add behavior of existing UAs 375 to FAQ (with pointer to test cases). 377 C.3. Since draft-reschke-basicauth-enc-02 379 Add and resolve issue "xhrutf8". 381 C.4. Since draft-reschke-basicauth-enc-03 383 Add and resolve issue "proxy". 385 C.5. Since draft-reschke-basicauth-enc-04 387 Add and resolve issues "paramname" and "sentparam". Add issues 388 "terminology" and "unorm". Update HTTPbis reference. 390 C.6. Since draft-reschke-basicauth-enc-05 392 Update HTTPbis reference. 394 C.7. Since draft-reschke-basicauth-enc-06 396 Update HTTPbis and XHR references. 398 C.8. Since draft-reschke-basicauth-enc-07 400 "b64token" -> "token68" (ABNF term changed in HTTPbis P7). Change 401 contact information from HTTPbis WG to HTTPAUTH WG. Add issue 402 parmname2831. Changed intended status to "experimental". 404 C.9. Since draft-reschke-basicauth-enc-08 406 Made it a draft of the IETF HTTPauth Working Group. 408 C.10. Since draft-ietf-httpauth-basicauth-enc-00 410 Clarify what encoding step the charset selection applies to. 412 Use RFC 6365 terminology. 414 Rename the parameter to "charset" for consistency with RFC 2831. 416 C.11. Since draft-ietf-httpauth-basicauth-enc-01 418 Update httpbis and XHR references. Add a note about 419 draft-ietf-httpauth-basicauth-update. 421 C.12. Since draft-ietf-httpauth-basicauth-enc-02 423 Update httpbis reference. Close issue "unorm". 425 Appendix D. Resolved issues (to be removed by RFC Editor before 426 publication) 428 Issues that were either rejected or resolved in this version of this 429 document. 431 D.1. unorm 433 Type: edit 435 julian.reschke@greenbytes.de (2012-02-02): We need a statement about 436 unicode normalization forms. 438 Resolution: State that the expected normalization form is NFC. 440 Appendix E. Open issues (to be removed by RFC Editor prior to 441 publication) 443 E.1. edit 445 Type: edit 447 julian.reschke@greenbytes.de (2010-08-11): Umbrella issue for 448 editorial fixes/enhancements. 450 Author's Address 452 Julian F. Reschke 453 greenbytes GmbH 454 Hafenweg 16 455 Muenster, NW 48155 456 Germany 458 EMail: julian.reschke@greenbytes.de 459 URI: http://greenbytes.de/tech/webdav/