Add.
[gsasl.git] / doc / specification / draft-ietf-sasl-saslprep-10.txt
blob444a19e1046ada53316e669979c40e2a82541a33
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>
14 Status of Memo
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
46   for more information.
54 Zeilenga                        SASLprep                        [Page 1]
56 INTERNET-DRAFT       draft-ietf-sasl-saslprep-10.txt        18 July 2004
59 Abstract
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.
70 1. Introduction
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
127   [CharModel].
130 2.1. Mapping
132   This profile specifies:
133     - non-ASCII space characters [StringPrep, C.1.2] be mapped to SPACE
134       (U+0020), and
136     - the "commonly mapped to nothing" characters [StringPrep, B.1] be
137       mapped to nothing.
141 2.2. Normalization
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.
183 3. Examples
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.
257 6. Acknowledgment
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
262   Blanchet.
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,
271                 December 2002.
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
298                 2000.
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
316                 2004.
319 9. Author's Address
321   Kurt D. Zeilenga
322   OpenLDAP Foundation
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
358   ietf-ipr@ietf.org.
361 Full Copyright
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]