1 2 3 4 5 6 7 Network Working Group K. Zeilenga 8 Request for Comments: 4013 OpenLDAP Foundation 9 Category: Standards Track February 2005 10 11 12 SASLprep: Stringprep Profile for User Names and Passwords 13 14 Status of This Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22 Copyright Notice 23 24 Copyright (C) The Internet Society (2005). 25 26 Abstract 27 28 This document describes how to prepare Unicode strings representing 29 user names and passwords for comparison. The document defines the 30 "SASLprep" profile of the "stringprep" algorithm to be used for both 31 user names and passwords. This profile is intended to be used by 32 Simple Authentication and Security Layer (SASL) mechanisms (such as 33 PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols 34 exchanging simple user names and/or passwords. 35 36 1. Introduction 37 38 The use of simple user names and passwords in authentication and 39 authorization is pervasive on the Internet. To increase the 40 likelihood that user name and password input and comparison work in 41 ways that make sense for typical users throughout the world, this 42 document defines rules for preparing internationalized user names and 43 passwords for comparison. For simplicity and implementation ease, a 44 single algorithm is defined for both user names and passwords. 45 46 The algorithm assumes all strings are comprised of characters from 47 the Unicode [Unicode] character set. 48 49 This document defines the "SASLprep" profile of the "stringprep" 50 algorithm [StringPrep]. 51 52 The profile is designed for use in Simple Authentication and Security 53 Layer ([SASL]) mechanisms, such as [PLAIN], [CRAM-MD5], and 54 [DIGEST-MD5]. It may be applicable where simple user names and 55 56 57 58 Zeilenga Standards Track [Page 1] 59 61 RFC 4013 SASLprep February 2005 62 63 64 passwords are used. This profile is not intended for use in 65 preparing identity strings that are not simple user names (e.g., 66 email addresses, domain names, distinguished names), or where 67 identity or password strings that are not character data, or require 68 different handling (e.g., case folding). 69 70 This document does not alter the technical specification of any 71 existing protocols. Any specification that wishes to use the 72 algorithm described in this document needs to explicitly incorporate 73 this document and provide precise details as to where and how this 74 algorithm is used by implementations of that specification. 75 76 2. The SASLprep Profile 77 78 This section defines the "SASLprep" profile of the "stringprep" 79 algorithm [StringPrep]. This profile is intended for use in 80 preparing strings representing simple user names and passwords. 81 82 This profile uses Unicode 3.2 [Unicode]. 83 84 Character names in this document use the notation for code points and 85 names from the Unicode Standard [Unicode]. For example, the letter 86 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>. 87 In the lists of mappings and the prohibited characters, the "U+" is 88 left off to make the lists easier to read. The comments for 89 character ranges are shown in square brackets (such as "[CONTROL 90 CHARACTERS]") and do not come from the standard. 91 92 Note: A glossary of terms used in Unicode can be found in [Glossary]. 93 Information on the Unicode character encoding model can be found in 94 [CharModel]. 95 96 2.1. Mapping 97 98 This profile specifies: 99 100 - non-ASCII space characters [StringPrep, C.1.2] that can be 101 mapped to SPACE (U+0020), and 102 103 - the "commonly mapped to nothing" characters [StringPrep, B.1] 104 that can be mapped to nothing. 105 106 2.2. Normalization 107 108 This profile specifies using Unicode normalization form KC, as 109 described in Section 4 of [StringPrep]. 110 111 112 113 114 115 Zeilenga Standards Track [Page 2] 116 118 RFC 4013 SASLprep February 2005 119 120 121 2.3. Prohibited Output 122 123 This profile specifies the following characters as prohibited input: 124 125 - Non-ASCII space characters [StringPrep, C.1.2] 126 - ASCII control characters [StringPrep, C.2.1] 127 - Non-ASCII control characters [StringPrep, C.2.2] 128 - Private Use characters [StringPrep, C.3] 129 - Non-character code points [StringPrep, C.4] 130 - Surrogate code points [StringPrep, C.5] 131 - Inappropriate for plain text characters [StringPrep, C.6] 132 - Inappropriate for canonical representation characters 133 [StringPrep, C.7] 134 - Change display properties or deprecated characters 135 [StringPrep, C.8] 136 - Tagging characters [StringPrep, C.9] 137 138 2.4. Bidirectional Characters 139 140 This profile specifies checking bidirectional strings as described in 141 [StringPrep, Section 6]. 142 143 2.5. Unassigned Code Points 144 145 This profile specifies the [StringPrep, A.1] table as its list of 146 unassigned code points. 147 148 3. Examples 149 150 The following table provides examples of how various character data 151 is transformed by the SASLprep string preparation algorithm 152 153 # Input Output Comments 154 - ----- ------ -------- 155 1 I<U+00AD>X IX SOFT HYPHEN mapped to nothing 156 2 user user no transformation 157 3 USER USER case preserved, will not match #2 158 4 <U+00AA> a output is NFKC, input in ISO 8859-1 159 5 <U+2168> IX output is NFKC, will match #1 160 6 <U+0007> Error - prohibited character 161 7 <U+0627><U+0031> Error - bidirectional check 162 163 4. Security Considerations 164 165 This profile is intended to prepare simple user name and password 166 strings for comparison or use in cryptographic functions (e.g., 167 message digests). The preparation algorithm was specifically 168 designed such that its output is canonical, and it is well-formed. 169 170 171 172 Zeilenga Standards Track [Page 3] 173 175 RFC 4013 SASLprep February 2005 176 177 178 However, due to an anomaly [PR29] in the specification of Unicode 179 normalization, canonical equivalence is not guaranteed for a select 180 few character sequences. These sequences, however, do not appear in 181 well-formed text. This specification was published despite this 182 known technical problem. It is expected that this specification will 183 be revised before further progression on the Standards Track (after 184 [Unicode] and/or [StringPrep] specifications have been updated to 185 address this problem). 186 187 It is not intended for preparing identity strings that are not simple 188 user names (e.g., distinguished names, domain names), nor is the 189 profile intended for use of simple user names that require different 190 handling (such as case folding). Protocols (or applications of those 191 protocols) that have application-specific identity forms and/or 192 comparison algorithms should use mechanisms specifically designed for 193 these forms and algorithms. 194 195 Application of string preparation may have an impact upon the 196 feasibility of brute force and dictionary attacks. While the number 197 of possible prepared strings is less than the number of possible 198 Unicode strings, the number of usable names and passwords is greater 199 than as if only ASCII was used. Though SASLprep eliminates some 200 Unicode code point sequences as possible prepared strings, that 201 elimination generally makes the (canonical) output forms practicable 202 and prohibits nonsensical inputs. 203 204 User names and passwords should be protected from eavesdropping. 205 206 General "stringprep" and Unicode security considerations apply. Both 207 are discussed in [StringPrep]. 208 209 5. IANA Considerations 210 211 This document details the "SASLprep" profile of the [StringPrep] 212 protocol. This profile has been registered in the stringprep profile 213 registry. 214 215 Name of this profile: SASLprep 216 RFC in which the profile is defined: RFC 4013 217 Indicator whether or not this is the newest version of the 218 profile: This is the first version of the SASPprep profile. 219 220 6. Acknowledgement 221 222 This document borrows text from "Preparation of Internationalized 223 Strings ('stringprep')" and "Nameprep: A Stringprep Profile for 224 Internationalized Domain Names", both by Paul Hoffman and Marc 225 Blanchet. This document is a product of the IETF SASL WG. 226 227 228 229 Zeilenga Standards Track [Page 4] 230 232 RFC 4013 SASLprep February 2005 233 234 235 7. Normative References 236 237 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of 238 Internationalized Strings ("stringprep")", RFC 3454, 239 December 2002. 240 241 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 242 3.2.0" is defined by "The Unicode Standard, Version 243 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 244 61633-5), as amended by the "Unicode Standard Annex 245 #27: Unicode 3.1" 246 (http://www.unicode.org/reports/tr27/) and by the 247 "Unicode Standard Annex #28: Unicode 3.2" 248 (http://www.unicode.org/reports/tr28/). 249 250 8. Informative References 251 252 [Glossary] The Unicode Consortium, "Unicode Glossary", 253 <http://www.unicode.org/glossary/>. 254 255 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 256 #17, Character Encoding Model", UTR17, 257 <http://www.unicode.org/unicode/reports/tr17/>, August 258 2000. 259 260 [SASL] Melnikov, A., Ed., "Simple Authentication and Security 261 Layer (SASL)", Work in Progress. 262 263 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in 264 Progress. 265 266 [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest 267 Authentication as a SASL Mechanism", Work in Progress. 268 269 [PLAIN] Zeilenga, K., Ed., "The Plain SASL Mechanism", Work in 270 Progress. 271 272 [PR29] "Public Review Issue #29: Normalization Issue", 273 <http://www.unicode.org/review/pr-29.html>, February 274 2004. 275 276 Author's Address 277 278 Kurt D. Zeilenga 279 OpenLDAP Foundation 280 281 EMail: Kurt (a] OpenLDAP.org 282 283 284 285 286 Zeilenga Standards Track [Page 5] 287 289 RFC 4013 SASLprep February 2005 290 291 292 Full Copyright Statement 293 294 Copyright (C) The Internet Society (2005). 295 296 This document is subject to the rights, licenses and restrictions 297 contained in BCP 78, and except as set forth therein, the authors 298 retain all their rights. 299 300 This document and the information contained herein are provided on an 301 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 302 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 303 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 304 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 305 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 307 308 Intellectual Property 309 310 The IETF takes no position regarding the validity or scope of any 311 Intellectual Property Rights or other rights that might be claimed to 312 pertain to the implementation or use of the technology described in 313 this document or the extent to which any license under such rights 314 might or might not be available; nor does it represent that it has 315 made any independent effort to identify any such rights. Information 316 on the IETF's procedures with respect to rights in IETF Documents can 317 be found in BCP 78 and BCP 79. 318 319 Copies of IPR disclosures made to the IETF Secretariat and any 320 assurances of licenses to be made available, or the result of an 321 attempt made to obtain a general license or permission for the use of 322 such proprietary rights by implementers or users of this 323 specification can be obtained from the IETF on-line IPR repository at 324 http://www.ietf.org/ipr. 325 326 The IETF invites any interested party to bring to its attention any 327 copyrights, patents or patent applications, or other proprietary 328 rights that may cover technology that may be required to implement 329 this standard. Please address the information to the IETF at ietf- 330 ipr (a] ietf.org. 331 332 333 Acknowledgement 334 335 Funding for the RFC Editor function is currently provided by the 336 Internet Society. 337 338 339 340 341 342 343 Zeilenga Standards Track [Page 6] 344 346
Indexes created Mon Sep 14 00:24:24 UTC 2026