mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-15 03:01:09 +08:00
340 lines
13 KiB
Plaintext
340 lines
13 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group K. Zeilenga
|
||
Request for Comments: 4013 OpenLDAP Foundation
|
||
Category: Standards Track February 2005
|
||
|
||
|
||
SASLprep: Stringprep Profile for User Names and Passwords
|
||
|
||
Status of This Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2005).
|
||
|
||
Abstract
|
||
|
||
This document describes how to prepare Unicode strings representing
|
||
user names and passwords for comparison. The document defines the
|
||
"SASLprep" profile of the "stringprep" algorithm to be used for both
|
||
user names and passwords. This profile is intended to be used by
|
||
Simple Authentication and Security Layer (SASL) mechanisms (such as
|
||
PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols
|
||
exchanging simple user names and/or passwords.
|
||
|
||
1. Introduction
|
||
|
||
The use of simple user names and passwords in authentication and
|
||
authorization is pervasive on the Internet. To increase the
|
||
likelihood that user name and password input and comparison work in
|
||
ways that make sense for typical users throughout the world, this
|
||
document defines rules for preparing internationalized user names and
|
||
passwords for comparison. For simplicity and implementation ease, a
|
||
single algorithm is defined for both user names and passwords.
|
||
|
||
The algorithm assumes all strings are comprised of characters from
|
||
the Unicode [Unicode] character set.
|
||
|
||
This document defines the "SASLprep" profile of the "stringprep"
|
||
algorithm [StringPrep].
|
||
|
||
The profile is designed for use in Simple Authentication and Security
|
||
Layer ([SASL]) mechanisms, such as [PLAIN], [CRAM-MD5], and
|
||
[DIGEST-MD5]. It may be applicable where simple user names and
|
||
|
||
|
||
|
||
Zeilenga Standards Track [Page 1]
|
||
|
||
RFC 4013 SASLprep February 2005
|
||
|
||
|
||
passwords are used. This profile is not intended for use in
|
||
preparing identity strings that are not simple user names (e.g.,
|
||
email addresses, domain names, distinguished names), or where
|
||
identity or password strings that are not character data, or require
|
||
different handling (e.g., case folding).
|
||
|
||
This document does not alter the technical specification of any
|
||
existing protocols. Any specification that wishes to use the
|
||
algorithm described in this document needs to explicitly incorporate
|
||
this document and provide precise details as to where and how this
|
||
algorithm is used by implementations of that specification.
|
||
|
||
2. The SASLprep Profile
|
||
|
||
This section defines the "SASLprep" profile of the "stringprep"
|
||
algorithm [StringPrep]. This profile is intended for use in
|
||
preparing strings representing simple user names and passwords.
|
||
|
||
This profile uses Unicode 3.2 [Unicode].
|
||
|
||
Character names in this document use the notation for code points and
|
||
names from the Unicode Standard [Unicode]. For example, the letter
|
||
"a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
|
||
In the lists of mappings and the prohibited characters, the "U+" is
|
||
left off to make the lists easier to read. The comments for
|
||
character ranges are shown in square brackets (such as "[CONTROL
|
||
CHARACTERS]") and do not come from the standard.
|
||
|
||
Note: A glossary of terms used in Unicode can be found in [Glossary].
|
||
Information on the Unicode character encoding model can be found in
|
||
[CharModel].
|
||
|
||
2.1. Mapping
|
||
|
||
This profile specifies:
|
||
|
||
- non-ASCII space characters [StringPrep, C.1.2] that can be
|
||
mapped to SPACE (U+0020), and
|
||
|
||
- the "commonly mapped to nothing" characters [StringPrep, B.1]
|
||
that can be mapped to nothing.
|
||
|
||
2.2. Normalization
|
||
|
||
This profile specifies using Unicode normalization form KC, as
|
||
described in Section 4 of [StringPrep].
|
||
|
||
|
||
|
||
|
||
|
||
Zeilenga Standards Track [Page 2]
|
||
|
||
RFC 4013 SASLprep February 2005
|
||
|
||
|
||
2.3. Prohibited Output
|
||
|
||
This profile specifies the following characters as prohibited input:
|
||
|
||
- Non-ASCII space characters [StringPrep, C.1.2]
|
||
- ASCII control characters [StringPrep, C.2.1]
|
||
- Non-ASCII control characters [StringPrep, C.2.2]
|
||
- Private Use characters [StringPrep, C.3]
|
||
- Non-character code points [StringPrep, C.4]
|
||
- Surrogate code points [StringPrep, C.5]
|
||
- Inappropriate for plain text characters [StringPrep, C.6]
|
||
- Inappropriate for canonical representation characters
|
||
[StringPrep, C.7]
|
||
- Change display properties or deprecated characters
|
||
[StringPrep, C.8]
|
||
- Tagging characters [StringPrep, C.9]
|
||
|
||
2.4. Bidirectional Characters
|
||
|
||
This profile specifies checking bidirectional strings as described in
|
||
[StringPrep, Section 6].
|
||
|
||
2.5. Unassigned Code Points
|
||
|
||
This profile specifies the [StringPrep, A.1] table as its list of
|
||
unassigned code points.
|
||
|
||
3. Examples
|
||
|
||
The following table provides examples of how various character data
|
||
is transformed by the SASLprep string preparation algorithm
|
||
|
||
# Input Output Comments
|
||
- ----- ------ --------
|
||
1 I<U+00AD>X IX SOFT HYPHEN mapped to nothing
|
||
2 user user no transformation
|
||
3 USER USER case preserved, will not match #2
|
||
4 <U+00AA> a output is NFKC, input in ISO 8859-1
|
||
5 <U+2168> IX output is NFKC, will match #1
|
||
6 <U+0007> Error - prohibited character
|
||
7 <U+0627><U+0031> Error - bidirectional check
|
||
|
||
4. Security Considerations
|
||
|
||
This profile is intended to prepare simple user name and password
|
||
strings for comparison or use in cryptographic functions (e.g.,
|
||
message digests). The preparation algorithm was specifically
|
||
designed such that its output is canonical, and it is well-formed.
|
||
|
||
|
||
|
||
Zeilenga Standards Track [Page 3]
|
||
|
||
RFC 4013 SASLprep February 2005
|
||
|
||
|
||
However, due to an anomaly [PR29] in the specification of Unicode
|
||
normalization, canonical equivalence is not guaranteed for a select
|
||
few character sequences. These sequences, however, do not appear in
|
||
well-formed text. This specification was published despite this
|
||
known technical problem. It is expected that this specification will
|
||
be revised before further progression on the Standards Track (after
|
||
[Unicode] and/or [StringPrep] specifications have been updated to
|
||
address this problem).
|
||
|
||
It is not intended for preparing identity strings that are not simple
|
||
user names (e.g., distinguished names, domain names), nor is the
|
||
profile intended for use of simple user names that require different
|
||
handling (such as case folding). Protocols (or applications of those
|
||
protocols) that have application-specific identity forms and/or
|
||
comparison algorithms should use mechanisms specifically designed for
|
||
these forms and algorithms.
|
||
|
||
Application of string preparation may have an impact upon the
|
||
feasibility of brute force and dictionary attacks. While the number
|
||
of possible prepared strings is less than the number of possible
|
||
Unicode strings, the number of usable names and passwords is greater
|
||
than as if only ASCII was used. Though SASLprep eliminates some
|
||
Unicode code point sequences as possible prepared strings, that
|
||
elimination generally makes the (canonical) output forms practicable
|
||
and prohibits nonsensical inputs.
|
||
|
||
User names and passwords should be protected from eavesdropping.
|
||
|
||
General "stringprep" and Unicode security considerations apply. Both
|
||
are discussed in [StringPrep].
|
||
|
||
5. IANA Considerations
|
||
|
||
This document details the "SASLprep" profile of the [StringPrep]
|
||
protocol. This profile has been registered in the stringprep profile
|
||
registry.
|
||
|
||
Name of this profile: SASLprep
|
||
RFC in which the profile is defined: RFC 4013
|
||
Indicator whether or not this is the newest version of the
|
||
profile: This is the first version of the SASPprep profile.
|
||
|
||
6. Acknowledgement
|
||
|
||
This document borrows text from "Preparation of Internationalized
|
||
Strings ('stringprep')" and "Nameprep: A Stringprep Profile for
|
||
Internationalized Domain Names", both by Paul Hoffman and Marc
|
||
Blanchet. This document is a product of the IETF SASL WG.
|
||
|
||
|
||
|
||
Zeilenga Standards Track [Page 4]
|
||
|
||
RFC 4013 SASLprep February 2005
|
||
|
||
|
||
7. Normative References
|
||
|
||
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
|
||
Internationalized Strings ("stringprep")", RFC 3454,
|
||
December 2002.
|
||
|
||
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
|
||
3.2.0" is defined by "The Unicode Standard, Version
|
||
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
|
||
61633-5), as amended by the "Unicode Standard Annex
|
||
#27: Unicode 3.1"
|
||
(http://www.unicode.org/reports/tr27/) and by the
|
||
"Unicode Standard Annex #28: Unicode 3.2"
|
||
(http://www.unicode.org/reports/tr28/).
|
||
|
||
8. Informative References
|
||
|
||
[Glossary] The Unicode Consortium, "Unicode Glossary",
|
||
<http://www.unicode.org/glossary/>.
|
||
|
||
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
|
||
#17, Character Encoding Model", UTR17,
|
||
<http://www.unicode.org/unicode/reports/tr17/>, August
|
||
2000.
|
||
|
||
[SASL] Melnikov, A., Ed., "Simple Authentication and Security
|
||
Layer (SASL)", Work in Progress.
|
||
|
||
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
|
||
Progress.
|
||
|
||
[DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
|
||
Authentication as a SASL Mechanism", Work in Progress.
|
||
|
||
[PLAIN] Zeilenga, K., Ed., "The Plain SASL Mechanism", Work in
|
||
Progress.
|
||
|
||
[PR29] "Public Review Issue #29: Normalization Issue",
|
||
<http://www.unicode.org/review/pr-29.html>, February
|
||
2004.
|
||
|
||
Author's Address
|
||
|
||
Kurt D. Zeilenga
|
||
OpenLDAP Foundation
|
||
|
||
EMail: Kurt@OpenLDAP.org
|
||
|
||
|
||
|
||
|
||
Zeilenga Standards Track [Page 5]
|
||
|
||
RFC 4013 SASLprep February 2005
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2005).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the IETF's procedures with respect to rights in IETF Documents can
|
||
be found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at ietf-
|
||
ipr@ietf.org.
|
||
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Zeilenga Standards Track [Page 6]
|
||
|