One document matched: draft-ietf-precis-saslprepbis-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-ietf-precis-saslprepbis-01" ipr="trust200902" obsoletes="4013">
<front>
<title abbrev="PRECIS: Usernames and Passwords">Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
<organization>Isode Ltd</organization>
<address>
<postal>
<street>5 Castle Business Village</street>
<street>36 Station Road</street>
<city>Hampton</city>
<region>Middlesex</region>
<code>TW12 2BX</code>
<country>UK</country>
</postal>
<email>Alexey.Melnikov@isode.com</email>
</address>
</author>
<date day="27" month="March" year="2013"/>
<area>Applications</area>
<workgroup>PRECIS</workgroup>
<keyword>Username</keyword>
<keyword>Password</keyword>
<keyword>Unicode</keyword>
<keyword>Internationalization</keyword>
<keyword>SASLprep</keyword>
<abstract>
<t>This document describes how to handle Unicode strings representing simple 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<section title="Overview" anchor="overview">
<t>User names and passwords are used pervasively in authentication and authorization on the Internet. To increase the likelihood that the input and comparison of user names and passwords will work in ways that make sense for typical users throughout the world, this document defines rules for preparing and comparing internationalized strings that represent simple user names and passwords. (In many authentication technologies passwords are not directly compared because the actual password is used as input to an algorithm such as a hash function; however, non-ASCII code points in the input string still need to be handled correctly.)</t>
<t>The algorithms defined in this document assume that all strings are comprised of characters from the Unicode character set <xref target="UNICODE"/>.</t>
<t>The algorithms are designed for use in Simple Authentication and Security Layer (SASL) <xref target="RFC4422"/> mechanisms, such as PLAIN <xref target="RFC4616"/> and SCRAM-SHA-1 <xref target="RFC5802"/>. However, they might be applicable wherever simple user names or passwords are used. This profile is not intended for use in preparing strings that are not simple user names (e.g., email addresses, DNS domain names, LDAP distinguished names), nor in cases where identifiers or secrets are not strings (e.g., keys or certificates) or require different handling (e.g., case folding).</t>
<t>This document builds upon the PRECIS framework defined in <xref target='FRAMEWORK'/>, which differs fundamentally from the stringprep technology <xref target='RFC3454'/> used in SASLprep <xref target='RFC4013'/>. The primary difference is that stringprep profiles allowed all characters except those which were explicitly disallowed, whereas PRECIS profiles disallow all characters except those which are explicitly allowed (this "inclusion model" was originally used for internationalized domain names in <xref target='RFC5891'/>; see <xref target='RFC5894'/> for further discussion). It is important to keep this distinction in mind when comparing the technology defined in this document to SASLprep <xref target='RFC4013'/>.</t>
<t>This document obsoletes RFC 4013.</t>
</section>
<section title="Terminology" anchor="terms">
<t>Many important terms used in this document are defined in <xref target='FRAMEWORK'/>, <xref target='RFC4422'/>, <xref target='RFC5890'/>, <xref target='RFC6365'/>, and <xref target='UNICODE'/>. The term "non-ASCII space" refers to any Unicode code point with a general category of "Zs", with the exception of U+0020 (here called "ASCII space").</t>
<t>As used here, the term "password" is not literally limited to a word; i.e., a password could be a passphrase consisting of more than one word, perhaps separated by spaces or other such characters.</t>
<t>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 <xref target='RFC2119'/>.</t>
</section>
</section>
<section title='Simple User Names' anchor='username'>
<section title='Definition' anchor='username-definition'>
<t>Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify that the authentication identity used in the context of such mechanisms is a "simple user name" (see Section 2 of <xref target='RFC4422'/> as well as <xref target='RFC4013'/>). However, the exact form of a simple user name in any particular mechanism or deployment thereof is a local matter, and a simple user name does not necessarily map to an application identifier such as the localpart of an email address.</t>
<t>For purposes of preparation and comparison of authentication identities, this document specifies that a simple user name is a string of Unicode code points <xref target='UNICODE'/>, encoded using UTF-8 <xref target='RFC3629'/>, and structured either as an ordered sequence of "simpleparts" (where the complete simple user name can consist of a single simplepart or a space-separated sequence of simpleparts) or as a simplepart@domainpart (where the domainpart is an IP literal, an IPv4 address, or a fully-qualified domain name).</t>
<t>Therefore the syntax for a simple user name is defined as follows using the Augmented Backus-Naur Form (ABNF) as specified in <xref target="RFC5234"/>.</t>
<figure>
<artwork><![CDATA[
simpleusername = simplepart [1*(1*SP simplepart)]
/ simplepart '@' domainpart
simplepart = 1*(idpoint)
;
; an "idpoint" is a UTF-8 encoded
; Unicode code point that conforms to
; the PRECIS "IdentifierClass"
;
domainpart = IP-literal / IPv4address / ifqdn
;
; the "IPv4address" and "IP-literal"
; rules are defined in RFC 3986, and
; the first-match-wins (a.k.a. "greedy")
; algorithm described in RFC 3986
; applies to the matching process
;
; note well that reuse of the IP-literal
; rule from RFC 3986 implies that IPv6
; addresses are enclosed in square
; brackets (i.e., beginning with '['
; and ending with ']')
;
ifqdn = 1*1023(domainpoint)
;
; a "domainpoint" is a UTF-8 encoded
; Unicode code point that conforms to
; RFC 5890
;
]]></artwork>
</figure>
<t>Note well that all code points and blocks not explicitly allowed in the PRECIS IdentifierClass 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.</t>
<t>Note also that common constructions such as "user@example.com" are allowed as simple user names when using software that conforms to this specification, as they were under <xref target='RFC4013'/>.</t>
</section>
<section title='Preparation' anchor='username-preparation'>
<t>A simple user name MUST NOT be zero bytes in length. This rule is to be enforced after any normalization and mapping of code points.</t>
<t>Each simplepart of a simple user name MUST conform to the definition of the PRECIS IdentifierClass provided in <xref target='FRAMEWORK'/>, where the normalization, casemapping, and directionality rules are as described below.</t>
<t>
<list style='numbers'>
<t>Unicode Normalization Form C (NFC) MUST be applied to all characters.</t>
<t>Uppercase and titlecase characters MUST be mapped to their lowercase equivalents.</t>
<t>Additional mappings MAY be applied, such as those defined in <xref target='I-D.ietf-precis-mappings'/>.</t>
</list>
</t>
<t>With regard to directionality, the "Bidi Rule" provided in <xref target='RFC5893'/> applies.</t>
</section>
</section>
<section title='Passwords' anchor='password'>
<section title='Definition' anchor='password-definition'>
<t>For purposes of preparation and comparison of passwords, this document specifies that a password is a string of Unicode code points <xref target='UNICODE'/>, encoded using UTF-8 <xref target='RFC3629'/>, and conformant to the PRECIS FreeformClass.</t>
<t>Therefore the syntax for a password is defined as follows using the Augmented Backus-Naur Form (ABNF) as specified in <xref target="RFC5234"/>.</t>
<figure>
<artwork><![CDATA[
password = 1*(freepoint)
;
; a "freepoint" is a UTF-8 encoded
; Unicode code point that conforms to
; the PRECIS "FreeformClass"
;
]]></artwork>
</figure>
<t>Note well that all code points and blocks not explicitly allowed in the PRECIS FreeformClass 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.</t>
</section>
<section title='Preparation' anchor='password-preparation'>
<t>A password MUST NOT be zero bytes in length. This rule is to be enforced after any normalization and mapping of code points.</t>
<t>A password MUST be treated as follows, where the operations specified MUST be completed in the order shown:</t>
<t>
<list style='numbers'>
<t>Apply Unicode Normalization Form C (NFC) to all characters.</t>
<t>Map any instances of non-ASCII space to ASCII space (U+0020).</t>
<t>Ensure that the resulting string conforms to the definition of the PRECIS FreeformClass.</t>
</list>
</t>
<t>With regard to directionality, the "Bidi Rule" (defined in <xref target='RFC5893'/>) and similar rules are unnecessary and inapplicable to passwords, since they can reduce the range of characters that are allowed in a string and therefore reduce the amount of entropy that is possible in a password. Furthermore, such rules are intended to minimize the possibility that the same string will be displayed differently on a system set for right-to-left display and a system set for left-to-right display; however, passwords are typically not displayed at all and are rarely meant to be interoperable across different systems in the way that non-secret strings like domain names and user names are.</t>
</section>
</section>
<section title="Migration" anchor='migration'>
<t>The rules defined in this specification differ slightly from those defined by the SASLprep specification <xref target='RFC4013'/>. The following sections describe these differences, along with their implications for migration, in more detail.</t>
<section title='User Names' anchor='migration-usernames'>
<t>Deployments that currently use SASLprep for handling user names might need to scrub existing data when migrating to use of the rules defined in this specification. In particular:</t>
<t>
<list style='symbols'>
<t>SASLprep specified the use of Unicode Normalization Form KC (NFKC), whereas this usage of the PRECIS IdentifierClass employs Unicode Normalization Form C (NFC). In practice this change is unlikely to cause significant problems, because NFKC provides methods for mapping Unicode code points with compatibility equivalents to those equivalents, whereas the PRECIS IdentifierClass entirely disallows Unicode code points with compatibility equivalents (i.e., during comparison NFKC is more "aggressive" about finding matches than is NFC). A few examples might suffice to indicate the nature of the problem: (1) U+017F LATIN SMALL LETTER LONG S is compatibility equivalent to U+0073 LATIN SMALL LETTER S (2) U+2163 ROMAN NUMERAL FOUR is compatibility equivalent to U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V (3) U+FB01 LATIN SMALL LIGATURE FI is compatibility equivalent to U+0066 LATIN SMALL LETTER F and U+0069 LATIN SMALL LETTER I. Under SASLprep, the use of NFKC also handled the mapping of fullwidth and halfwidth code points to their decomposition equivalents (see <xref target='I-D.ietf-precis-mappings'/>). Although it is expected that code points with compatibility equivalents are rare in existing user names, for migration purposes deployments might want to search their database of user names for Unicode code points with compatibility equivalents and map those code points to their compatibility equivalents.</t>
<t>SASLprep mapped non-ASCII spaces to ASCII space (U+0020), whereas the PRECIS IdentifierClass entirely disallows non-ASCII spaces. The non-ASCII space characters are U+00A0 NO-BREAK SPACE, U+1680 OGHAM SPACE MARK, U+180E MONGOLIAN VOWEL SEPARATOR, U+2000 EN QUAD through U+200A HAIR SPACE, U+202F NARROW NO-BREAK SPACE, U+205F MEDIUM MATHEMATICAL SPACE, and U+3000 IDEOGRAPHIC SPACE. For migration purposes, deployments might want to convert non-ASCII space characters to ASCII space in simple user names.</t>
<t>SASLprep mapped the "characters commonly mapped to nothing" from Appendix B.1 of <xref target='RFC3454'/>) to nothing, whereas the PRECIS IdentifierClass entirely disallows most of these characters, which correspond to the code points from the "M" category defined under Section 6.13 of <xref target='FRAMEWORK'/> (with the exception of U+1806 MONGOLIAN TODO SOFT HYPHEN, which was "commonly mapped to nothing" in Unicode 3.2 but at the time of this writing does not have a derived property of Default_Ignorable_Code_Point in Unicode 6.1). For migration purposes, deployments might want to remove code points contained in the PRECIS "M" category from simple user names.</t>
<t>SASLprep allowed uppercase and titlecase characters, whereas this usage of the PRECIS IdentifierClass maps uppercase and titlecase characters to their lowercase equivalents. For migration purposes, deployments can either convert uppercase and titlecase characters to their lowercase equivalents in simple user names (thus losing the case information) or preserve uppercase and titlecase characters and ignore the case difference when comparing simple user names.</t>
</list>
</t>
</section>
<section title='Passwords' anchor='migration-passwords'>
<t>Depending on local service policy, migration from RFC 4013 to this specification might not involve any scrubbing of data (since passwords might not be stored in the clear anyway); however, service providers need to be aware of possible issues that might arise during migration. In particular:</t>
<t>
<list style='symbols'>
<t>SASLprep specified the use of Unicode Normalization Form KC (NFKC), whereas this usage of the PRECIS FreeformClass employs Unicode Normalization Form C (NFC). Because NFKC is more aggressive about finding matches than NFC, in practice this change is unlikely to cause significant problems and indeed has the security benefit of probably resulting in fewer false positives when comparing passwords. A few examples might suffice to indicate the nature of the problem: (1) U+017F LATIN SMALL LETTER LONG S is compatibility equivalent to U+0073 LATIN SMALL LETTER S (2) U+2163 ROMAN NUMERAL FOUR is compatibility equivalent to U+0049 LATIN CAPITAL LETTER I and U+0056 LATIN CAPITAL LETTER V (3) U+FB01 LATIN SMALL LIGATURE FI is compatibility equivalent to U+0066 LATIN SMALL LETTER F and U+0069 LATIN SMALL LETTER I. Under SASLprep, the use of NFKC also handled the mapping of fullwidth and halfwidth code points to their decomposition equivalents (see <xref target='I-D.ietf-precis-mappings'/>). Although it is expected that code points with compatibility equivalents are rare in existing passwords, some passwords that matched when SASLprep was used might no longer work when the rules in this specification are applied.</t>
<t>SASLprep mapped the "characters commonly mapped to nothing" from Appendix B.1 of <xref target='RFC3454'/>) to nothing, whereas the PRECIS FreeformClass entirely disallows such characters, which correspond to the code points from the "M" category defined under Section 6.13 of <xref target='FRAMEWORK'/> (with the exception of U+1806 MONGOLIAN TODO SOFT HYPHEN, which was commonly mapped to nothing in Unicode 3.2 but at the time of this writing is allowed by Unicode 6.1). In practice, this change will probably have no effect on comparison, but user-oriented software might reject such code points instead of ignoring them during password preparation.</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<section title="Password/Passphrase Strength" anchor="security-passwords">
<t>The ability to include a wide range of characters in passwords and passphrases can increase the potential for creating a strong password with high entropy. However, in practice, the ability to include such characters ought to be weighed against the possible need to reproduce them on various devices using various input methods.</t>
</section>
<section title="Reuse of PRECIS" anchor="security-precis">
<t>The security considerations described in <xref target="FRAMEWORK"/> apply to the "IdentifierClass" and "FreeformClass" base string classes used in this document for simple user names and passwords, respectively.</t>
</section>
<section title="Reuse of Unicode" anchor="security-unicode">
<t>The security considerations described in <xref target='UTR39'/> apply to the use of Unicode characters in user names and passwords.</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="Use of IdentifierClass" anchor="iana-nameclass">
<t>The IANA shall add an entry to the PRECIS Usage Registry for reuse of the PRECIS IdentifierClass in SASL, as follows:</t>
<t>
<list style='hanging'>
<t hangText='Applicability:'>Usernames in SASL and Kerberos.</t>
<t hangText='Base Class:'>IdentifierClass.</t>
<t hangText='Subclass:'>No.</t>
<t hangText='Replaces:'>The SASLprep profile of Stringprep.</t>
<t hangText='Normalization:'>NFC.</t>
<t hangText='Casemapping:'>Map uppercase and titlecase characters to lowercase.</t>
<t hangText='Additional Mappings:'>None.</t>
<t hangText='Directionality:'>The "Bidi Rule" defined in RFC 5893 applies.</t>
<t hangText='Specification:'>RFC XXXX. [Note to RFC Editor: please change XXXX to the number issued for this specification.]</t>
</list>
</t>
</section>
<section title="Use of FreeformClass" anchor="iana-freeclass">
<t>The IANA shall add an entry to the PRECIS Usage Registry for reuse of the PRECIS FreeformClass in SASL, as follows:</t>
<t>
<list style='hanging'>
<t hangText='Applicability:'>Passwords in SASL and Kerberos.</t>
<t hangText='Base Class:'>FreeformClass</t>
<t hangText='Subclass:'>No.</t>
<t hangText='Replaces:'>The SASLprep profile of Stringprep.</t>
<t hangText='Normalization:'>NFC.</t>
<t hangText='Casemapping:'>None.</t>
<t hangText='Additional Mappings:'>Map non-ASCII space characters to ASCII space.</t>
<t hangText='Directionality:'>None.</t>
<t hangText='Specification:'>RFC XXXX. [Note to RFC Editor: please change XXXX to the number issued for this specification.]</t>
</list>
</t>
</section>
</section>
<section title="Open Issues">
<t>We need to compare the output obtained when applying the new rules with Unicode 3.2 and Unicode 6.1 data to the output obtained when applying the SASLprep rules with Unicode 3.2 data, then make sure that the PRECIS Working Group and KITTEN Working Group are comfortable with any changes to the Unicode characters that are allowed and disallowed. (See also the migration issues described under <xref target='migration'/>.)</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='FRAMEWORK'>
<front>
<title>Precis Framework: Handling Internationalized Strings in Protocols</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization>Cisco</organization>
</author>
<author initials='M' surname='Blanchet' fullname='Marc Blanchet'>
<organization>Viagenie</organization>
</author>
<date month='March' day='26' year='2013' />
<abstract><t>Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to handle various classes of strings in a way that depends on the properties of Unicode code points and that is agile with respect to versions of Unicode; as a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). A specification that reuses this framework can either directly use the base string classes or subclass the base string classes as needed. This framework takes an approach similar to the revised internationalized domain names in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in RFC 4690, albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-precis-framework-07' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-precis-framework-07.txt' />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date month='March' year='1997' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC3629'>
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'>
<organization /></author>
<date year='2003' month='November' />
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t></abstract></front>
<seriesInfo name='STD' value='63' />
<seriesInfo name='RFC' value='3629' />
<format type='TXT' octets='33856' target='http://www.rfc-editor.org/rfc/rfc3629.txt' />
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
<format type='TXT' octets='26359' target='http://www.rfc-editor.org/rfc/rfc5234.txt' />
</reference>
<reference anchor="UNICODE" target="http://www.unicode.org/versions/Unicode6.1.0/">
<front>
<title>The Unicode Standard, Version 6.1</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="2012" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor='I-D.ietf-precis-mappings'>
<front>
<title>Mapping characters for PRECIS classes</title>
<author initials='Y' surname='YONEYA' fullname='Yoshiro YONEYA'>
<organization />
</author>
<author initials='T' surname='NEMOTO' fullname='Takahiro NEMOTO'>
<organization />
</author>
<date month='December' day='26' year='2012' />
<abstract><t>Preparation and comparison of internationalized strings ("PRECIS") Framework [I-D.ietf-precis-framework] is defining several classes of strings for preparation and comparison. In the document, case mapping is defined because many of protocols handle case sensitive or case insensitive string comparison and therefore preparation of string is mandatory. As described in IDNA mapping [RFC5895] and PRECIS problem statement [I-D.ietf-precis-problem-statement], mappings in internationalized strings are not limited to case, but also width, delimiters and/or other specials are taken into consideration. This document considers mappings other than case mapping in PRECIS context.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-precis-mappings-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-precis-mappings-01.txt' />
</reference>
<reference anchor="RFC3454">
<front>
<title>Preparation of Internationalized Strings ("stringprep")</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='M.' surname='Blanchet' fullname='M. Blanchet'>
<organization /></author>
<date month='December' year='2002' /></front>
<seriesInfo name='RFC' value='3454' />
<format type='TXT' octets='138684' target='ftp://ftp.isi.edu/in-notes/rfc3454.txt' />
</reference>
<reference anchor='RFC4013'>
<front>
<title>SASLprep: Stringprep Profile for User Names and Passwords</title>
<author initials='K.' surname='Zeilenga' fullname='K. Zeilenga'>
<organization /></author>
<date year='2005' month='February' />
<abstract>
<t>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. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4013' />
<format type='TXT' octets='13051' target='http://www.rfc-editor.org/rfc/rfc4013.txt' />
</reference>
<reference anchor="RFC4422">
<front>
<title>Simple Authentication and Security Layer (SASL)</title>
<author initials='A.' surname='Melnikov' fullname='A. Melnikov' role="editor">
<organization /></author>
<author initials='K.' surname='Zeilenga' fullname='K. Zeilenga' role="editor">
<organization /></author>
<date year='2006' month='June' />
<abstract>
<t><p>The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.</p><p> This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.</p><p> This document obsoletes RFC 2222. [STANDARDS TRACK]</p></t></abstract></front>
<seriesInfo name='RFC' value='4422' />
<format type='TXT' octets='73206' target='ftp://ftp.isi.edu/in-notes/rfc4422.txt' />
</reference>
<reference anchor='RFC4616'>
<front>
<title>The PLAIN Simple Authentication and Security Layer (SASL) Mechanism</title>
<author initials='K.' surname='Zeilenga' fullname='K. Zeilenga'>
<organization /></author>
<date year='2006' month='August' />
<abstract>
<t>This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4616' />
<format type='TXT' octets='20270' target='http://www.rfc-editor.org/rfc/rfc4616.txt' />
</reference>
<reference anchor='RFC5802'>
<front>
<title>Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms</title>
<author initials='C.' surname='Newman' fullname='C. Newman'>
<organization /></author>
<author initials='A.' surname='Menon-Sen' fullname='A. Menon-Sen'>
<organization /></author>
<author initials='A.' surname='Melnikov' fullname='A. Melnikov'>
<organization /></author>
<author initials='N.' surname='Williams' fullname='N. Williams'>
<organization /></author>
<date year='2010' month='July' />
<abstract>
<t>The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.</t><t> This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5802' />
<format type='TXT' octets='59049' target='http://www.rfc-editor.org/rfc/rfc5802.txt' />
</reference>
<reference anchor='RFC5890'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization />
</author>
<date year='2010' month='August' />
<abstract>
<t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5890' />
<format type='TXT' octets='54245' target='http://www.rfc-editor.org/rfc/rfc5890.txt' />
</reference>
<reference anchor='RFC5891'>
<front>
<title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization />
</author>
<date year='2010' month='August' />
<abstract>
<t>This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5891' />
<format type='TXT' octets='38105' target='http://www.rfc-editor.org/rfc/rfc5891.txt' />
</reference>
<reference anchor='RFC5893'>
<front>
<title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization />
</author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization />
</author>
<date year='2010' month='August' />
<abstract>
<t>The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5893' />
<format type='TXT' octets='38870' target='http://www.rfc-editor.org/rfc/rfc5893.txt' />
</reference>
<reference anchor='RFC5894'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5894' />
<format type='TXT' octets='115174' target='http://www.rfc-editor.org/rfc/rfc5894.txt' />
</reference>
<reference anchor='RFC6365'>
<front>
<title>Terminology Used in Internationalization in the IETF</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2011' month='September' />
<abstract>
<t>This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice.</t></abstract></front>
<seriesInfo name='BCP' value='166' />
<seriesInfo name='RFC' value='6365' />
<format type='TXT' octets='103155' target='http://www.rfc-editor.org/rfc/rfc6365.txt' />
</reference>
<reference anchor="UTR39" target='http://unicode.org/reports/tr39/'>
<front>
<title>Unicode Technical Report #39: Unicode Security Mechanisms</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date month="August" year="2010" />
</front>
</reference>
</references>
<section title="Differences from RFC 4013" anchor="diffs">
<t>The following substantive modifications were made from RFC 4013.</t>
<t>
<list style='symbols'>
<t>A single SASLprep algorithm was replaced by two separate algorithms: one for simple user names and another for passwords.</t>
<t>The new preparation algorithms use PRECIS instead of a stringprep profile. The new algorithms work independenctly of Unicode versions.</t>
<t>As recommended in the PRECIS framwork, changed the Unicode normalization form from NFKC to NFC.</t>
<t>Some Unicode code points that were mapped to nothing in RFC 4013 are simply disallowed by PRECIS.</t>
</list>
</t>
</section>
<section title="Acknowledgements" anchor="acks">
<t>Thanks to Yoshiro YONEYA and Takahiro NEMOTO for implementation feedback. Thanks also to Marc Blanchet, Joe Hildebrand, Alan DeKok, Simon Josefsson, Jonathan Lennox, Matt Miller, Chris Newman, Pete Resnick, Andrew Sullivan, and Nico Williams for their input.</t>
<t>This document borrows some text from RFC 4013 and RFC 6120.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:36:06 |