From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4013.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc4013.txt (limited to 'doc/rfc/rfc4013.txt') diff --git a/doc/rfc/rfc4013.txt b/doc/rfc/rfc4013.txt new file mode 100644 index 0000000..54a1d31 --- /dev/null +++ b/doc/rfc/rfc4013.txt @@ -0,0 +1,339 @@ + + + + + + +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 or . + 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 IX IX SOFT HYPHEN mapped to nothing + 2 user user no transformation + 3 USER USER case preserved, will not match #2 + 4 a output is NFKC, input in ISO 8859-1 + 5 IX output is NFKC, will match #1 + 6 Error - prohibited character + 7 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", + . + + [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report + #17, Character Encoding Model", UTR17, + , 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", + , 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] + -- cgit v1.2.3