idnits 2.17.1 draft-ietf-sasl-saslprep-08.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 3978, Section 5.5 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 249. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 255), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 (12 April 2004) is 7309 days in the past. Is this intentional? 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 127, but not defined == Unused Reference: 'CRAM-MD5' is defined on line 210, but no explicit reference was found in the text == Unused Reference: 'DIGEST-MD5' is defined on line 213, 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: 11 errors (**), 0 flaws (~~), 4 warnings (==), 11 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: September 2004 12 April 2004 6 SASLprep: Stringprep profile for user names and passwords 7 9 Status of Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. 14 This document is intended to be, after appropriate review and 15 revision, submitted to the RFC Editor as a Standards Track document. 16 Distribution of this memo is unlimited. Technical discussion of this 17 document will take place on the IETF SASL mailing list 18 . Please send editorial comments directly to the 19 document editor . 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 . The list of 31 Internet-Draft Shadow Directories can be accessed at 32 . 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Please see the Full Copyright section near the end of this document 37 for more information. 39 Abstract 41 This document describes how to prepare Unicode strings representing 42 user names and passwords for comparison. The document defines the 43 "SASLprep" profile of the "stringprep" algorithm to be used for both 44 user names and passwords. This profile is intended to be used by 45 Simple Authentication and Security Layer (SASL) mechanisms (such as 46 PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging 47 simple user names and/or passwords. 49 1. Introduction 51 The use of simple user names and passwords in authentication and 52 authorization is pervasive on the Internet. To increase the 53 likelihood that user name and password input and comparison work in 54 ways that make sense for typical users throughout the world, this 55 document defines rules for preparing internationalized user names and 56 passwords for comparison. For simplicity and implementation ease, a 57 single algorithm is defined for both user names and passwords. 59 The algorithm assumes all strings are comprised of characters from the 60 Unicode character set. 62 This document defines the "SASLprep" profile of the "stringprep" 63 algorithm [StringPrep]. 65 The profile is designed for use in Simple Authentication and Security 66 Layer ([SASL]) mechanisms such as [PLAIN]. It may be applicable 67 elsewhere simple user names and passwords are used. This profile is 68 not intended to be used to prepare identity strings which are not 69 simple user names (e.g., e-mail addresses, domain names, distinguished 70 names), or where identity or password strings which are not character 71 data. 73 2. The SASLprep profile 75 This section defines the "SASLprep" profile of the "stringprep" 76 algorithm [StringPrep]. This profile is intended to be used to 77 prepare strings representing simple user names and passwords. 79 This profile uses Unicode 3.2 [Unicode]. 81 Character names in this document use the notation for code points and 82 names from the Unicode Standard [Unicode]. For example, the letter 83 "a" may be represented as either or . 84 In the lists of mappings and the prohibited characters, the "U+" is 85 left off to make the lists easier to read. The comments for character 86 ranges are shown in square brackets (such as "[CONTROL CHARACTERS]") 87 and do not come from the standard. 89 Note: a glossary of terms used in Unicode can be found in [Glossary]. 90 Information on the Unicode character encoding model can be found in 91 [CharModel]. 93 2.1. Mapping 95 This profile specifies: 96 - non-ASCII space characters [StringPrep, C.1.2] be mapped to SPACE 97 (U+0020), and 99 - the "commonly mapped to nothing" characters [StringPrep, B.1] be 100 mapped to nothing. 102 2.2. Normalization 104 This profile specifies using Unicode normalization form KC, as 105 described in Section 4 of [StringPrep]. 107 2.3. Prohibited Output 109 This profile specifies the following characters: 111 - Non-ASCII space characters [StringPrep, C.1.2], 112 - ASCII control characters [StringPrep, C.2.1], 113 - Non-ASCII control characters [StringPrep, C.2.2], 114 - Private Use [StringPrep, C.3], 115 - Non-character code points [StringPrep, C.4], 116 - Surrogate code points [StringPrep, C.5], 117 - Inappropriate for plain text [StringPrep, C.6], 118 - Inappropriate for canonical representation [StringPrep, C.7], 119 - Change display properties or are deprecated [StringPrep, C.8], and 120 - Tagging characters [StringPrep, C.9]. 122 are prohibited output. 124 2.4. Bidirectional characters 126 This profile specifies checking bidirectional strings as described in 127 [StringPrep, Section 6]. 129 2.5. Unassigned Code Points 131 This profile specifies [StringPrep, A.1] table as its list of 132 unassigned code points. 134 3. Security Considerations 135 This profile is intended to used to prepare simple user names and 136 passwords strings for comparison or use in cryptographic functions 137 (e.g., message digests). The preparation algorithm is specifically 138 designed such that its output is canonical. 140 It is not intended to be used for to prepare identity strings which 141 are not simple user names (e.g., distinguished names and domain 142 names). Nor is the profile intended to be used for simple user names 143 which require different handling. Protocols (or applications of those 144 protocols) which have application-specific identity forms and/or 145 comparison algorithms should use mechanisms specifically designed for 146 these forms and algorithms. 148 Application of string preparation may have an impact upon the 149 feasibility of brute force and dictionary attacks. While the number 150 of possible prepared strings is less than the number of possible 151 Unicode strings, the number of usable names and passwords is greater 152 than if only ASCII was used. Though SASLprep eliminates some of 153 Unicode code point sequences as possible prepared strings, that 154 elimination generally makes the (canonical) output forms practicable 155 and prohibits nonsensical inputs. 157 User names and passwords should be protected from eavesdropping. 159 General "stringprep" and Unicode security considerations apply. Both 160 are discussed in [StringPrep]. 162 4. IANA Considerations 164 This document details the "SASLprep" profile of [StringPrep] protocol. 165 Upon Standards Action the profile should be registered in the 166 stringprep profile registry. 168 Name of this profile: SASLprep 169 RFC in which the profile is defined: This RFC 170 Indicator whether or not this is the newest version of the 171 profile: This is the first version of the SASPprep profile. 173 5. Acknowledgment 175 This document borrows text from "Preparation of Internationalized 176 Strings ('stringprep')" and "Nameprep: A Stringprep Profile for 177 Internationalized Domain Names", both by Paul Hoffman and Marc 178 Blanchet. 180 This document is a product of the IETF SASL WG. 182 6. Normative References 184 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of 185 Internationalized Strings ('stringprep')", RFC 3454, 186 December 2002. 188 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 189 3.2.0" is defined by "The Unicode Standard, Version 3.0" 190 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 191 as amended by the "Unicode Standard Annex #27: Unicode 192 3.1" (http://www.unicode.org/reports/tr27/) and by the 193 "Unicode Standard Annex #28: Unicode 3.2" 194 (http://www.unicode.org/reports/tr28/). 196 7. Informative References 198 [Glossary] The Unicode Consortium, "Unicode Glossary", 199 . 201 [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report 202 #17, Character Encoding Model", UTR17, 203 , August 204 2000. 206 [SASL] Melnikov, A. (Editor), "Simple Authentication and 207 Security Layer (SASL)", 208 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 210 [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", 211 draft-ietf-sasl-crammd5-xx.txt, a work in progress. 213 [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest 214 Authentication as a SASL Mechanism", 215 draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress. 217 [PLAIN] Zeilenga, K. (Editor), "The Plain SASL Mechanism", 218 draft-ietf-sasl-plain-xx.txt, a work in progress. 220 8. Editor's Address 222 Kurt D. Zeilenga 223 OpenLDAP Foundation 225 Email: Kurt@OpenLDAP.org 227 Intellectual Property Rights 229 The IETF takes no position regarding the validity or scope of any 230 Intellectual Property Rights or other rights that might be claimed to 231 pertain to the implementation or use of the technology described in 232 this document or the extent to which any license under such rights 233 might or might not be available; nor does it represent that it has 234 made any independent effort to identify any such rights. Information 235 on the procedures with respect to rights in RFC documents can be found 236 in BCP 78 and BCP 79. 238 Copies of IPR disclosures made to the IETF Secretariat and any 239 assurances of licenses to be made available, or the result of an 240 attempt made to obtain a general license or permission for the use of 241 such proprietary rights by implementers or users of this specification 242 can be obtained from the IETF on-line IPR repository at 243 http://www.ietf.org/ipr. 245 The IETF invites any interested party to bring to its attention any 246 copyrights, patents or patent applications, or other proprietary 247 rights that may cover technology that may be required to implement 248 this standard. Please address the information to the IETF at ietf- 249 ipr@ietf.org. 251 Full Copyright 253 Copyright (C) The Internet Society (2004). This document is subject 254 to the rights, licenses and restrictions contained in BCP 78 and 255 except as set forth therein, the authors retain all their rights. 257 This document and the information contained herein are provided on an 258 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 259 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 260 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 261 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 262 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 263 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.