3 INTERNET-DRAFT Kurt D. Zeilenga
4 Intended Category: Standards Track OpenLDAP Foundation
5 Expires: January 2005 18 July 2004
9 SASLprep: Stringprep profile for user names and passwords
10 <draft-ietf-sasl-saslprep-10.txt>
16 This document is intended to be, after appropriate review and
17 revision, submitted to the RFC Editor as a Standards Track document.
18 Distribution of this memo is unlimited. Technical discussion of this
19 document will take place on the IETF SASL mailing list
20 <ietf-sasl@imc.org>. Please send editorial comments directly to the
21 document editor <Kurt@OpenLDAP.org>.
23 By submitting this Internet-Draft, I accept the provisions of Section
24 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
25 applicable patent or other IPR claims of which I am aware have been
26 disclosed, or will be disclosed, and any of which I become aware will
27 be disclosed, in accordance with RFC 3668.
29 Internet-Drafts are working documents of the Internet Engineering Task
30 Force (IETF), its areas, and its working groups. Note that other
31 groups may also distribute working documents as Internet-Drafts.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference material
36 or to cite them other than as "work in progress."
38 The list of current Internet-Drafts can be accessed at
39 <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
40 Internet-Draft Shadow Directories can be accessed at
41 <http://www.ietf.org/shadow.html>.
43 Copyright (C) The Internet Society (2004). All Rights Reserved.
45 Please see the Full Copyright section near the end of this document
54 Zeilenga SASLprep [Page 1]
56 INTERNET-DRAFT draft-ietf-sasl-saslprep-10.txt 18 July 2004
61 This document describes how to prepare Unicode strings representing
62 user names and passwords for comparison. The document defines the
63 "SASLprep" profile of the "stringprep" algorithm to be used for both
64 user names and passwords. This profile is intended to be used by
65 Simple Authentication and Security Layer (SASL) mechanisms (such as
66 PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging
67 simple user names and/or passwords.
72 The use of simple user names and passwords in authentication and
73 authorization is pervasive on the Internet. To increase the
74 likelihood that user name and password input and comparison work in
75 ways that make sense for typical users throughout the world, this
76 document defines rules for preparing internationalized user names and
77 passwords for comparison. For simplicity and implementation ease, a
78 single algorithm is defined for both user names and passwords.
80 The algorithm assumes all strings are comprised of characters from the
81 Unicode [Unicode] character set.
83 This document defines the "SASLprep" profile of the "stringprep"
84 algorithm [StringPrep].
86 The profile is designed for use in Simple Authentication and Security
87 Layer ([SASL]) mechanisms such as [PLAIN]. It may be applicable
88 elsewhere simple user names and passwords are used. This profile is
89 not intended to be used to prepare identity strings which are not
90 simple user names (e.g., email addresses, domain names, distinguished
91 names), or where identity or password strings which are not character
92 data, or require different handling (e.g., case folding).
94 This document by itself does not alter the technical specification any
95 existing protocols. Any specification that wishes to use the
96 algorithm described in this document needs to explicitly incorporate
97 this document and provide precise details as to where and how this
98 algorithm is used by implementations of that specification.
101 2. The SASLprep profile
103 This section defines the "SASLprep" profile of the "stringprep"
104 algorithm [StringPrep]. This profile is intended to be used to
105 prepare strings representing simple user names and passwords.
110 Zeilenga SASLprep [Page 2]
112 INTERNET-DRAFT draft-ietf-sasl-saslprep-10.txt 18 July 2004
115 This profile uses Unicode 3.2 [Unicode].
117 Character names in this document use the notation for code points and
118 names from the Unicode Standard [Unicode]. For example, the letter
119 "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
120 In the lists of mappings and the prohibited characters, the "U+" is
121 left off to make the lists easier to read. The comments for character
122 ranges are shown in square brackets (such as "[CONTROL CHARACTERS]")
123 and do not come from the standard.
125 Note: a glossary of terms used in Unicode can be found in [Glossary].
126 Information on the Unicode character encoding model can be found in
132 This profile specifies:
133 - non-ASCII space characters [StringPrep, C.1.2] be mapped to SPACE
136 - the "commonly mapped to nothing" characters [StringPrep, B.1] be
143 This profile specifies using Unicode normalization form KC, as
144 described in Section 4 of [StringPrep].
147 2.3. Prohibited Output
149 This profile specifies the following characters:
151 - Non-ASCII space characters [StringPrep, C.1.2],
152 - ASCII control characters [StringPrep, C.2.1],
153 - Non-ASCII control characters [StringPrep, C.2.2],
154 - Private Use [StringPrep, C.3],
155 - Non-character code points [StringPrep, C.4],
156 - Surrogate code points [StringPrep, C.5],
157 - Inappropriate for plain text [StringPrep, C.6],
158 - Inappropriate for canonical representation [StringPrep, C.7],
159 - Change display properties or are deprecated [StringPrep, C.8], and
160 - Tagging characters [StringPrep, C.9].
162 are prohibited output.
166 Zeilenga SASLprep [Page 3]
168 INTERNET-DRAFT draft-ietf-sasl-saslprep-10.txt 18 July 2004
171 2.4. Bidirectional characters
173 This profile specifies checking bidirectional strings as described in
174 [StringPrep, Section 6].
177 2.5. Unassigned Code Points
179 This profile specifies [StringPrep, A.1] table as its list of
180 unassigned code points.
185 The following table provides examples of how various character data is
186 transformed by SASLprep string preparation algorithm
188 # Input Output Comments
189 - ----- ------ --------
190 1 I<U+00AD>X IX SOFT HYPHEN mapped to nothing
191 2 user user no transformation
192 3 USER USER case preserved, will not match #2
193 4 <U+00AA> a output is NFKC, input in ISO 8859-1
194 5 <U+2168> IX output is NFKC, will match #1
195 6 <U+0007> Error - prohibited character
196 7 <U+0627><U+0031> Error - bidirectional check
199 4. Security Considerations
201 This profile is intended to be used to prepare simple user names and
202 passwords strings for comparison or use in cryptographic functions
203 (e.g., message digests). The preparation algorithm was specifically
204 designed such that its output is canonical, and it is well-formed.
205 However, due to an anomaly [PR29] in the specification of Unicode
206 normalization, canonical equivalence is not guaranteed for a select
207 few character sequences. These sequences, however, do not appear in
208 well-formed text. This specification was published despite this known
209 technical problem. It is expected that this specification will be
210 revised before further progression on the Standards Track (after
211 [Unicode] and/or [StringPrep] specifications have been updated to
212 address this problem).
214 It is not intended to be used for to prepare identity strings which
215 are not simple user names (e.g., distinguished names, domain names),
216 nor is the profile intended to be used for simple user names which
217 require different handling (such as case folding). Protocols (or
218 applications of those protocols) which have application-specific
222 Zeilenga SASLprep [Page 4]
224 INTERNET-DRAFT draft-ietf-sasl-saslprep-10.txt 18 July 2004
227 identity forms and/or comparison algorithms should use mechanisms
228 specifically designed for these forms and algorithms.
230 Application of string preparation may have an impact upon the
231 feasibility of brute force and dictionary attacks. While the number
232 of possible prepared strings is less than the number of possible
233 Unicode strings, the number of usable names and passwords is greater
234 than if only ASCII was used. Though SASLprep eliminates some of
235 Unicode code point sequences as possible prepared strings, that
236 elimination generally makes the (canonical) output forms practicable
237 and prohibits nonsensical inputs.
239 User names and passwords should be protected from eavesdropping.
241 General "stringprep" and Unicode security considerations apply. Both
242 are discussed in [StringPrep].
245 5. IANA Considerations
247 This document details the "SASLprep" profile of [StringPrep] protocol.
248 Upon Standards Action the profile should be registered in the
249 stringprep profile registry.
251 Name of this profile: SASLprep
252 RFC in which the profile is defined: This RFC
253 Indicator whether or not this is the newest version of the
254 profile: This is the first version of the SASPprep profile.
259 This document borrows text from "Preparation of Internationalized
260 Strings ('stringprep')" and "Nameprep: A Stringprep Profile for
261 Internationalized Domain Names", both by Paul Hoffman and Marc
264 This document is a product of the IETF SASL WG.
267 7. Normative References
269 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
270 Internationalized Strings ('stringprep')", RFC 3454,
273 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
274 3.2.0" is defined by "The Unicode Standard, Version 3.0"
278 Zeilenga SASLprep [Page 5]
280 INTERNET-DRAFT draft-ietf-sasl-saslprep-10.txt 18 July 2004
283 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
284 as amended by the "Unicode Standard Annex #27: Unicode
285 3.1" (http://www.unicode.org/reports/tr27/) and by the
286 "Unicode Standard Annex #28: Unicode 3.2"
287 (http://www.unicode.org/reports/tr28/).
290 8. Informative References
292 [Glossary] The Unicode Consortium, "Unicode Glossary",
293 <http://www.unicode.org/glossary/>.
295 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
296 #17, Character Encoding Model", UTR17,
297 <http://www.unicode.org/unicode/reports/tr17/>, August
300 [SASL] Melnikov, A. (Editor), "Simple Authentication and
301 Security Layer (SASL)",
302 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
304 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism",
305 draft-ietf-sasl-crammd5-xx.txt, a work in progress.
307 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
308 Authentication as a SASL Mechanism",
309 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
311 [PLAIN] Zeilenga, K. (Editor), "The Plain SASL Mechanism",
312 draft-ietf-sasl-plain-xx.txt, a work in progress.
314 [PR29] "Public Review Issue #29: Normalization Issue",
315 <http://www.unicode.org/review/pr-29.html>, February
324 Email: Kurt@OpenLDAP.org
328 Intellectual Property Rights
330 The IETF takes no position regarding the validity or scope of any
334 Zeilenga SASLprep [Page 6]
336 INTERNET-DRAFT draft-ietf-sasl-saslprep-10.txt 18 July 2004
339 Intellectual Property Rights or other rights that might be claimed to
340 pertain to the implementation or use of the technology described in
341 this document or the extent to which any license under such rights
342 might or might not be available; nor does it represent that it has
343 made any independent effort to identify any such rights. Information
344 on the procedures with respect to rights in RFC documents can be found
345 in BCP 78 and BCP 79.
347 Copies of IPR disclosures made to the IETF Secretariat and any
348 assurances of licenses to be made available, or the result of an
349 attempt made to obtain a general license or permission for the use of
350 such proprietary rights by implementers or users of this specification
351 can be obtained from the IETF on-line IPR repository at
352 http://www.ietf.org/ipr.
354 The IETF invites any interested party to bring to its attention any
355 copyrights, patents or patent applications, or other proprietary
356 rights that may cover technology that may be required to implement
357 this standard. Please address the information to the IETF at
363 Copyright (C) The Internet Society (2004). This document is subject
364 to the rights, licenses and restrictions contained in BCP 78, and
365 except as set forth therein, the authors retain all their rights.
367 This document and the information contained herein are provided on an
368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
369 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
370 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
371 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
372 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
390 Zeilenga SASLprep [Page 7]