Precis P. Saint-Andre Internet-Draft Cisco Systems, Inc. Obsoletes: 4013 (if approved) A. Melnikov Intended status: Standards Track Isode Ltd Expires: September 6, 2012 March 5, 2012 Username and Password Preparation Algorithms draft-melnikov-precis-saslprepbis-00 Abstract This document describes how to prepare Unicode strings representing user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Saint-Andre & Melnikov Expires September 6, 2012 [Page 1] Internet-Draft SASLprep Bis March 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. User Name Preparation . . . . . . . . . . . . . . . . . . . . . 4 3. Password Preparation . . . . . . . . . . . . . . . . . . . . . 5 4. ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5.1. Password Strength . . . . . . . . . . . . . . . . . . . . . 6 5.2. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Use of NameClass . . . . . . . . . . . . . . . . . . . . . 6 6.2. Use of FreeClass . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . . 8 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Saint-Andre & Melnikov Expires September 6, 2012 [Page 2] Internet-Draft SASLprep Bis March 2012 1. Introduction 1.1. Overview 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 both work in ways that make sense for typical users throughout the world, this document defines rules for preparing internationalized user names and passwords, primarily for purposes of comparison. The algorithms defined in this document assume that all strings are comprised of characters from the Unicode [UNICODE] character set. The Unicode string preparation algorithms are designed for use in Simple Authentication and Security Layer ([SASL]) mechanisms, such as PLAIN [RFC4616] and SCRAM-SHA-1 [RFC5802]. They may be applicable where simple user names and 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), nor in cases where identity or password strings are not character data or require different handling (e.g., case folding). The PRECIS approach differs fundamentally from the stringprep approach taken in RFC 4013. The primary difference is that stringprep profiles allow all characters except those which are explicitly disallowed, whereas PRECIS profiles disallow all characters except those which are explicitly allowed (this "inclusion model" was originally used in [IDNA-PROTO], see [IDNA-RATIONALE] for further discussion). One result is that rarely-used Unicode characters or blocks (e.g., surrogate code points) do not need to be listed individually, since they are disallowed by default. It is important to keep this distinction in mind when comparing this document to RFC 4013. This document obsoletes RFC 4013. 1.2. Terminology Many important terms used in this document are defined in [FRAMEWORK], [I18N-TERMS], [IDNA-DEFS], and [UNICODE]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. Saint-Andre & Melnikov Expires September 6, 2012 [Page 3] Internet-Draft SASLprep Bis March 2012 2. User Name Preparation A user name MUST be processed as follows, where the operations specified MUST be completed in the order shown (note that some steps can be combined and performed at the same time): 1. (MAPPING 1) Non-ASCII space characters from the "N" category defined under Section 6.14 of [FRAMEWORK] MUST be mapped to SPACE (U+0020). 2. (MAPPING 2) Characters from the "M" category defined under Section 6.13 MUST be mapped to nothing (this category includes all of the "characters commonly mapped to nothing" from Appendix B.1 of [STRINGPREP]), except U+1806 MONGOLIAN TODO SOFT HYPHEN). 3. (MAPPING 3) Uppercase and titlecase characters MUST be mapped to their lowercase equivalents. [[NOTE: This differs from SASLprep, which allowed uppercase and titlecase characters.]] 4. (PRECIS) A user name MUST consist only of Unicode code points that conform to the "NameClass" base string class defined in [FRAMEWORK]. [[OPEN ISSUE: SASLprep allowed spaces in user names, should they be allowed here?]] 5. All characters MUST be mapped using Unicode Normalization Form C (NFC). [[OPEN ISSUE: This differs from SASLprep, which used NFKC.]] 6. After performing all of the above steps a user name MUST NOT be zero bytes in length. With regard to directionality, the "Bidi Rule" provided in [IDNA-BIDI] applies. As noted in the Introduction, all code points and blocks not explicitly allowed in the PRECIS NameClass are disallowed; this includes private use characters, surrogate code points, and the other code points and blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013. [[TODO: Double-check that all SASLprep prohibited output is indeed disallowed by the PRECIS NameClass.]] Saint-Andre & Melnikov Expires September 6, 2012 [Page 4] Internet-Draft SASLprep Bis March 2012 3. Password Preparation A password MUST be processed as follows, where the operations specified MUST be completed in the order shown (note that some steps can be combined and performed at the same time): 1. (MAPPING 1) non-ASCII space characters from the "N" category defined under Section 6.14 of [FRAMEWORK] MUST be mapped to SPACE (U+0020). 2. (MAPPING 2) Characters from the "M" category defined under Section 6.13 MUST be mapped to nothing (this category includes all of the "characters commonly mapped to nothing" from Appendix B.1 of [STRINGPREP]), except U+1806 MONGOLIAN TODO SOFT HYPHEN). 3. [[OPEN ISSUE: Map HasCompat ("Q") category?]] 4. (PRECIS) A password MUST consist only of Unicode code points that conform to the "FreeClass" base string class defined in [FRAMEWORK]. 5. All characters MUST be mapped using Unicode Normalization Form C (NFC). [[OPEN ISSUE: Use NFKC as in the original SASLprep?]] 6. After performing all of the above steps, a password MUST NOT be zero bytes in length. With regard to directionality, the "Bidi Rule" provided in [IDNA-BIDI] applies. As noted in the Introduction, all code points and blocks not explicitly allowed in the PRECIS FreeClass are disallowed; this includes private use characters, surrogate code points, and the other code points and blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013. [[TODO: Double-check that all SASLprep prohibited output is indeed disallowed by the PRECIS FreeClass.]] 4. ToDo Compare output of the new algorithms on Unicode 3.2 data with SASLprep and make sure that the PRECIS and KITTEN WGs are comfortable with the changes in which Unicode characters are allowed/disallowed (if any). Saint-Andre & Melnikov Expires September 6, 2012 [Page 5] Internet-Draft SASLprep Bis March 2012 5. Security Considerations 5.1. Password Strength The ability to include a wide range of characters in passwords is intended to increase the potential for creating a strong password with high entropy. However, in practice, the ability to include such characters needs to be weighed against the possible need to reproduce those characters on a various devices using various input methods. 5.2. Reuse of PRECIS The security considerations described in [FRAMEWORK] apply to the "NameClass" and "FreeClass" base string classes used in this document for user names and passwords, respectively. 5.3. Reuse of Unicode The security considerations described in [UTR39] apply to the use of Unicode characters in user names and passwords. 6. IANA Considerations 6.1. Use of NameClass The IANA shall add an entry to the PRECIS Usage Registry for reuse of the PRECIS NameClass in SASL, as follows: Application Protocol: SASL/Kerberos. Base Class: NameClass. Subclassing: Yes. See Section 2 of RFC XXXX. Directionality: The "Bidi Rule" defined in RFC 5893 applies. Casemapping: Uppercase and titlecase code points are mapped to their lowercase equivalents. Normalization: NFC. Specification: RFC XXXX. 6.2. Use of FreeClass The IANA shall add an entry to the PRECIS Usage Registry for reuse of the PRECIS FreeClass in SASL, as follows: Application Protocol: SASL/Kerberos. Saint-Andre & Melnikov Expires September 6, 2012 [Page 6] Internet-Draft SASLprep Bis March 2012 Base Class: FreeClass Subclassing: No. Directionality: The "Bidi Rule" defined in RFC 5893 applies. Casemapping: None. Normalization: NFC. Specification: RFC XXXX. 7. References 7.1. Normative References [FRAMEWORK] Blanchet, M. and P. Saint-Andre, "Precis Framework: Handling Internationalized Strings in Protocols", draft-ietf-precis-framework-01 (work in progress), October 2011. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000. 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/). 7.2. Informative References [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006. [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. [IDNA-BIDI] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010. [IDNA-DEFS] Saint-Andre & Melnikov Expires September 6, 2012 [Page 7] Internet-Draft SASLprep Bis March 2012 Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [IDNA-PROTO] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [I18N-TERMS] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", draft-hoffman-rfc3536bis-02 (work in progress), April 2011. [IDNA-RATIONALE] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010. [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [UTR39] The Unicode Consortium, "Unicode Technical Report #39: Unicode Security Mechanisms", August 2010, . Appendix A. Differences from RFC 4013 Based on consensus derived from implementation and deployment experience as well as formal interoperability testing, the following substantive modifications were made from RFC 4013. o A single SASLprep algorithm was replaced by two separate algorithms: one for user names and another for passwords. o The new preparation algorithms use PRECIS instead of a Stringprep profile. The algorithms are now Unicode version independent. Appendix B. Acknowledgements This document is partially based on text from RFC 4013. Saint-Andre & Melnikov Expires September 6, 2012 [Page 8] Internet-Draft SASLprep Bis March 2012 Authors' Addresses Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA Phone: +1-303-308-3282 Email: psaintan@cisco.com Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Alexey.Melnikov@isode.com Saint-Andre & Melnikov Expires September 6, 2012 [Page 9]