draft-ietf-precis-7613bis-00.txt   draft-ietf-precis-7613bis-01.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: October 7, 2016 April 5, 2016 Expires: November 6, 2016 May 5, 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-00 draft-ietf-precis-7613bis-01
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 October 7, 2016. This Internet-Draft will expire on November 6, 2016.
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 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 6 3.2. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 6
3.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 6 3.2.2. Preparation . . . . . . . . . . . . . . . . . . . . . 6
3.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 7 3.2.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 7
3.2.4. Comparison . . . . . . . . . . . . . . . . . . . . . 7
3.3. UsernameCasePreserved Profile . . . . . . . . . . . . . . 7 3.3. UsernameCasePreserved Profile . . . . . . . . . . . . . . 7
3.3.1. Preparation . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Preparation . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Comparison . . . . . . . . . . . . . . . . . . . . . 8 3.3.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 8
3.4. Case Mapping vs. Case Preservation . . . . . . . . . . . 8 3.3.4. Comparison . . . . . . . . . . . . . . . . . . . . . 8
3.5. Application-Layer Constructs . . . . . . . . . . . . . . 9 3.4. Case Mapping vs. Case Preservation . . . . . . . . . . . 9
3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Application-Layer Constructs . . . . . . . . . . . . . . 10
4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 11 4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 12 4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 12 4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 13
4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 14
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 14
5. Use in Application Protocols . . . . . . . . . . . . . . . . 14 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Use in Application Protocols . . . . . . . . . . . . . . . . 15
6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 18 7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 19
7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 19 7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 19
7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 19 7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 20
8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 20 8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 21
8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 20 8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 21
8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 20 8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Differences from RFC 7613 . . . . . . . . . . . . . 24
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 (SASL) mechanism [RFC4616] and the HTTP Basic scheme [RFC7617]) or
[HTTP-BASIC-AUTH]) or indirectly when provided as the input to a indirectly when provided as the input to a cryptographic algorithm
cryptographic algorithm such as a hash function (as in the Salted such as a hash function (as in the Salted Challenge Response
Challenge Response Authentication Mechanism (SCRAM) SASL mechanism Authentication Mechanism (SCRAM) SASL mechanism [RFC5802] and the
[RFC5802] and the HTTP Digest scheme [HTTP-DIGEST-AUTH]). 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 characters from the
Unicode character set [Unicode], with special attention to characters Unicode character set [Unicode], with special attention to characters
outside the ASCII range [RFC20]. The rules for handling such strings outside the ASCII range [RFC20]. The rules for handling such strings
are specified through profiles of the string classes defined in the are specified through profiles of the string classes defined in the
preparation, enforcement, and comparison of internationalized strings preparation, enforcement, and comparison of internationalized strings
skipping to change at page 4, line 9 skipping to change at page 4, line 11
The methods defined here might be applicable wherever usernames or The methods defined here might be applicable wherever usernames or
passwords are used. However, the methods are not intended for use in passwords are used. However, the methods are not intended for use in
preparing strings that are not usernames (e.g., Lightweight Directory preparing strings that are not usernames (e.g., Lightweight Directory
Access Protocol (LDAP) distinguished names), nor in cases where Access Protocol (LDAP) distinguished names), nor in cases where
identifiers or secrets are not strings (e.g., keys and certificates) identifiers or secrets are not strings (e.g., keys and certificates)
or require specialized handling. or require specialized handling.
This document obsoletes RFC 4013 (the SASLprep profile of stringprep This document obsoletes RFC 4013 (the SASLprep profile of stringprep
[RFC3454]) but can be used by technologies other than SASL [RFC4422], [RFC3454]) but can be used by technologies other than SASL [RFC4422],
such as HTTP authentication as specified in [HTTP-BASIC-AUTH] and such as HTTP authentication as specified in [RFC7617] and [RFC7616].
[HTTP-DIGEST-AUTH].
This document does not modify the handling of internationalized This document does not modify the handling of internationalized
strings in usernames and passwords as prescribed by existing strings in usernames and passwords as prescribed by existing
application protocols that use SASLprep. If the community that uses application protocols that use SASLprep. If the community that uses
such an application protocol wishes to modernize its handling of such an application protocol wishes to modernize its handling of
internationalized strings to use PRECIS instead of stringprep, it internationalized strings to use PRECIS instead of stringprep, it
needs to explicitly update the existing application protocol needs to explicitly update the existing application protocol
definition (one example is [XMPP-ADDR], which is intended to obsolete definition (one example is [RFC7622]. Non-coordinated updates to
[RFC6122]). Non-coordinated updates to protocol implementations are protocol implementations are discouraged because they can have a
discouraged because they can have a negative impact on negative impact on interoperability and security.
interoperability and security.
2. Terminology 2. Terminology
Many important terms used in this document are defined in [RFC5890], Many important terms used in this document are defined in [RFC5890],
[RFC6365], [RFC7564], and [Unicode]. The term "non-ASCII space" [RFC6365], [RFC7564], and [Unicode]. The term "non-ASCII space"
refers to any Unicode code point having a Unicode general category of refers to any Unicode code point having a Unicode general category of
"Zs", with the exception of U+0020 (here called "ASCII space"). "Zs", with the exception of U+0020 (here called "ASCII space").
As used here, the term "password" is not literally limited to a word; 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 i.e., a password could be a passphrase consisting of more than one
word, perhaps separated by spaces, punctuation, or other non- word, perhaps separated by spaces, punctuation, or other non-
alphanumeric characters. alphanumeric characters.
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 [HTTP-BASIC-AUTH] and [HTTP-DIGEST-AUTH]), whether or specified in [RFC7617] and [RFC7616]), whether or not they use SASL.
not they use SASL. Note well that the exact form of a username in Note well that the exact form of a username in any particular SASL
any particular SASL mechanism or application technology is a matter mechanism or application technology is a matter for implementation
for implementation and deployment, and that a username does not and deployment, and that a username does not necessarily map to any
necessarily map to any particular application identifier (such as the particular application identifier (such as the localpart of an email
localpart of an email address). 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 6, line 11 skipping to change at page 6, line 11
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
The definition of the UsernameCaseMapped profile of the 3.2.1. Rules
IdentifierClass is provided in the following sections, including
detailed information about preparation, enforcement, and comparison
(for details on the distinction between these actions, refer to
[RFC7564]).
3.2.1. Preparation The following rules apply within the UsernameCaseMapped profile of
the PRECIS IdentifierClass.
An entity that prepares a string according to this profile MUST first 1. Width-Mapping Rule: Map fullwidth and halfwidth characters to
map fullwidth and halfwidth characters to their decomposition their decomposition mappings (see Unicode Standard Annex #11
mappings (see Unicode Standard Annex #11 [UAX11]). This is necessary [UAX11]).
because the PRECIS "HasCompat" category specified in Section 9.17 of
[RFC7564] would otherwise forbid fullwidth and halfwidth characters.
After applying this width-mapping rule, the entity then MUST ensure
that the string consists only of Unicode code points that conform to
the PRECIS IdentifierClass defined in Section 4.2 of [RFC7564]. In
addition, the entity then MUST encode the string as UTF-8 [RFC3629].
3.2.2. Enforcement 2. Additional Mapping Rule: There is no additional mapping rule.
An entity that performs enforcement according to this profile MUST 3. Case-Mapping Rule: Map uppercase and titlecase characters to
prepare a string as described in Section 3.2.1 and MUST also apply their lowercase equivalents, preferably using Unicode Default
the rules specified below for the UsernameCaseMapped profile (these Case Folding as defined in the Unicode Standard [Unicode] (at the
rules MUST be applied in the order shown): time of this writing, the algorithm is specified in Chapter 3 of
[Unicode7.0], but the chapter number might change in a future
version of the Unicode Standard); see further discussion in
Section 3.4.
1. Width-Mapping Rule: Applied as part of preparation (see above). 4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to
all characters.
2. Additional Mapping Rule: There is no additional mapping rule. 5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893]
to strings that contain right-to-left characters (i.e., each of
the six conditions of the Bidi Rule must be satisfied); for
strings that do not contain right-to-left characters, there is no
special processing for directionality.
3. Case-Mapping Rule: Uppercase and titlecase characters MUST be 3.2.2. Preparation
mapped to their lowercase equivalents, preferably using Unicode
Default Case Folding as defined in the Unicode Standard [Unicode]
(at the time of this writing, the algorithm is specified in
Chapter 3 of [Unicode7.0], but the chapter number might change in
a future version of the Unicode Standard); see further discussion
in Section 3.4.
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be An entity that prepares a string for subsequent enforcement according
applied to all characters. to this profile MUST proceed as follows (applying the steps in the
order shown).
5. Directionality Rule: Applications MUST apply the "Bidi Rule" 1. Apply the width-mapping rule specified in Section 3.2.1. It is
defined in [RFC5893] to strings that contain right-to-left necessary to apply the rule at this point because otherwise the
characters (i.e., each of the six conditions of the Bidi Rule PRECIS "HasCompat" category specified in Section 9.17 of
must be satisfied). [RFC7564] would forbid fullwidth and halfwidth characters.
3.2.3. Comparison 2. Ensure that the string consists only of Unicode code points that
conform to the PRECIS IdentifierClass defined in Section 4.2 of
[RFC7564].
3. Encode the string as UTF-8 [RFC3629].
3.2.3. Enforcement
An entity that performs enforcement according to this profile MUST
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:
1. Normalization Rule
2. Directionality Rule
3. Case-Mapping Rule
After all of the foregoing rules have been enforced, the entity MUST
ensure that the username is not zero bytes in length (this is done
after enforcing the rules to prevent applications from mistakenly
omitting a username entirely, because when internationalized
characters are accepted, a non-empty sequence of characters can
result in a zero-length username after canonicalization).
3.2.4. Comparison
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.1 and profile MUST prepare each string as specified in Section 3.2.2 and
then enforce the rules specified in Section 3.2.2. The two strings then enforce the rules specified in Section 3.2.3. The two strings
are to be considered equivalent if they are an exact octet-for-octet are to be considered equivalent if they are an exact octet-for-octet
match (sometimes called "bit-string identity"). match (sometimes called "bit-string identity").
3.3. UsernameCasePreserved Profile 3.3. UsernameCasePreserved Profile
The definition of the UsernameCasePreserved profile of the 3.3.1. Rules
IdentifierClass is provided in the following sections, including
detailed information about preparation, enforcement, and comparison
(for details on the distinction between these actions, refer to
[RFC7564]).
3.3.1. Preparation The following rules apply within the UsernameCasePreserved profile of
the PRECIS IdentifierClass.
An entity that prepares a string according to this profile MUST first 1. Width-Mapping Rule: Map fullwidth and halfwidth characters to
map fullwidth and halfwidth characters to their decomposition their decomposition mappings (see Unicode Standard Annex #11
mappings (see Unicode Standard Annex #11 [UAX11]). This is necessary [UAX11]).
because the PRECIS "HasCompat" category specified in Section 9.17 of
[RFC7564] would otherwise forbid fullwidth and halfwidth characters.
After applying this width-mapping rule, the entity then MUST ensure
that the string consists only of Unicode code points that conform to
the PRECIS IdentifierClass defined in Section 4.2 of [RFC7564]. In
addition, the entity then MUST encode the string as UTF-8 [RFC3629].
3.3.2. Enforcement 2. Additional Mapping Rule: There is no additional mapping rule.
An entity that performs enforcement according to this profile MUST 3. Case-Mapping Rule: There is no case-mapping rule.
prepare a string as described in Section 3.3.1 and MUST also apply
the rules specified below for the UsernameCasePreserved profile
(these rules MUST be applied in the order shown):
1. Width-Mapping Rule: Applied as part of preparation (see above). 4. Normalization Rule: Apply Unicode Normalization Form C (NFC) to
all characters.
2. Additional Mapping Rule: There is no additional mapping rule. 5. Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893]
to strings that contain right-to-left characters (i.e., each of
the six conditions of the Bidi Rule must be satisfied); for
strings that do not contain right-to-left characters, there is no
special processing for directionality.
3. Case-Mapping Rule: Uppercase and titlecase characters MUST NOT be 3.3.2. Preparation
mapped to their lowercase equivalents; see further discussion in
Section 3.4.
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be An entity that prepares a string for subsequent enforcement according
applied to all characters. to this profile MUST proceed as follows (applying the steps in the
order shown).
5. Directionality Rule: Applications MUST apply the "Bidi Rule" 1. Apply the width-mapping rule specified in Section 3.2.1. It is
defined in [RFC5893] to strings that contain right-to-left necessary to apply the rule at this point because otherwise the
characters (i.e., each of the six conditions of the Bidi Rule PRECIS "HasCompat" category specified in Section 9.17 of
must be satisfied). [RFC7564] would forbid fullwidth and halfwidth characters.
3.3.3. Comparison 2. Ensure that the string consists only of Unicode code points that
conform to the PRECIS IdentifierClass defined in Section 4.2 of
[RFC7564].
3. Encode the string as UTF-8 [RFC3629].
3.3.3. Enforcement
An entity that performs enforcement according to this profile MUST
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:
1. Normalization Rule
2. Directionality Rule
3. Case-Mapping Rule
After all of the foregoing rules have been enforced, the entity MUST
ensure that the username is not zero bytes in length (this is done
after enforcing the rules to prevent applications from mistakenly
omitting a username entirely, because when internationalized
characters are accepted, a non-empty sequence of characters can
result in a zero-length username after canonicalization).
3.3.4. Comparison
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.3.1 and profile MUST prepare each string as specified in Section 3.3.2 and
then enforce the rules specified in Section 3.3.2. The two strings then enforce the rules specified in Section 3.3.3. The two strings
are to be considered equivalent if they are an exact octet-for-octet are to be considered equivalent if they are an exact octet-for-octet
match (sometimes called "bit-string identity"). match (sometimes called "bit-string identity").
3.4. Case Mapping vs. Case Preservation 3.4. Case Mapping vs. Case Preservation
In order to accommodate the widest range of username constructs in In order to accommodate the widest range of username constructs in
applications, this document defines two username profiles: applications, this document defines two username profiles:
UsernameCaseMapped and UsernameCasePreserved. These two profiles UsernameCaseMapped and UsernameCasePreserved. These two profiles
differ only in the Case-Mapping Rule and are otherwise identical. differ only in the Case-Mapping Rule and are otherwise identical.
skipping to change at page 9, line 14 skipping to change at page 10, line 4
"SASL application protocols" SHOULD delay any case-mapping of "SASL application protocols" SHOULD delay any case-mapping of
authorization identifiers to the last possible moment, which authorization identifiers to the last possible moment, which
happens to necessarily be on the server side (this enables happens to necessarily be on the server side (this enables
decisions about case mapping to be a matter of deployment policy). decisions about case mapping to be a matter of deployment policy).
In keeping with [RFC4422], SASL application protocols are not to In keeping with [RFC4422], SASL application protocols are not to
apply this or any other profile to authentication identifiers, apply this or any other profile to authentication identifiers,
only to authorization identifiers. only to authorization identifiers.
o Application protocols that do not use SASL (such as HTTP o Application protocols that do not use SASL (such as HTTP
authentication with the HTTP Basic and Digest schemes as specified authentication with the HTTP Basic and Digest schemes as specified
in [HTTP-BASIC-AUTH] and [HTTP-DIGEST-AUTH]) but that directly in [RFC7617] and [RFC7616]) but that directly reuse this profile
reuse this profile MUST specify whether and when case mapping is MUST specify whether and when case mapping is to be applied to
to be applied to authentication identifiers or authorization authentication identifiers or authorization identifiers, or both.
identifiers, or both. Such "non-SASL application protocols" Such "non-SASL application protocols" SHOULD delay any case
SHOULD delay any case mapping to the last possible moment, such as mapping to the last possible moment, such as when doing a lookup
when doing a lookup by username, performing username comparisons, by username, performing username comparisons, or generating a
or generating a cryptographic salt from a username (if the last cryptographic salt from a username (if the last possible moment
possible moment happens on the server, then decisions about case happens on the server, then decisions about case mapping can be a
mapping can be a matter of deployment policy). matter of deployment policy).
If the specification for a SASL mechanism, SASL application protocol, If the specification for a SASL mechanism, SASL application protocol,
or non-SASL application protocol uses the UsernameCaseMapped profile, or non-SASL application protocol uses the UsernameCaseMapped profile,
it MUST clearly describe whether case mapping is to be applied at the it MUST clearly describe whether case mapping is to be applied at the
level of the protocol itself, implementations thereof, or service level of the protocol itself, implementations thereof, or service
deployments (each of these approaches can be legitimate, depending on deployments (each of these approaches can be legitimate, depending on
the application in question). the application in question).
3.5. Application-Layer Constructs 3.5. Application-Layer Constructs
skipping to change at page 21, line 38 skipping to change at page 22, line 38
<http://www.unicode.org/versions/Unicode7.0.0/>. <http://www.unicode.org/versions/Unicode7.0.0/>.
[Unicode] The Unicode Consortium, "The Unicode Standard", [Unicode] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>. <http://www.unicode.org/versions/latest/>.
9.2. Informative References 9.2. Informative References
[Err1812] RFC Errata, "Erratum ID 1812", RFC 4013, [Err1812] RFC Errata, "Erratum ID 1812", RFC 4013,
<http://www.rfc-editor.org>. <http://www.rfc-editor.org>.
[HTTP-BASIC-AUTH]
Reschke, J., "The 'Basic' HTTP Authentication Scheme",
Work in Progress, draft-ietf-httpauth-basicauth-update-07,
February 2015.
[HTTP-DIGEST-AUTH]
Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", Work in Progress, draft-
ietf-httpauth-digest-19, April 2015.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, [RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>. <http://www.rfc-editor.org/info/rfc20>.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, DOI Internationalized Strings ("stringprep")", RFC 3454, DOI
10.17487/RFC3454, December 2002, 10.17487/RFC3454, December 2002,
<http://www.rfc-editor.org/info/rfc3454>. <http://www.rfc-editor.org/info/rfc3454>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
skipping to change at page 22, line 34 skipping to change at page 23, line 25
Security Layer (SASL) Mechanism", RFC 4616, DOI 10.17487/ Security Layer (SASL) Mechanism", RFC 4616, DOI 10.17487/
RFC4616, August 2006, RFC4616, August 2006,
<http://www.rfc-editor.org/info/rfc4616>. <http://www.rfc-editor.org/info/rfc4616>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism "Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI
10.17487/RFC5802, July 2010, 10.17487/RFC5802, July 2010,
<http://www.rfc-editor.org/info/rfc5802>. <http://www.rfc-editor.org/info/rfc5802>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/
RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
for Internationalized Domain Names for Applications for Internationalized Domain Names for Applications
(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
<http://www.rfc-editor.org/info/rfc5893>. <http://www.rfc-editor.org/info/rfc5893>.
[RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
<http://www.rfc-editor.org/info/rfc5894>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6122] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", RFC 6122, DOI 10.17487/
RFC6122, March 2011,
<http://www.rfc-editor.org/info/rfc6122>.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for
Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
2013, <http://www.rfc-editor.org/info/rfc6943>. 2013, <http://www.rfc-editor.org/info/rfc6943>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI
10.17487/RFC7542, May 2015, 10.17487/RFC7542, May 2015,
<http://www.rfc-editor.org/info/rfc7542>. <http://www.rfc-editor.org/info/rfc7542>.
[UTS39] Unicode Technical Standard #39, "Unicode Security [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Mechanisms", edited by Mark Davis and Michel Suignard, Enforcement, and Comparison of Internationalized Strings
<http://unicode.org/reports/tr39/>. Representing Usernames and Passwords", RFC 7613, DOI
10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>.
[XMPP-ADDR] [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Saint-Andre, P., "Extensible Messaging and Presence Digest Access Authentication", RFC 7616, DOI 10.17487/
Protocol (XMPP): Address Format", Work in Progress, draft- RFC7616, September 2015,
ietf-xmpp-6122bis-24, June 2015. <http://www.rfc-editor.org/info/rfc7616>.
Appendix A. Differences from RFC 4013 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC
7617, DOI 10.17487/RFC7617, September 2015,
<http://www.rfc-editor.org/info/rfc7617>.
This document builds upon the PRECIS framework defined in [RFC7564], [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
which differs fundamentally from the stringprep technology [RFC3454] Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/
used in SASLprep [RFC4013]. The primary difference is that RFC7622, September 2015,
stringprep profiles allowed all characters except those characters <http://www.rfc-editor.org/info/rfc7622>.
that were explicitly disallowed, whereas PRECIS profiles disallow all
characters except those characters that are explicitly allowed (this
"inclusion model" was originally used for internationalized domain
names in [RFC5891]; see [RFC5894] for further discussion). It is
important to keep this distinction in mind when comparing the
technology defined in this document to SASLprep [RFC4013].
The following substantive modifications were made from RFC 4013. [UTS39] Unicode Technical Standard #39, "Unicode Security
Mechanisms", edited by Mark Davis and Michel Suignard,
<http://unicode.org/reports/tr39/>.
o A single SASLprep algorithm was replaced by three separate Appendix A. Differences from RFC 7613
algorithms: one for usernames with case mapping, one for usernames
with case preservation, and one for passwords.
o The new preparation algorithms use PRECIS instead of a stringprep The following modifications were made from [RFC7613].
profile. The new algorithms work independently of Unicode
versions.
o As recommended in the PRECIS framework, changed the Unicode o Modified the presentation (but not the content) of the rules.
normalization form from NFKC to NFC.
o Some Unicode code points that were mapped to nothing in RFC 4013 o Clarified several editorial matters.
are simply disallowed by PRECIS.
See [RFC7613] for a description of the differences from [RFC4013].
Appendix B. Acknowledgements Appendix B. Acknowledgements
This document borrows some text from [RFC4013] and [RFC6120]. This document borrows some text from [RFC4013] and [RFC6120].
The following individuals provided helpful feedback on this document: The following individuals provided helpful feedback on this document:
Marc Blanchet, Ben Campbell, Alan DeKok, Joe Hildebrand, Jeffrey Marc Blanchet, Ben Campbell, Alan DeKok, Joe Hildebrand, Jeffrey
Hutzelman, Simon Josefsson, Jonathan Lennox, James Manger, Matt Hutzelman, Simon Josefsson, Jonathan Lennox, James Manger, Matt
Miller, Chris Newman, Yutaka OIWA, Pete Resnick, Andrew Sullivan, Miller, Chris Newman, Yutaka OIWA, Pete Resnick, Andrew Sullivan,
Nico Williams, and Yoshiro YONEYA. Nico Williams in particular Nico Williams, and Yoshiro YONEYA. Nico Williams in particular
 End of changes. 48 change blocks. 
190 lines changed or deleted 197 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/