draft-ietf-precis-7613bis-03.txt   draft-ietf-precis-7613bis-04.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Filament Internet-Draft Filament
Obsoletes: 7613 (if approved) A. Melnikov Obsoletes: 7613 (if approved) A. Melnikov
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: March 9, 2017 September 5, 2016 Expires: June 3, 2017 November 30, 2016
Preparation, Enforcement, and Comparison of Internationalized Strings Preparation, Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords Representing Usernames and Passwords
draft-ietf-precis-7613bis-03 draft-ietf-precis-7613bis-04
Abstract Abstract
This document describes updated methods for handling Unicode strings This document describes updated methods for handling Unicode strings
representing usernames and passwords. The previous approach was representing usernames and passwords. The previous approach was
known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).
The methods specified in this document provide a more sustainable The methods specified in this document provide a more sustainable
approach to the handling of internationalized usernames and approach to the handling of internationalized usernames and
passwords. The preparation, enforcement, and comparison of passwords. The preparation, enforcement, and comparison of
internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 9, 2017. This Internet-Draft will expire on June 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
3.3.2. Preparation . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Preparation . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 8 3.3.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Comparison . . . . . . . . . . . . . . . . . . . . . 8 3.3.4. Comparison . . . . . . . . . . . . . . . . . . . . . 8
3.4. Case Mapping vs. Case Preservation . . . . . . . . . . . 8 3.4. Case Mapping vs. Case Preservation . . . . . . . . . . . 8
3.5. Application-Layer Constructs . . . . . . . . . . . . . . 10 3.5. Application-Layer Constructs . . . . . . . . . . . . . . 10
3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 13 4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 13
4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 14
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Use in Application Protocols . . . . . . . . . . . . . . . . 15 5. Use in Application Protocols . . . . . . . . . . . . . . . . 15
6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 18 7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 18
7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 19 7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 19
7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 20 7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 20
7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 20 7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 20 8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 20
8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 21 8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 21
8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 21 8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 21
8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 21 8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Differences from RFC 7613 . . . . . . . . . . . . . 24 Appendix A. Changes from RFC 7613 . . . . . . . . . . . . . . . 24
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Usernames and passwords are widely used for authentication and Usernames and passwords are widely used for authentication and
authorization on the Internet, either directly when provided in authorization on the Internet, either directly when provided in
plaintext (as in the PLAIN Simple Authentication and Security Layer plaintext (as in the PLAIN Simple Authentication and Security Layer
(SASL) mechanism [RFC4616] and the HTTP Basic scheme [RFC7617]) or (SASL) mechanism [RFC4616] and the HTTP Basic scheme [RFC7617]) or
indirectly when provided as the input to a cryptographic algorithm indirectly when provided as the input to a cryptographic algorithm
such as a hash function (as in the Salted Challenge Response such as a hash function (as in the Salted Challenge Response
Authentication Mechanism (SCRAM) SASL mechanism [RFC5802] and the Authentication Mechanism (SCRAM) SASL mechanism [RFC5802] and the
HTTP Digest scheme [RFC7616]). HTTP Digest scheme [RFC7616]).
To increase the likelihood that the input and comparison of usernames To increase the likelihood that the input and comparison of usernames
and passwords will work in ways that make sense for typical users and passwords will work in ways that make sense for typical users
throughout the world, this document defines rules for preparing, throughout the world, this document defines rules for preparing,
enforcing, and comparing internationalized strings that represent enforcing, and comparing internationalized strings that represent
usernames and passwords. Such strings consist of characters from the usernames and passwords. Such strings consist of code points from
Unicode character set [Unicode], with special attention to characters the Unicode character set [Unicode], with special attention to code
outside the ASCII range [RFC20]. The rules for handling such strings points outside the ASCII range [RFC20]. The rules for handling such
are specified through profiles of the string classes defined in the strings are specified through profiles of the string classes defined
preparation, enforcement, and comparison of internationalized strings in the preparation, enforcement, and comparison of internationalized
(PRECIS) framework specification [RFC7564]. strings (PRECIS) framework specification [RFC7564].
Profiles of the PRECIS framework enable software to handle Unicode Profiles of the PRECIS framework enable software to handle Unicode
characters outside the ASCII range in an automated way, so that such code points outside the ASCII range in an automated way, so that such
characters are treated carefully and consistently in application code points are treated carefully and consistently in application
protocols. In large measure, these profiles are designed to protect protocols. In large measure, these profiles are designed to protect
application developers from the potentially negative consequences of application developers from the potentially negative consequences of
supporting the full range of Unicode characters. For instance, in supporting the full range of Unicode code points. For instance, in
almost all application protocols it would be dangerous to treat the almost all application protocols it would be dangerous to treat the
Unicode character SUPERSCRIPT ONE (U+00B9) as equivalent to DIGIT ONE Unicode character SUPERSCRIPT ONE (U+00B9) as equivalent to DIGIT ONE
(U+0031), because that would result in false positives during (U+0031), because that would result in false positives during
comparison, authentication, and authorization (e.g., an attacker comparison, authentication, and authorization (e.g., an attacker
could easy spoof an account "user1@example.com"). could easy spoof an account "user1@example.com").
Whereas a naive use of Unicode would make such attacks trivially Whereas a naive use of Unicode would make such attacks trivially
easy, the PRECIS profile defined here for usernames generally easy, the PRECIS profile defined here for usernames generally
protects applications from inadvertently causing such problems. protects applications from inadvertently causing such problems.
(Similar considerations apply to passwords, although here it is (Similar considerations apply to passwords, although here it is
skipping to change at page 4, line 45 skipping to change at page 4, line 45
Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify
that the authentication identity used in the context of such that the authentication identity used in the context of such
mechanisms is a "simple user name" (see Section 2 of [RFC4422] as mechanisms is a "simple user name" (see Section 2 of [RFC4422] as
well as [RFC4013]). Various application technologies also assume well as [RFC4013]). Various application technologies also assume
that the identity of a user or account takes the form of a username that the identity of a user or account takes the form of a username
(e.g., authentication for the Hypertext Transfer Protocol as (e.g., authentication for the Hypertext Transfer Protocol as
specified in [RFC7617] and [RFC7616]), whether or not they use SASL. specified in [RFC7617] and [RFC7616]), whether or not they use SASL.
Note well that the exact form of a username in any particular SASL Note well that the exact form of a username in any particular SASL
mechanism or application technology is a matter for implementation mechanism or application technology is a matter for implementation
and deployment, and that a username does not necessarily map to any and deployment, and that a username does not necessarily map to any
particular application identifier (such as the localpart of an email particular application identifier.
address).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Usernames 3. Usernames
3.1. Definition 3.1. Definition
skipping to change at page 5, line 22 skipping to change at page 5, line 22
as UTF-8 [RFC3629]). A userpart is allowed to contain only code as UTF-8 [RFC3629]). A userpart is allowed to contain only code
points that are allowed by the PRECIS IdentifierClass defined in points that are allowed by the PRECIS IdentifierClass defined in
Section 4.2 of [RFC7564], and thus consists almost exclusively of Section 4.2 of [RFC7564], and thus consists almost exclusively of
letters and digits. A username can consist of a single userpart or a letters and digits. A username can consist of a single userpart or a
space-separated sequence of userparts. space-separated sequence of userparts.
The syntax for a username is defined as follows, using the Augmented The syntax for a username is defined as follows, using the Augmented
Backus-Naur Form (ABNF) [RFC5234]. Backus-Naur Form (ABNF) [RFC5234].
username = userpart *(1*SP userpart) username = userpart *(1*SP userpart)
userpart = 1*(idbyte) userpart = 1*(idpoint)
; ;
; an "idbyte" is a byte used to encode a ; an "idpoint" is a Unicode code point that
; Unicode code point that can be contained ; can be contained in a string conforming to
; in a string that conforms to the PRECIS ; the PRECIS IdentifierClass
; IdentifierClass
; ;
All code points and blocks not explicitly allowed in the PRECIS All code points and blocks not explicitly allowed in the PRECIS
IdentifierClass are disallowed; this includes private use characters, IdentifierClass are disallowed; this includes private use code
surrogate code points, and the other code points and blocks that were points, surrogate code points, and the other code points and blocks
defined as "Prohibited Output" in [RFC4013]. In addition, common that were defined as "Prohibited Output" in [RFC4013]. In addition,
constructions such as "user@example.com" (e.g., the Network Access common constructions such as "user@example.com" (e.g., the Network
Identifier from [RFC7542]) are allowed as usernames under this Access Identifier from [RFC7542]) are allowed as usernames under this
specification, as they were under [RFC4013]. specification, as they were under [RFC4013].
Implementation Note: The username construct defined in this Implementation Note: The username construct defined in this
document does not necessarily match what all deployed applications document does not necessarily match what all deployed applications
might refer to as a "username" or "userid" but instead provides a might refer to as a "username" or "userid" but instead provides a
relatively safe subset of Unicode characters that can be used in relatively safe subset of Unicode code points that can be used in
existing SASL mechanisms and in application protocols that use existing SASL mechanisms and in application protocols that use
SASL, and even in most application protocols that do not currently SASL, and even in most application protocols that do not currently
use SASL. use SASL.
A username MUST NOT be zero bytes in length. This rule is to be A username MUST NOT be zero bytes in length. This rule is to be
enforced after any normalization and mapping of code points. enforced after any normalization and mapping of code points.
In protocols that provide usernames as input to a cryptographic In protocols that provide usernames as input to a cryptographic
algorithm such as a hash function, the client will need to perform algorithm such as a hash function, the client will need to perform
enforcement of the rules for the UsernameCaseMapped or enforcement of the rules for the UsernameCaseMapped or
UsernameCasePreserved profile before applying the algorithm. UsernameCasePreserved profile before applying the algorithm.
This specification defines two profiles for usernames: one that This specification defines two profiles for usernames: one that
performs case mapping and one that performs case preservation (see performs case mapping and one that performs case preservation (see
further discussion under Section 3.4). further discussion under Section 3.4).
3.2. UsernameCaseMapped Profile 3.2. UsernameCaseMapped Profile
3.2.1. Rules 3.2.1. Rules
The following rules apply within the UsernameCaseMapped profile of The following rules are defined for use within the UsernameCaseMapped
the PRECIS IdentifierClass. profile of the PRECIS IdentifierClass.
1. Width-Mapping Rule: Map fullwidth and halfwidth characters to 1. Width-Mapping Rule: Map fullwidth and halfwidth code points to
their decomposition mappings (see Unicode Standard Annex #11 their decomposition mappings (see Unicode Standard Annex #11
[UAX11]). [UAX11]).
2. Additional Mapping Rule: There is no additional mapping rule. 2. Additional Mapping Rule: There is no additional mapping rule.
3. Case-Mapping Rule: Map uppercase and titlecase characters to 3. Case-Mapping Rule: Map uppercase and titlecase code points to
their lowercase equivalents, preferably using the Unicode their lowercase equivalents, preferably using the Unicode
toLower() operation as defined in the Unicode Standard [Unicode]; toLower() operation as defined in the Unicode Standard [Unicode];
see further discussion in Section 3.4. see further discussion in Section 3.4.
4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to 4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to
all characters. all strings.
5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893] 5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893]
to strings that contain right-to-left characters (i.e., each of to strings that contain right-to-left code points (i.e., each of
the six conditions of the Bidi Rule must be satisfied); for the six conditions of the Bidi Rule must be satisfied); for
strings that do not contain right-to-left characters, there is no strings that do not contain right-to-left code points, there is
special processing for directionality. no special processing for directionality.
3.2.2. Preparation 3.2.2. Preparation
An entity that prepares a string for subsequent enforcement according An entity that prepares a string for subsequent enforcement according
to this profile MUST proceed as follows (applying the steps in the to this profile MUST proceed as follows (applying the steps in the
order shown). order shown).
1. Apply the width-mapping rule specified in Section 3.2.1. It is 1. Apply the width-mapping rule specified in Section 3.2.1. It is
necessary to apply the rule at this point because otherwise the necessary to apply the rule at this point because otherwise the
PRECIS "HasCompat" category specified in Section 9.17 of PRECIS "HasCompat" category specified in Section 9.17 of
[RFC7564] would forbid fullwidth and halfwidth characters. [RFC7564] would forbid fullwidth and halfwidth code points.
2. Ensure that the string consists only of Unicode code points that 2. Ensure that the string consists only of Unicode code points that
conform to the PRECIS IdentifierClass defined in Section 4.2 of explicitly allowed by the PRECIS IdentifierClass defined in
[RFC7564]. Section 4.2 of [RFC7564].
3.2.3. Enforcement 3.2.3. Enforcement
An entity that performs enforcement according to this profile MUST An entity that performs enforcement according to this profile MUST
prepare a string as described in Section 3.2.2 and MUST also apply prepare a string as described in Section 3.2.2 and MUST also apply
the following rules specified in Section 3.2.1 in the order shown: the following rules specified in Section 3.2.1 in the order shown:
1. Case-Mapping Rule 1. Case-Mapping Rule
2. Normalization Rule 2. Normalization Rule
skipping to change at page 7, line 36 skipping to change at page 7, line 36
An entity that performs comparison of two strings according to this An entity that performs comparison of two strings according to this
profile MUST prepare each string as specified in Section 3.2.2 and profile MUST prepare each string as specified in Section 3.2.2 and
then MUST enforce the rules specified in Section 3.2.3. The two then MUST enforce the rules specified in Section 3.2.3. The two
strings are to be considered equivalent if they are an exact octet- strings are to be considered equivalent if they are an exact octet-
for-octet match (sometimes called "bit-string identity"). for-octet match (sometimes called "bit-string identity").
3.3. UsernameCasePreserved Profile 3.3. UsernameCasePreserved Profile
3.3.1. Rules 3.3.1. Rules
The following rules apply within the UsernameCasePreserved profile of The following rules are defined for use within the
the PRECIS IdentifierClass. UsernameCasePreserved profile of the PRECIS IdentifierClass.
1. Width-Mapping Rule: Map fullwidth and halfwidth characters to 1. Width-Mapping Rule: Map fullwidth and halfwidth code points to
their decomposition mappings (see Unicode Standard Annex #11 their decomposition mappings (see Unicode Standard Annex #11
[UAX11]). [UAX11]).
2. Additional Mapping Rule: There is no additional mapping rule. 2. Additional Mapping Rule: There is no additional mapping rule.
3. Case-Mapping Rule: There is no case-mapping rule. 3. Case-Mapping Rule: There is no case-mapping rule.
4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to 4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to
all characters. all strings.
5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893] 5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893]
to strings that contain right-to-left characters (i.e., each of to strings that contain right-to-left code points (i.e., each of
the six conditions of the Bidi Rule must be satisfied); for the six conditions of the Bidi Rule must be satisfied); for
strings that do not contain right-to-left characters, there is no strings that do not contain right-to-left code points, there is
special processing for directionality. no special processing for directionality.
3.3.2. Preparation 3.3.2. Preparation
An entity that prepares a string for subsequent enforcement according An entity that prepares a string for subsequent enforcement according
to this profile MUST proceed as follows (applying the steps in the to this profile MUST proceed as follows (applying the steps in the
order shown). order shown).
1. Apply the width-mapping rule specified in Section 3.2.1. It is 1. Apply the width-mapping rule specified in Section 3.2.1. It is
necessary to apply the rule at this point because otherwise the necessary to apply the rule at this point because otherwise the
PRECIS "HasCompat" category specified in Section 9.17 of PRECIS "HasCompat" category specified in Section 9.17 of
[RFC7564] would forbid fullwidth and halfwidth characters. [RFC7564] would forbid fullwidth and halfwidth code points.
2. Ensure that the string consists only of Unicode code points that 2. Ensure that the string consists only of Unicode code points that
conform to the PRECIS IdentifierClass defined in Section 4.2 of are explicitly allowed by the PRECIS IdentifierClass defined in
[RFC7564]. Section 4.2 of [RFC7564].
3.3.3. Enforcement 3.3.3. Enforcement
An entity that performs enforcement according to this profile MUST An entity that performs enforcement according to this profile MUST
prepare a string as described in Section 3.3.2 and MUST also apply prepare a string as described in Section 3.3.2 and MUST also apply
the following rules specified in Section 3.3.1 in the order shown: the following rules specified in Section 3.3.1 in the order shown:
1. Normalization Rule 1. Normalization Rule
2. Directionality Rule 2. Directionality Rule
skipping to change at page 12, line 27 skipping to change at page 12, line 27
| | | (U+265A) | | | | (U+265A) |
+--------------------------+---------------------------------+ +--------------------------+---------------------------------+
Table 2: A Sample of Strings That Violate the Userpart Rule Table 2: A Sample of Strings That Violate the Userpart Rule
Here again, several points are worth noting. Regarding example 8: Here again, several points are worth noting. Regarding example 8:
although this is not a valid userpart, it is a valid username because although this is not a valid userpart, it is a valid username because
it is a space-separated sequence of userparts. Regarding example 10: it is a space-separated sequence of userparts. Regarding example 10:
the Unicode character ROMAN NUMERAL FOUR (U+2163) has a compatibility the Unicode character ROMAN NUMERAL FOUR (U+2163) has a compatibility
equivalent of the string formed of LATIN CAPITAL LETTER I (U+0049) equivalent of the string formed of LATIN CAPITAL LETTER I (U+0049)
and LATIN CAPITAL LETTER V (U+0056), but characters with and LATIN CAPITAL LETTER V (U+0056), but code points with
compatibility equivalents are not allowed in the PRECIS compatibility equivalents are not allowed in the PRECIS
IdentifierClass. Regarding example 11: symbol characters such as IdentifierClass. Regarding example 11: symbol characters such as
BLACK CHESS KING (U+265A) are not allowed in the PRECIS BLACK CHESS KING (U+265A) are not allowed in the PRECIS
IdentifierClass. IdentifierClass.
4. Passwords 4. Passwords
4.1. Definition 4.1. Definition
This document specifies that a password is a string of Unicode code This document specifies that a password is a string of Unicode code
points [Unicode] that is conformant to the OpaqueString profile points [Unicode] that is conformant to the OpaqueString profile
(specified below) of the PRECIS FreeformClass defined in Section 4.3 (specified below) of the PRECIS FreeformClass defined in Section 4.3
of [RFC7564], and that is expressed in a standard Unicode Encoding of [RFC7564], and that is expressed in a standard Unicode Encoding
Form (such as UTF-8 [RFC3629]). Form (such as UTF-8 [RFC3629]).
The syntax for a password is defined as follows, using the Augmented The syntax for a password is defined as follows, using the Augmented
Backus-Naur Form (ABNF) [RFC5234]. Backus-Naur Form (ABNF) [RFC5234].
password = 1*(freebyte) password = 1*(freepoint)
; ;
; a "freebyte" is a byte used to encode a ; a "freepoint" is a Unicode code point that
; Unicode code point that can be contained ; can be contained in a string conforming to
; in a string that conforms to the PRECIS ; the PRECIS FreeformClass
; FreeformClass
; ;
All code points and blocks not explicitly allowed in the PRECIS All code points and blocks not explicitly allowed in the PRECIS
FreeformClass are disallowed; this includes private use characters, FreeformClass are disallowed; this includes private use code points,
surrogate code points, and the other code points and blocks defined surrogate code points, and the other code points and blocks defined
as "Prohibited Output" in Section 2.3 of RFC 4013 (when corrected per as "Prohibited Output" in Section 2.3 of RFC 4013 (when corrected per
[Err1812]). [Err1812]).
A password MUST NOT be zero bytes in length. This rule is to be A password MUST NOT be zero bytes in length. This rule is to be
enforced after any normalization and mapping of code points. enforced after any normalization and mapping of code points.
Note: Some existing systems allow an empty string in places where Note: Some existing systems allow an empty string in places where
a password would be expected (e.g., command-line tools that might a password would be expected (e.g., command-line tools that might
be called from an automated script, or servers that might need to be called from an automated script, or servers that might need to
skipping to change at page 13, line 45 skipping to change at page 13, line 45
4.2. OpaqueString Profile 4.2. OpaqueString Profile
The definition of the OpaqueString profile is provided in the The definition of the OpaqueString profile is provided in the
following sections, including detailed information about preparation, following sections, including detailed information about preparation,
enforcement, and comparison (for details on the distinction between enforcement, and comparison (for details on the distinction between
these actions, refer to [RFC7564]). these actions, refer to [RFC7564]).
4.2.1. Preparation 4.2.1. Preparation
An entity that prepares a string according to this profile MUST An entity that prepares a string according to this profile MUST
ensure that the string consists only of Unicode code points that ensure that the string consists only of Unicode code points that are
conform to the FreeformClass base string class defined in [RFC7564]. explicitly allowed by the FreeformClass base string class defined in
[RFC7564].
4.2.2. Enforcement 4.2.2. Enforcement
An entity that performs enforcement according to this profile MUST An entity that performs enforcement according to this profile MUST
prepare a string as described in Section 4.2.1 and MUST also apply prepare a string as described in Section 4.2.1 and MUST also apply
the rules specified below for the OpaqueString profile (these rules the rules specified below for the OpaqueString profile (these rules
MUST be applied in the order shown): MUST be applied in the order shown):
1. Width-Mapping Rule: Fullwidth and halfwidth characters MUST NOT 1. Width-Mapping Rule: Fullwidth and halfwidth code points MUST NOT
be mapped to their decomposition mappings (see Unicode Standard be mapped to their decomposition mappings (see Unicode Standard
Annex #11 [UAX11]). Annex #11 [UAX11]).
2. Additional Mapping Rule: Any instances of non-ASCII space MUST be 2. Additional Mapping Rule: Any instances of non-ASCII space MUST be
mapped to ASCII space (U+0020); a non-ASCII space is any Unicode mapped to ASCII space (U+0020); a non-ASCII space is any Unicode
code point having a Unicode general category of "Zs" (with the code point having a Unicode general category of "Zs" (with the
exception of U+0020). exception of U+0020).
3. Case-Mapping Rule: There is no case mapping rule (because mapping 3. Case-Mapping Rule: There is no case mapping rule (because mapping
uppercase and titlecase characters to their lowercase equivalents uppercase and titlecase code points to their lowercase
would lead to false positives and thus to reduced security). equivalents would lead to false positives and thus to reduced
security).
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be 4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
applied to all characters. applied to all strings.
5. Directionality Rule: There is no directionality rule. The "Bidi 5. Directionality Rule: There is no directionality rule. The "Bidi
Rule" (defined in [RFC5893]) and similar rules are unnecessary Rule" (defined in [RFC5893]) and similar rules are unnecessary
and inapplicable to passwords, because they can reduce the range and inapplicable to passwords, because they can reduce the range
of characters that are allowed in a string and therefore reduce of characters that are allowed in a string and therefore reduce
the amount of entropy that is possible in a password. Such rules the amount of entropy that is possible in a password. Such rules
are intended to minimize the possibility that the same string are intended to minimize the possibility that the same string
will be displayed differently on a layout system set for right- will be displayed differently on a layout system set for right-
to-left display and a layout system set for left-to-right to-left display and a layout system set for left-to-right
display; however, passwords are typically not displayed at all display; however, passwords are typically not displayed at all
skipping to change at page 16, line 10 skipping to change at page 16, line 13
FreeformClass. It is the responsibility of an application protocol FreeformClass. It is the responsibility of an application protocol
to specify the protocol slots in which such strings can appear, the to specify the protocol slots in which such strings can appear, the
entities that are expected to enforce the rules governing such entities that are expected to enforce the rules governing such
strings, and at what points during protocol processing or interface strings, and at what points during protocol processing or interface
handling the rules need to be enforced. See Section 6 of [RFC7564] handling the rules need to be enforced. See Section 6 of [RFC7564]
for guidelines on using PRECIS profiles in applications. for guidelines on using PRECIS profiles in applications.
Above and beyond the PRECIS-based rules specified here, application Above and beyond the PRECIS-based rules specified here, application
protocols can also define application-specific rules governing such protocols can also define application-specific rules governing such
strings (rules regarding minimum or maximum length, further strings (rules regarding minimum or maximum length, further
restrictions on allowable characters or character ranges, safeguards restrictions on allowable code points or character ranges, safeguards
to mitigate the effects of visually similar characters, etc.), to mitigate the effects of visually similar characters, etc.),
application-layer constructs (see Section 3.5), and related matters. application-layer constructs (see Section 3.5), and related matters.
Some PRECIS profile definitions encourage entities that enforce the Some PRECIS profile definitions encourage entities that enforce the
rules to be liberal in what they accept. However, for usernames and rules to be liberal in what they accept. However, for usernames and
passwords such a policy can be problematic, because it can lead to passwords such a policy can be problematic, because it can lead to
false positives. An in-depth discussion can be found in [RFC6943]. false positives. An in-depth discussion can be found in [RFC6943].
6. Migration 6. Migration
skipping to change at page 17, line 18 skipping to change at page 17, line 18
Under SASLprep, the use of NFKC also handled the mapping of Under SASLprep, the use of NFKC also handled the mapping of
fullwidth and halfwidth code points to their decomposition fullwidth and halfwidth code points to their decomposition
mappings. mappings.
For migration purposes, operators might want to search their For migration purposes, operators might want to search their
database of usernames for names containing Unicode code points database of usernames for names containing Unicode code points
with compatibility equivalents and, where there is no conflict, with compatibility equivalents and, where there is no conflict,
map those code points to their equivalents. Naturally, it is map those code points to their equivalents. Naturally, it is
possible that during this process the operator will discover possible that during this process the operator will discover
conflicting usernames (e.g., HENRYIV with the last two characters conflicting usernames (e.g., HENRYIV with the last two code points
being LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V being LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V
(U+0056) vs. "HENRYIV" with the last character being ROMAN NUMERAL (U+0056) vs. "HENRYIV" with the last character being ROMAN NUMERAL
FOUR (U+2163), which is compatibility equivalent to U+0049 and FOUR (U+2163), which is compatibility equivalent to U+0049 and
U+0056); in these cases, the operator will need to determine how U+0056); in these cases, the operator will need to determine how
to proceed -- for instance, by disabling the account whose name to proceed -- for instance, by disabling the account whose name
contains a Unicode code point with a compatibility equivalent. contains a Unicode code point with a compatibility equivalent.
Such cases are probably rare, but it is important for operators to Such cases are probably rare, but it is important for operators to
be aware of them. be aware of them.
o SASLprep mapped the "characters commonly mapped to nothing" from o SASLprep mapped the "characters commonly mapped to nothing" from
Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS
IdentifierClass entirely disallows most of these characters, which IdentifierClass entirely disallows most of these code points,
correspond to the code points from the PRECIS "M" category defined which correspond to the code points from the PRECIS "M" category
under Section 9.13 of [RFC7564]. For migration purposes, the defined under Section 9.13 of [RFC7564]. For migration purposes,
operator might want to remove from usernames any code points the operator might want to remove from usernames any code points
contained in the PRECIS "M" category (e.g., SOFT HYPHEN (U+00AD)). contained in the PRECIS "M" category (e.g., SOFT HYPHEN (U+00AD)).
Because these code points would have been "mapped to nothing" in Because these code points would have been "mapped to nothing" in
stringprep, in practice a user would not notice the difference if, stringprep, in practice a user would not notice the difference if,
upon migration to PRECIS, the code points are removed. upon migration to PRECIS, the code points are removed.
o SASLprep allowed uppercase and titlecase characters, whereas the o SASLprep allowed uppercase and titlecase code points, whereas the
UsernameCaseMapped profile maps uppercase and titlecase characters UsernameCaseMapped profile maps uppercase and titlecase code
to their lowercase equivalents (by contrast, the points to their lowercase equivalents (by contrast, the
UsernameCasePreserved profile matches SASLprep in this regard). UsernameCasePreserved profile matches SASLprep in this regard).
For migration purposes, the operator can use either the For migration purposes, the operator can use either the
UsernameCaseMapped profile (thus losing the case information) or UsernameCaseMapped profile (thus losing the case information) or
the UsernameCasePreserved profile (thus ignoring case difference the UsernameCasePreserved profile (thus ignoring case difference
when comparing usernames). when comparing usernames).
6.2. Passwords 6.2. Passwords
Depending on local service policy, migration from RFC 4013 to this Depending on local service policy, migration from RFC 4013 to this
specification might not involve any scrubbing of data (because specification might not involve any scrubbing of data (because
skipping to change at page 18, line 36 skipping to change at page 18, line 36
Under SASLprep, the use of NFKC also handled the mapping of Under SASLprep, the use of NFKC also handled the mapping of
fullwidth and halfwidth code points to their decomposition fullwidth and halfwidth code points to their decomposition
mappings. Although it is expected that code points with mappings. Although it is expected that code points with
compatibility equivalents are rare in existing passwords, some compatibility equivalents are rare in existing passwords, some
passwords that matched when SASLprep was used might no longer work passwords that matched when SASLprep was used might no longer work
when the rules in this specification are applied. when the rules in this specification are applied.
o SASLprep mapped the "characters commonly mapped to nothing" from o SASLprep mapped the "characters commonly mapped to nothing" from
Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS
FreeformClass entirely disallows such characters, which correspond FreeformClass entirely disallows such code points, which
to the code points from the PRECIS "M" category defined under correspond to the code points from the PRECIS "M" category defined
Section 9.13 of [RFC7564]. In practice, this change will probably under Section 9.13 of [RFC7564]. In practice, this change will
have no effect on comparison, but user-oriented software might probably have no effect on comparison, but user-oriented software
reject such code points instead of ignoring them during password might reject such code points instead of ignoring them during
preparation. password preparation.
7. IANA Considerations 7. IANA Considerations
IANA has made the updates described below. IANA has made the updates described below.
7.1. UsernameCaseMapped Profile 7.1. UsernameCaseMapped Profile
IANA has added the following entry to the "PRECIS Profiles" registry. IANA has added the following entry to the "PRECIS Profiles" registry.
Name: UsernameCaseMapped. Name: UsernameCaseMapped.
Base Class: IdentifierClass. Base Class: IdentifierClass.
Applicability: Usernames in security and application protocols. Applicability: Usernames in security and application protocols.
Replaces: The SASLprep profile of stringprep. Replaces: The SASLprep profile of stringprep.
Width-Mapping Rule: Map fullwidth and halfwidth characters to their Width-Mapping Rule: Map fullwidth and halfwidth code points to their
decomposition mappings. decomposition mappings.
Additional Mapping Rule: None. Additional Mapping Rule: None.
Case-Mapping Rule: Map uppercase and titlecase characters to Case-Mapping Rule: Map uppercase and titlecase code points to
lowercase. lowercase.
Normalization Rule: NFC. Normalization Rule: NFC.
Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies. Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
Enforcement: To be defined by security or application protocols that Enforcement: To be defined by security or application protocols that
use this profile. use this profile.
Specification: RFC 7613 (this document), Section 3.2. Specification: RFC 7613 (this document), Section 3.2.
skipping to change at page 19, line 40 skipping to change at page 19, line 40
IANA has added the following entry to the "PRECIS Profiles" registry. IANA has added the following entry to the "PRECIS Profiles" registry.
Name: UsernameCasePreserved. Name: UsernameCasePreserved.
Base Class: IdentifierClass. Base Class: IdentifierClass.
Applicability: Usernames in security and application protocols. Applicability: Usernames in security and application protocols.
Replaces: The SASLprep profile of stringprep. Replaces: The SASLprep profile of stringprep.
Width-Mapping Rule: Map fullwidth and halfwidth characters to their Width-Mapping Rule: Map fullwidth and halfwidth code points to their
decomposition mappings. decomposition mappings.
Additional Mapping Rule: None. Additional Mapping Rule: None.
Case-Mapping Rule: None. Case-Mapping Rule: None.
Normalization Rule: NFC. Normalization Rule: NFC.
Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies. Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
skipping to change at page 20, line 22 skipping to change at page 20, line 22
Base Class: FreeformClass. Base Class: FreeformClass.
Applicability: Passwords and other opaque strings in security and Applicability: Passwords and other opaque strings in security and
application protocols. application protocols.
Replaces: The SASLprep profile of stringprep. Replaces: The SASLprep profile of stringprep.
Width-Mapping Rule: None. Width-Mapping Rule: None.
Additional Mapping Rule: Map non-ASCII space characters to ASCII Additional Mapping Rule: Map non-ASCII space code points to ASCII
space. space.
Case-Mapping Rule: None. Case-Mapping Rule: None.
Normalization Rule: NFC. Normalization Rule: NFC.
Directionality Rule: None. Directionality Rule: None.
Enforcement: To be defined by security or application protocols that Enforcement: To be defined by security or application protocols that
use this profile. use this profile.
skipping to change at page 21, line 24 skipping to change at page 21, line 24
8.3. Reuse of PRECIS 8.3. Reuse of PRECIS
The security considerations described in [RFC7564] apply to the The security considerations described in [RFC7564] apply to the
IdentifierClass and FreeformClass base string classes used in this IdentifierClass and FreeformClass base string classes used in this
document for usernames and passwords, respectively. document for usernames and passwords, respectively.
8.4. Reuse of Unicode 8.4. Reuse of Unicode
The security considerations described in [UTS39] apply to the use of The security considerations described in [UTS39] apply to the use of
Unicode characters in usernames and passwords. Unicode code points in usernames and passwords.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
skipping to change at page 24, line 5 skipping to change at page 24, line 5
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/ Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/
RFC7622, September 2015, RFC7622, September 2015,
<http://www.rfc-editor.org/info/rfc7622>. <http://www.rfc-editor.org/info/rfc7622>.
[UTS39] Unicode Technical Standard #39, "Unicode Security [UTS39] Unicode Technical Standard #39, "Unicode Security
Mechanisms", edited by Mark Davis and Michel Suignard, Mechanisms", edited by Mark Davis and Michel Suignard,
<http://unicode.org/reports/tr39/>. <http://unicode.org/reports/tr39/>.
Appendix A. Differences from RFC 7613 Appendix A. Changes from RFC 7613
The following modifications were made from [RFC7613]. The following changes were made from [RFC7613].
o Corrected the order of operations for the UsernameCaseMapped o Corrected the order of operations for the UsernameCaseMapped
profile to ensure consistency with RFC 7564. profile to ensure consistency with RFC 7564.
o In accordance with working group discussions and updates to o In accordance with working group discussions and updates to
[RFC7564], removed the use of the Unicode CaseFold() operation in [RFC7564], removed the use of the Unicode CaseFold() operation in
favor of the Unicode toLower() operation. favor of the Unicode toLower() operation.
o Modified the presentation (but not the content) of the rules. o Modified the presentation (but not the content) of the rules.
o Removed UTF-8 as a mandatory encoding, because that is a matter
for the application.
o Clarified several editorial matters. o Clarified several editorial matters.
o Updated references.
See [RFC7613] for a description of the differences from [RFC4013]. See [RFC7613] for a description of the differences from [RFC4013].
Appendix B. Acknowledgements Appendix B. Acknowledgements
Thanks to Christian Schudt and Sam Whited for their bug reports and Thanks to Christian Schudt and Sam Whited for their bug reports and
feedback. feedback.
See [RFC7613] for acknowledgements related to the specification that See [RFC7613] for acknowledgements related to the specification that
this document supersedes. this document supersedes.
 End of changes. 51 change blocks. 
84 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/