idnits 2.17.1 draft-ietf-sasl-saslprep-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 287. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 293), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 July 2004) is 7222 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Section 6' is mentioned on line 137, but not defined == Unused Reference: 'CRAM-MD5' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'DIGEST-MD5' is defined on line 247, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3454 (ref. 'StringPrep') (Obsoleted by RFC 7564) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- No information found for draft-ietf-sasl-crammd5-xx - is the name correct? -- No information found for draft-ietf-sasl-rfc2831bis-xx - is the name correct? -- No information found for draft-ietf-sasl-plain-xx - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standards Track OpenLDAP Foundation 4 Expires: January 2005 18 July 2004 6 SASLprep: Stringprep profile for user names and passwords 7 9 Status of Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as a Standards Track document. 13 Distribution of this memo is unlimited. Technical discussion of this 14 document will take place on the IETF SASL mailing list 15 . Please send editorial comments directly to the 16 document editor . 18 By submitting this Internet-Draft, I accept the provisions of Section 19 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 20 applicable patent or other IPR claims of which I am aware have been 21 disclosed, or will be disclosed, and any of which I become aware will 22 be disclosed, in accordance with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 . The list of 35 Internet-Draft Shadow Directories can be accessed at 36 . 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 This document describes how to prepare Unicode strings representing 46 user names and passwords for comparison. The document defines the 47 "SASLprep" profile of the "stringprep" algorithm to be used for both 48 user names and passwords. This profile is intended to be used by 49 Simple Authentication and Security Layer (SASL) mechanisms (such as 50 PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging 51 simple user names and/or passwords. 53 1. Introduction 55 The use of simple user names and passwords in authentication and 56 authorization is pervasive on the Internet. To increase the 57 likelihood that user name and password input and comparison work in 58 ways that make sense for typical users throughout the world, this 59 document defines rules for preparing internationalized user names and 60 passwords for comparison. For simplicity and implementation ease, a 61 single algorithm is defined for both user names and passwords. 63 The algorithm assumes all strings are comprised of characters from the 64 Unicode [Unicode] character set. 66 This document defines the "SASLprep" profile of the "stringprep" 67 algorithm [StringPrep]. 69 The profile is designed for use in Simple Authentication and Security 70 Layer ([SASL]) mechanisms such as [PLAIN]. It may be applicable 71 elsewhere simple user names and passwords are used. This profile is 72 not intended to be used to prepare identity strings which are not 73 simple user names (e.g., email addresses, domain names, distinguished 74 names), or where identity or password strings which are not character 75 data, or require different handling (e.g., case folding). 77 This document by itself does not alter the technical specification any 78 existing protocols. Any specification that wishes to use the 79 algorithm described in this document needs to explicitly incorporate 80 this document and provide precise details as to where and how this 81 algorithm is used by implementations of that specification. 83 2. The SASLprep profile 85 This section defines the "SASLprep" profile of the "stringprep" 86 algorithm [StringPrep]. This profile is intended to be used to 87 prepare strings representing simple user names and passwords. 89 This profile uses Unicode 3.2 [Unicode]. 91 Character names in this document use the notation for code points and 92 names from the Unicode Standard [Unicode]. For example, the letter 93 "a" may be represented as either or . 94 In the lists of mappings and the prohibited characters, the "U+" is 95 left off to make the lists easier to read. The comments for character 96 ranges are shown in square brackets (such as "[CONTROL CHARACTERS]") 97 and do not come from the standard. 99 Note: a glossary of terms used in Unicode can be found in [Glossary]. 100 Information on the Unicode character encoding model can be found in 101 [CharModel]. 103 2.1. Mapping 105 This profile specifies: 106 - non-ASCII space characters [StringPrep, C.1.2] be mapped to SPACE 107 (U+0020), and 109 - the "commonly mapped to nothing" characters [StringPrep, B.1] be 110 mapped to nothing. 112 2.2. Normalization 114 This profile specifies using Unicode normalization form KC, as 115 described in Section 4 of [StringPrep]. 117 2.3. Prohibited Output 119 This profile specifies the following characters: 121 - Non-ASCII space characters [StringPrep, C.1.2], 122 - ASCII control characters [StringPrep, C.2.1], 123 - Non-ASCII control characters [StringPrep, C.2.2], 124 - Private Use [StringPrep, C.3], 125 - Non-character code points [StringPrep, C.4], 126 - Surrogate code points [StringPrep, C.5], 127 - Inappropriate for plain text [StringPrep, C.6], 128 - Inappropriate for canonical representation [StringPrep, C.7], 129 - Change display properties or are deprecated [StringPrep, C.8], and 130 - Tagging characters [StringPrep, C.9]. 132 are prohibited output. 134 2.4. Bidirectional characters 136 This profile specifies checking bidirectional strings as described in 137 [StringPrep, Section 6]. 139 2.5. Unassigned Code Points 141 This profile specifies [StringPrep, A.1] table as its list of 142 unassigned code points. 144 3. Examples 146 The following table provides examples of how various character data is 147 transformed by SASLprep string preparation algorithm 149 # Input Output Comments 150 - ----- ------ -------- 151 1 IX IX SOFT HYPHEN mapped to nothing 152 2 user user no transformation 153 3 USER USER case preserved, will not match #2 154 4 a output is NFKC, input in ISO 8859-1 155 5 IX output is NFKC, will match #1 156 6 Error - prohibited character 157 7 Error - bidirectional check 159 4. Security Considerations 161 This profile is intended to be used to prepare simple user names and 162 passwords strings for comparison or use in cryptographic functions 163 (e.g., message digests). The preparation algorithm was specifically 164 designed such that its output is canonical, and it is well-formed. 165 However, due to an anomaly [PR29] in the specification of Unicode 166 normalization, canonical equivalence is not guaranteed for a select 167 few character sequences. These sequences, however, do not appear in 168 well-formed text. This specification was published despite this known 169 technical problem. It is expected that this specification will be 170 revised before further progression on the Standards Track (after 171 [Unicode] and/or [StringPrep] specifications have been updated to 172 address this problem). 174 It is not intended to be used for to prepare identity strings which 175 are not simple user names (e.g., distinguished names, domain names), 176 nor is the profile intended to be used for simple user names which 177 require different handling (such as case folding). Protocols (or 178 applications of those protocols) which have application-specific 179 identity forms and/or comparison algorithms should use mechanisms 180 specifically designed for these forms and algorithms. 182 Application of string preparation may have an impact upon the 183 feasibility of brute force and dictionary attacks. While the number 184 of possible prepared strings is less than the number of possible 185 Unicode strings, the number of usable names and passwords is greater 186 than if only ASCII was used. Though SASLprep eliminates some of 187 Unicode code point sequences as possible prepared strings, that 188 elimination generally makes the (canonical) output forms practicable 189 and prohibits nonsensical inputs. 191 User names and passwords should be protected from eavesdropping. 193 General "stringprep" and Unicode security considerations apply. Both 194 are discussed in [StringPrep]. 196 5. IANA Considerations 198 This document details the "SASLprep" profile of [StringPrep] protocol. 199 Upon Standards Action the profile should be registered in the 200 stringprep profile registry. 202 Name of this profile: SASLprep 203 RFC in which the profile is defined: This RFC 204 Indicator whether or not this is the newest version of the 205 profile: This is the first version of the SASPprep profile. 207 6. Acknowledgment 209 This document borrows text from "Preparation of Internationalized 210 Strings ('stringprep')" and "Nameprep: A Stringprep Profile for 211 Internationalized Domain Names", both by Paul Hoffman and Marc 212 Blanchet. 214 This document is a product of the IETF SASL WG. 216 7. Normative References 218 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of 219 Internationalized Strings ('stringprep')", RFC 3454, 220 December 2002. 222 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 223 3.2.0" is defined by "The Unicode Standard, Version 3.0" 224 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 225 as amended by the "Unicode Standard Annex #27: Unicode 226 3.1" (http://www.unicode.org/reports/tr27/) and by the 227 "Unicode Standard Annex #28: Unicode 3.2" 228 (http://www.unicode.org/reports/tr28/). 230 8. Informative References 232 [Glossary] The Unicode Consortium, "Unicode Glossary", 233 . 235 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 236 #17, Character Encoding Model", UTR17, 237 , August 238 2000. 240 [SASL] Melnikov, A. (Editor), "Simple Authentication and 241 Security Layer (SASL)", 242 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 244 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", 245 draft-ietf-sasl-crammd5-xx.txt, a work in progress. 247 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest 248 Authentication as a SASL Mechanism", 249 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress. 251 [PLAIN] Zeilenga, K. (Editor), "The Plain SASL Mechanism", 252 draft-ietf-sasl-plain-xx.txt, a work in progress. 254 [PR29] "Public Review Issue #29: Normalization Issue", 255 , February 256 2004. 258 9. Author's Address 260 Kurt D. Zeilenga 261 OpenLDAP Foundation 263 Email: Kurt@OpenLDAP.org 265 Intellectual Property Rights 267 The IETF takes no position regarding the validity or scope of any 268 Intellectual Property Rights or other rights that might be claimed to 269 pertain to the implementation or use of the technology described in 270 this document or the extent to which any license under such rights 271 might or might not be available; nor does it represent that it has 272 made any independent effort to identify any such rights. Information 273 on the procedures with respect to rights in RFC documents can be found 274 in BCP 78 and BCP 79. 276 Copies of IPR disclosures made to the IETF Secretariat and any 277 assurances of licenses to be made available, or the result of an 278 attempt made to obtain a general license or permission for the use of 279 such proprietary rights by implementers or users of this specification 280 can be obtained from the IETF on-line IPR repository at 281 http://www.ietf.org/ipr. 283 The IETF invites any interested party to bring to its attention any 284 copyrights, patents or patent applications, or other proprietary 285 rights that may cover technology that may be required to implement 286 this standard. Please address the information to the IETF at 287 ietf-ipr@ietf.org. 289 Full Copyright 291 Copyright (C) The Internet Society (2004). This document is subject 292 to the rights, licenses and restrictions contained in BCP 78, and 293 except as set forth therein, the authors retain all their rights. 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 298 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 299 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 300 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.