idnits 2.17.00 (12 Aug 2021) /tmp/idnits18845/draft-ietf-precis-saslprepbis-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2013) is 3136 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) == Outdated reference: draft-ietf-precis-framework has been published as RFC 7564 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' == Outdated reference: draft-ietf-precis-mappings has been published as RFC 7790 -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PRECIS P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Obsoletes: 4013 (if approved) A. Melnikov 5 Intended status: Standards Track Isode Ltd 6 Expires: April 21, 2014 October 18, 2013 8 Preparation and Comparison of Internationalized Strings Representing 9 Usernames and Passwords 10 draft-ietf-precis-saslprepbis-05 12 Abstract 14 This document describes methods for handling Unicode strings 15 representing usernames and passwords. This document obsoletes RFC 16 4013. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 21, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. What the Username and Password Profiles Provide . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2.1. Case Mapping . . . . . . . . . . . . . . . . . . . . . 6 59 5. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. UsernameIdentifierClass . . . . . . . . . . . . . . . . . 10 67 7.2. PasswordFreeformClass . . . . . . . . . . . . . . . . . . 11 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8.1. Password/Passphrase Strength . . . . . . . . . . . . . . . 11 70 8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 11 71 8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 12 72 8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . . 14 77 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Usernames and passwords are widely used for authentication and 83 authorization on the Internet, either directly when provided in 84 plaintext (as in the SASL PLAIN mechanism [RFC4616] or the HTTP Basic 85 scheme [RFC2617]) or indirectly when provided as the input to a 86 cryptographic algorithm such as a hash function (as in the SASL SCRAM 87 mechanism [RFC5802] or the HTTP Digest scheme [RFC2617]). To 88 increase the likelihood that the input and comparison of usernames 89 and passwords will work in ways that make sense for typical users 90 throughout the world, this document defines rules for preparing and 91 comparing internationalized strings that represent usernames and 92 passwords. 94 The methods specified in this document define two PRECIS profiles as 95 explained in the PRECIS framework specification 96 [I-D.ietf-precis-framework]. This document assumes that all strings 97 are comprised of characters from the Unicode character set [UNICODE], 98 with special attention to characters outside the ASCII range [RFC20]. 99 The methods defined here might be applicable wherever usernames or 100 passwords are used. However, the methods are not intended for use in 101 preparing strings that are not usernames (e.g., email addresses and 102 LDAP distinguished names), nor in cases where identifiers or secrets 103 are not strings (e.g., keys and certificates) or require specialized 104 handling. 106 This document obsoletes RFC 4013 (the "SASLprep" profile of 107 stringprep [RFC3454]) but can be used by technologies other than the 108 Simple Authentication and Security Layer (SASL) [RFC4422], such as 109 HTTP authentication [RFC2617]. 111 2. What the Username and Password Profiles Provide 113 Profiles of the PRECIS framework enable software to handle Unicode 114 characters outside the ASCII range in an automated way, so that such 115 characters are treated carefully and consistently in application 116 protocols. In large measure, these profiles are designed to protect 117 application developers from the potentially negative consequences of 118 supporting the full range of Unicode characters. For instance, in 119 almost all application protocols it would be dangerous to treat the 120 Unicode character SUPERSCRIPT ONE (U+0089) as equivalent to DIGIT ONE 121 (U+0031), since that would result in false positives during 122 comparison, authentication, and authorization (e.g., an attacker 123 could easy spoof an account "user1@example.com"). 125 Whereas a naive use of Unicode would make such attacks trivially 126 easy, the Username PRECIS profile defined in this document generally 127 protects applications from inadvertently causing such problems. 128 (Similar considerations apply to passwords, although here it is 129 desirable to support a wider range of characters so as to maximize 130 entropy during authentication.) 132 3. Terminology 134 Many important terms used in this document are defined in 135 [I-D.ietf-precis-framework], [RFC5890], [RFC6365], and [UNICODE]. 136 The term "non-ASCII space" refers to any Unicode code point having a 137 general category of "Zs", with the exception of U+0020 (here called 138 "ASCII space"). 140 As used here, the term "password" is not literally limited to a word; 141 i.e., a password could be a passphrase consisting of more than one 142 word, perhaps separated by spaces or other such characters. 144 Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify 145 that the authentication identity used in the context of such 146 mechanisms is a "simple user name" (see Section 2 of [RFC4422] as 147 well as [RFC4013]). Various application technologies also assume 148 that the identity of a user or account takes the form of a username 149 (e.g., authentication for the HyperText Transfer Protocol [RFC2617]), 150 whether or not they use SASL. Note well that the exact form of a 151 username in any particular SASL mechanism or application technology 152 is a matter for implementation and deployment, and that a username 153 does not necessarily map to any particular application identifier 154 (such as the localpart of an email address). 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in 159 [RFC2119]. 161 4. Usernames 163 4.1. Definition 165 This document specifies that a username is a string of Unicode code 166 points [UNICODE], encoded using UTF-8 [RFC3629], and structured 167 either as an ordered sequence of "userparts" (where the complete 168 username can consist of a single userpart or a space-separated 169 sequence of userparts) or as a userpart@domainpart (where the 170 domainpart is an IP literal, an IPv4 address, or a fully-qualified 171 domain name). 173 The syntax for a username is defined as follows using the Augmented 174 Backus-Naur Form (ABNF) [RFC5234]. 176 username = userpart [1*(1*SP userpart)] 177 / userpart '@' domainpart 178 userpart = 1*(idpoint) 179 ; 180 ; an "idpoint" is a UTF-8 encoded Unicode code point 181 ; that conforms to the PRECIS "IdentifierClass" 182 ; 183 domainpart = IP-literal / IPv4address / ifqdn 184 ; 185 ; the "IPv4address" and "IP-literal" rules are 186 ; defined in RFC 3986, and the first-match-wins 187 ; (a.k.a. "greedy") algorithm described in RFC 3986 188 ; applies 189 ; 190 ; reuse of the IP-literal rule from RFC 3986 implies 191 ; that IPv6 addresses are enclosed in square brackets 192 ; (i.e., beginning with '[' and ending with ']') 193 ; 194 ifqdn = 1*1023(domainpoint) 195 ; 196 ; a "domainpoint" is a UTF-8 encoded Unicode code 197 ; point that conforms to RFC 5890 198 ; 200 All code points and blocks not explicitly allowed in the PRECIS 201 IdentifierClass are disallowed; this includes private use characters, 202 surrogate code points, and the other code points and blocks that were 203 defined as "Prohibited Output" in [RFC4013]. In addition, common 204 constructions such as "user@example.com" are allowed as usernames 205 under this specification, as they were under [RFC4013]. 207 4.2. Preparation 209 Each userpart of a username MUST conform to the 210 "UsernameIdentifierClass" profile of the PRECIS IdentifierClass, 211 which is defined as follows: 213 1. The base string class is the "IdentifierClass" specified in 214 [I-D.ietf-precis-framework]. 215 2. Fullwidth and halfwidth characters MUST be mapped to their 216 decomposition equivalents. 217 3. So-called additional mappings MAY be applied, such as those 218 defined in [I-D.ietf-precis-mappings]. 220 4. Uppercase and titlecase characters might be mapped to their 221 lowercase equivalents (see Section 4.2.1 below). 222 5. Unicode Normalization Form C (NFC) MUST be applied to all 223 characters. 225 With regard to directionality, the "Bidi Rule" provided in [RFC5893] 226 applies. 228 A username MUST NOT be zero bytes in length. This rule is to be 229 enforced after any normalization and mapping of code points. 231 In protocols that provide usernames as input to a cryptographic 232 algorithm such as a hash function, the client will need to perform 233 proper preparation of the username before applying the algorithm. 235 4.2.1. Case Mapping 237 Case mapping is a matter for the application protocol, protocol 238 implementation, or end deployment. In general, this document 239 suggests that it is preferable to perform case mapping, since not 240 doing so can lead to false positives during authentication and 241 authorization (as described in [RFC6943]) and can result in confusion 242 among end users given the prevalence of case mapping in many existing 243 protocols and applications. However, there can be good reasons to 244 not perform case mapping, such as backward compatibility with 245 deployed infrastructure. 247 In particular: 249 o SASL mechanisms that directly re-use this profile MUST specify 250 whether and when case mapping is to be applied to authentication 251 identifiers. SASL mechanisms SHOULD delay any case mapping to the 252 last possible moment, such as when doing a lookup by username, 253 username comparisons, or generating a cryptographic salt from a 254 username (if the last possible moment happens on the server, then 255 decisions about case mapping can be a matter of deployment 256 policy). In keeping with RFC4422, SASL mechanisms are not to 257 apply this or any other profile to authorization identifiers. 258 o Application protocols that use SASL (such as IMAP [RFC3501] and 259 XMPP [RFC6120]) and that directly re-use this profile MUST specify 260 whether case mapping is to be applied to authorization 261 identifiers. Such "SASL application protocols" SHOULD delay any 262 case mapping of authorization identifiers to the last possible 263 moment, which happens to necessarily be on the server side (this 264 enables decisions about case mapping to be a matter of deployment 265 policy). In keeping with RFC4422, SASL application protocols are 266 not to apply this or any other profile to authentication 267 identifiers. 269 o Application protocols that do not use SASL (such as HTTP 270 authentication with the Basic and Digest schemes [RFC2617]) MUST 271 specify whether and when case mapping is to be applied to 272 authentication identifiers and authorization identifiers. Such 273 "non-SASL application protocols" SHOULD delay any case mapping to 274 the last possible moment, such as when doing a lookup by username, 275 username comparisons, or generating a cryptographic salt from a 276 username (if the last possible moment happens on the server, then 277 decisions about case mapping can be a matter of deployment 278 policy). 280 If the specification for a SASL mechanism, SASL application protocol, 281 or non-SASL application protocol specifies the handling of case 282 mapping for strings that conform to the UsernameIdentifierClass, it 283 MUST clearly describe whether case mapping is required, recommended, 284 or optional at the level of the protocol itself, implementations 285 thereof, or service deployments. 287 5. Passwords 289 5.1. Definition 291 This document specifies that a password is a string of Unicode code 292 points [UNICODE], encoded using UTF-8 [RFC3629], and conformant to 293 the PRECIS FreeformClass. 295 The syntax for a password is defined as follows using the Augmented 296 Backus-Naur Form (ABNF) [RFC5234]. 298 password = 1*(freepoint) 299 ; 300 ; a "freepoint" is a UTF-8 encoded 301 ; Unicode code point that conforms to 302 ; the PRECIS "FreeformClass" 303 ; 305 All code points and blocks not explicitly allowed in the PRECIS 306 FreeformClass are disallowed; this includes private use characters, 307 surrogate code points, and the other code points and blocks defined 308 as "Prohibited Output" in Section 2.3 of RFC 4013. 310 5.2. Preparation 312 A password MUST conform to the "PasswordFreeformClass" profile of the 313 PRECIS FreeformClass, which is defined as follows: 315 1. The base string class is the "FreeformClass" specified in 316 [I-D.ietf-precis-framework]. 317 2. Fullwidth and halfwidth characters MUST NOT be mapped to their 318 decomposition equivalents. 319 3. Any instances of non-ASCII space MUST be mapped to ASCII space 320 (U+0020). 321 4. So-called additional mappings MAY be applied, such as those 322 defined in [I-D.ietf-precis-mappings]. 323 5. Uppercase and titlecase characters MUST NOT be mapped to their 324 lowercase equivalents. 325 6. Unicode Normalization Form C (NFC) MUST be applied to all 326 characters. 328 With regard to directionality, the "Bidi Rule" (defined in [RFC5893]) 329 and similar rules are unnecessary and inapplicable to passwords, 330 since they can reduce the range of characters that are allowed in a 331 string and therefore reduce the amount of entropy that is possible in 332 a password. Furthermore, such rules are intended to minimize the 333 possibility that the same string will be displayed differently on a 334 system set for right-to-left display and a system set for left-to- 335 right display; however, passwords are typically not displayed at all 336 and are rarely meant to be interoperable across different systems in 337 the way that non-secret strings like domain names and usernames are. 339 A password MUST NOT be zero bytes in length. This rule is to be 340 enforced after any normalization and mapping of code points. 342 In protocols that provide passwords as input to a cryptographic 343 algorithm such as a hash function, the client will need to perform 344 proper preparation of the password before applying the algorithm, 345 since the password is not available to the server in plaintext form. 347 6. Migration 349 The rules defined in this specification differ slightly from those 350 defined by the SASLprep specification [RFC4013]. The following 351 sections describe these differences, along with their implications 352 for migration, in more detail. 354 6.1. Usernames 356 Deployments that currently use SASLprep for handling usernames might 357 need to scrub existing data when migrating to use of the rules 358 defined in this specification. In particular: 360 o SASLprep specified the use of Unicode Normalization Form KC 361 (NFKC), whereas this usage of the PRECIS IdentifierClass employs 362 Unicode Normalization Form C (NFC). In practice this change is 363 unlikely to cause significant problems, because NFKC provides 364 methods for mapping Unicode code points with compatibility 365 equivalents to those equivalents, whereas the PRECIS 366 IdentifierClass entirely disallows Unicode code points with 367 compatibility equivalents (i.e., during comparison NFKC is more 368 "aggressive" about finding matches than is NFC). A few examples 369 might suffice to indicate the nature of the problem: (1) U+017F 370 LATIN SMALL LETTER LONG S is compatibility equivalent to U+0073 371 LATIN SMALL LETTER S (2) U+2163 ROMAN NUMERAL FOUR is 372 compatibility equivalent to U+0049 LATIN CAPITAL LETTER I and 373 U+0056 LATIN CAPITAL LETTER V (3) U+FB01 LATIN SMALL LIGATURE FI 374 is compatibility equivalent to U+0066 LATIN SMALL LETTER F and 375 U+0069 LATIN SMALL LETTER I. Under SASLprep, the use of NFKC also 376 handled the mapping of fullwidth and halfwidth code points to 377 their decomposition equivalents (see [I-D.ietf-precis-mappings]). 378 Although it is expected that code points with compatibility 379 equivalents are rare in existing usernames, for migration purposes 380 deployments might want to search their database of usernames for 381 Unicode code points with compatibility equivalents and map those 382 code points to their compatibility equivalents. 384 o SASLprep mapped the "characters commonly mapped to nothing" from 385 Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS 386 IdentifierClass entirely disallows most of these characters, which 387 correspond to the code points from the "M" category defined under 388 Section 6.13 of [I-D.ietf-precis-framework] (with the exception of 389 U+1806 MONGOLIAN TODO SOFT HYPHEN, which was "commonly mapped to 390 nothing" in Unicode 3.2 but at the time of this writing does not 391 have a derived property of Default_Ignorable_Code_Point in Unicode 392 6.2). For migration purposes, deployments might want to remove 393 code points contained in the PRECIS "M" category from usernames. 395 o SASLprep allowed uppercase and titlecase characters, whereas this 396 usage of the PRECIS IdentifierClass maps uppercase and titlecase 397 characters to their lowercase equivalents. For migration 398 purposes, deployments can either convert uppercase and titlecase 399 characters to their lowercase equivalents in usernames (thus 400 losing the case information) or preserve uppercase and titlecase 401 characters and ignore the case difference when comparing 402 usernames. 404 6.2. Passwords 406 Depending on local service policy, migration from RFC 4013 to this 407 specification might not involve any scrubbing of data (since 408 passwords might not be stored in the clear anyway); however, service 409 providers need to be aware of possible issues that might arise during 410 migration. In particular: 412 o SASLprep specified the use of Unicode Normalization Form KC 413 (NFKC), whereas this usage of the PRECIS FreeformClass employs 414 Unicode Normalization Form C (NFC). Because NFKC is more 415 aggressive about finding matches than NFC, in practice this change 416 is unlikely to cause significant problems and indeed has the 417 security benefit of probably resulting in fewer false positives 418 when comparing passwords. A few examples might suffice to 419 indicate the nature of the problem: (1) U+017F LATIN SMALL LETTER 420 LONG S is compatibility equivalent to U+0073 LATIN SMALL LETTER S 421 (2) U+2163 ROMAN NUMERAL FOUR is compatibility equivalent to 422 U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V 423 (3) U+FB01 LATIN SMALL LIGATURE FI is compatibility equivalent to 424 U+0066 LATIN SMALL LETTER F and U+0069 LATIN SMALL LETTER I. Under 425 SASLprep, the use of NFKC also handled the mapping of fullwidth 426 and halfwidth code points to their decomposition equivalents (see 427 [I-D.ietf-precis-mappings]). Although it is expected that code 428 points with compatibility equivalents are rare in existing 429 passwords, some passwords that matched when SASLprep was used 430 might no longer work when the rules in this specification are 431 applied. 433 o SASLprep mapped the "characters commonly mapped to nothing" from 434 Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS 435 FreeformClass entirely disallows such characters, which correspond 436 to the code points from the "M" category defined under Section 437 6.13 of [I-D.ietf-precis-framework] (with the exception of U+1806 438 MONGOLIAN TODO SOFT HYPHEN, which was commonly mapped to nothing 439 in Unicode 3.2 but at the time of this writing is allowed by 440 Unicode 6.2). In practice, this change will probably have no 441 effect on comparison, but user-oriented software might reject such 442 code points instead of ignoring them during password preparation. 444 7. IANA Considerations 446 The IANA shall add the following entries to the PRECIS Profiles 447 Registry. 449 7.1. UsernameIdentifierClass 450 Name: UsernameIdentifierClass. 451 Applicability: Usernames in security and application protocols. 452 Base Class: IdentifierClass. 453 Replaces: The SASLprep profile of Stringprep. 454 Width Mapping: Map fullwidth and halfwidth characters to their 455 decomposition equivalents. 456 Additional Mappings: None required or recommended. 457 Case Mapping: To be defined by security or application protocols 458 that use this profile. 459 Normalization: NFC. 460 Directionality: The "Bidi Rule" defined in RFC 5893 applies. 461 Exclusions: None. 462 Enforcement: To be defined by security or application protocols that 463 use this profile. 464 Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to 465 the number issued for this specification.] 467 7.2. PasswordFreeformClass 469 Name: PasswordFreeformClass. 470 Applicability: Passwords in security and application protocols. 471 Base Class: FreeformClass 472 Replaces: The SASLprep profile of Stringprep. 473 Width Mapping: None. 474 Additional Mappings: Map non-ASCII space characters to ASCII space. 475 Case Mapping: None. 476 Normalization: NFC. 477 Directionality: None. 478 Exclusions: None. 479 Enforcement: To be defined by security or application protocols that 480 use this profile. 481 Specification: RFC XXXX. 483 8. Security Considerations 485 8.1. Password/Passphrase Strength 487 The ability to include a wide range of characters in passwords and 488 passphrases can increase the potential for creating a strong password 489 with high entropy. However, in practice, the ability to include such 490 characters ought to be weighed against the possible need to reproduce 491 them on various devices using various input methods. 493 8.2. Identifier Comparison 495 The process of comparing identifiers (such as SASL simple user names, 496 authentication identifiers, and authorization identifiers) can lead 497 to either false negatives or false positives, both of which have 498 security implications. A more detailed discussion can be found in 499 [RFC6943]. 501 8.3. Reuse of PRECIS 503 The security considerations described in [I-D.ietf-precis-framework] 504 apply to the "IdentifierClass" and "FreeformClass" base string 505 classes used in this document for usernames and passwords, 506 respectively. 508 8.4. Reuse of Unicode 510 The security considerations described in [UTS39] apply to the use of 511 Unicode characters in usernames and passwords. 513 9. References 515 9.1. Normative References 517 [I-D.ietf-precis-framework] 518 Saint-Andre, P. and M. Blanchet, "Precis Framework: 519 Handling Internationalized Strings in Protocols", 520 draft-ietf-precis-framework-10 (work in progress), 521 October 2013. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 527 10646", STD 63, RFC 3629, November 2003. 529 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 530 Specifications: ABNF", STD 68, RFC 5234, January 2008. 532 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 533 6.1", 2012, 534 . 536 9.2. Informative References 538 [I-D.ietf-precis-mappings] 539 Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS 540 classes", draft-ietf-precis-mappings-04 (work in 541 progress), October 2013. 543 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 544 October 1969. 546 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 547 Leach, P., Luotonen, A., and L. Stewart, "HTTP 548 Authentication: Basic and Digest Access Authentication", 549 RFC 2617, June 1999. 551 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 552 Internationalized Strings ("stringprep")", RFC 3454, 553 December 2002. 555 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 556 4rev1", RFC 3501, March 2003. 558 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 559 and Passwords", RFC 4013, February 2005. 561 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 562 Authentication and Security Layer (SASL)", RFC 4422, 563 June 2006. 565 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 566 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 568 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 569 "Salted Challenge Response Authentication Mechanism 570 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 572 [RFC5890] Klensin, J., "Internationalized Domain Names for 573 Applications (IDNA): Definitions and Document Framework", 574 RFC 5890, August 2010. 576 [RFC5891] Klensin, J., "Internationalized Domain Names in 577 Applications (IDNA): Protocol", RFC 5891, August 2010. 579 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 580 Internationalized Domain Names for Applications (IDNA)", 581 RFC 5893, August 2010. 583 [RFC5894] Klensin, J., "Internationalized Domain Names for 584 Applications (IDNA): Background, Explanation, and 585 Rationale", RFC 5894, August 2010. 587 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 588 Protocol (XMPP): Core", RFC 6120, March 2011. 590 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 591 Internationalization in the IETF", BCP 166, RFC 6365, 592 September 2011. 594 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 595 Purposes", RFC 6943, May 2013. 597 [UTS39] The Unicode Consortium, "Unicode Technical Standard #39: 598 Unicode Security Mechanisms", July 2012, 599 . 601 Appendix A. Differences from RFC 4013 603 This document builds upon the PRECIS framework defined in 604 [I-D.ietf-precis-framework], which differs fundamentally from the 605 stringprep technology [RFC3454] used in SASLprep [RFC4013]. The 606 primary difference is that stringprep profiles allowed all characters 607 except those which were explicitly disallowed, whereas PRECIS 608 profiles disallow all characters except those which are explicitly 609 allowed (this "inclusion model" was originally used for 610 internationalized domain names in [RFC5891]; see [RFC5894] for 611 further discussion). It is important to keep this distinction in 612 mind when comparing the technology defined in this document to 613 SASLprep [RFC4013]. 615 The following substantive modifications were made from RFC 4013. 617 o A single SASLprep algorithm was replaced by two separate 618 algorithms: one for usernames and another for passwords. 619 o The new preparation algorithms use PRECIS instead of a stringprep 620 profile. The new algorithms work independenctly of Unicode 621 versions. 622 o As recommended in the PRECIS framwork, changed the Unicode 623 normalization form to NFC (from NFKC). 624 o Some Unicode code points that were mapped to nothing in RFC 4013 625 are simply disallowed by PRECIS. 627 Appendix B. Acknowledgements 629 The following individuals provided helpful feedback on this document: 630 Marc Blanchet, Alan DeKok, Joe Hildebrand, Jeffrey Hutzelman, Simon 631 Josefsson, Jonathan Lennox, Matt Miller, Chris Newman, Yutaka OIWA, 632 Pete Resnick, Andrew Sullivan, and Nico Williams (Nico in particular 633 provided text that was used in Section 4.2.1). Thanks also to 634 Yoshiro YONEYA and Takahiro NEMOTO for implementation feedback. 636 This document borrows some text from [RFC4013] and [RFC6120]. 638 Authors' Addresses 640 Peter Saint-Andre 641 Cisco Systems, Inc. 642 1899 Wynkoop Street, Suite 600 643 Denver, CO 80202 644 USA 646 Phone: +1-303-308-3282 647 Email: psaintan@cisco.com 649 Alexey Melnikov 650 Isode Ltd 651 5 Castle Business Village 652 36 Station Road 653 Hampton, Middlesex TW12 2BX 654 UK 656 Email: Alexey.Melnikov@isode.com