< draft-ietf-precis-7613bis-08.txt   draft-ietf-precis-7613bis-09.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: December 29, 2017 June 27, 2017 Expires: January 17, 2018 July 16, 2017
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-08 draft-ietf-precis-7613bis-09
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. This document obsoletes RFC 7613. passwords. This document obsoletes RFC 7613.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 December 29, 2017. This Internet-Draft will expire on January 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 22 skipping to change at page 2, line 22
3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Case Mapping vs. Case Preservation . . . . . . . . . . . 6 3.2. Case Mapping vs. Case Preservation . . . . . . . . . . . 6
3.3. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 7 3.3. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 7
3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Preparation . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Preparation . . . . . . . . . . . . . . . . . . . . . 8
3.3.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 8 3.3.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Comparison . . . . . . . . . . . . . . . . . . . . . 9 3.3.4. Comparison . . . . . . . . . . . . . . . . . . . . . 9
3.4. UsernameCasePreserved Profile . . . . . . . . . . . . . . 9 3.4. UsernameCasePreserved Profile . . . . . . . . . . . . . . 9
3.4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Preparation . . . . . . . . . . . . . . . . . . . . . 9 3.4.2. Preparation . . . . . . . . . . . . . . . . . . . . . 10
3.4.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 10 3.4.3. Enforcement . . . . . . . . . . . . . . . . . . . . . 10
3.4.4. Comparison . . . . . . . . . . . . . . . . . . . . . 10 3.4.4. Comparison . . . . . . . . . . . . . . . . . . . . . 10
3.5. Application-Layer Constructs . . . . . . . . . . . . . . 10 3.5. Application-Layer Constructs . . . . . . . . . . . . . . 11
3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 13 4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 14
4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 15
4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 16
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Use in Application Protocols . . . . . . . . . . . . . . . . 16 5. Use in Application Protocols . . . . . . . . . . . . . . . . 17
6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 19 7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 20
7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 20 7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 21
7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 20 7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 21
7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 21 7.4. Stringprep Profile . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 21 8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 22
8.2. Password/Passphrase Comparison . . . . . . . . . . . . . 21 8.2. Password/Passphrase Comparison . . . . . . . . . . . . . 22
8.3. Identifier Comparison . . . . . . . . . . . . . . . . . . 22 8.3. Identifier Comparison . . . . . . . . . . . . . . . . . . 23
8.4. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 22 8.4. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 23
8.5. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 22 8.5. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Changes from RFC 7613 . . . . . . . . . . . . . . . 25 Appendix A. Changes from RFC 7613 . . . . . . . . . . . . . . . 26
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 4, line 20 skipping to change at page 4, line 20
profile of stringprep [RFC3454]), the approach defined here can be profile of stringprep [RFC3454]), the approach defined here can be
used by technologies other than SASL [RFC4422], such as HTTP used by technologies other than SASL [RFC4422], such as HTTP
authentication as specified in [RFC7617] and [RFC7616]. authentication as specified in [RFC7617] and [RFC7616].
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 [RFC7622]. Non-coordinated updates to definition (one example is [RFC7622]). Non-coordinated updates to
protocol implementations are discouraged because they can have a protocol implementations are discouraged because they can have a
negative impact on interoperability and security. negative impact on interoperability and security.
2. Terminology 2. Terminology
A "username" or "user identifier" is a string of characters A "username" or "user identifier" is a string of characters
designating an account on a computing device or system, often but not designating an account on a computing device or system, often but not
necessarily for use by a person. Although some devices and system necessarily for use by a person. Although some devices and system
might allow a username to be part or all of a person's name, and a might allow a username to be part or all of a person's name, and a
person might want their account designator to be part or all of their person might want their account designator to be part or all of their
skipping to change at page 8, line 21 skipping to change at page 8, line 21
all strings. 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 code points (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 code points, there is strings that do not contain right-to-left code points, there is
no 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 an input string for subsequent enforcement
to this profile MUST proceed as follows (applying the steps in the according to this profile MUST proceed as follows (applying the steps
order shown). in the order shown).
1. Apply the width-mapping rule specified in Section 3.3.1. It is 1. Apply the width-mapping rule specified in Section 3.3.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
[I-D.ietf-precis-7564bis] would forbid fullwidth and halfwidth [I-D.ietf-precis-7564bis] would forbid fullwidth and halfwidth
code points. 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
are explicitly allowed by the PRECIS IdentifierClass defined in are explicitly allowed by the PRECIS IdentifierClass defined in
Section 4.2 of [I-D.ietf-precis-7564bis]. Section 4.2 of [I-D.ietf-precis-7564bis].
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 an input string as described in Section 3.3.2 and MUST also
the following rules specified in Section 3.3.1 in the order shown: apply the following rules specified in Section 3.3.1 in the order
shown:
1. Case-Mapping Rule 1. Case-Mapping Rule
2. Normalization Rule 2. Normalization Rule
3. Directionality Rule 3. Directionality Rule
After all of the foregoing rules have been enforced, the entity MUST 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 ensure that the username is not zero bytes in length (this is done
after enforcing the rules to prevent applications from mistakenly after enforcing the rules to prevent applications from mistakenly
omitting a username entirely, because when internationalized strings omitting a username entirely, because when internationalized strings
are accepted, a non-empty sequence of characters can result in a are accepted, a non-empty sequence of characters can result in a
zero-length username after canonicalization). zero-length username after canonicalization).
The result of the foregoing operations is an output string that
conforms to the UsernameCaseMapped profile. Until an implementation
produces such an output string, it MUST NOT treat the string as
conforming (in particular, it MUST NOT assume that an input string is
conforming before the enforcement operation has been completed).
3.3.4. Comparison 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.2 and profile MUST prepare each string as specified in Section 3.3.2 and
then MUST enforce the rules specified in Section 3.3.3. The two then MUST enforce the rules specified in Section 3.3.3. The two
strings are to be considered equivalent if and only if they are an strings are to be considered equivalent if and only if they are an
exact octet-for-octet match (sometimes called "bit-string identity"). exact octet-for-octet match (sometimes called "bit-string identity").
Until an implementation determines whether two strings are to be
considered equivalent, it MUST NOT treat them as equivalent (in
particular, it MUST NOT assume that an input string conforms to the
rules before the comparison operation has been completed).
3.4. UsernameCasePreserved Profile 3.4. UsernameCasePreserved Profile
3.4.1. Rules 3.4.1. Rules
The following rules are defined for use within the The following rules are defined for use within the
UsernameCasePreserved profile of the PRECIS IdentifierClass. UsernameCasePreserved profile of the PRECIS IdentifierClass.
1. Width-Mapping Rule: Map fullwidth and halfwidth code points 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]).
skipping to change at page 10, line 22 skipping to change at page 10, line 38
2. Directionality Rule 2. Directionality Rule
After all of the foregoing rules have been enforced, the entity MUST 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 ensure that the username is not zero bytes in length (this is done
after enforcing the rules to prevent applications from mistakenly after enforcing the rules to prevent applications from mistakenly
omitting a username entirely, because when internationalized strings omitting a username entirely, because when internationalized strings
are accepted, a non-empty sequence of characters can result in a are accepted, a non-empty sequence of characters can result in a
zero-length username after canonicalization). zero-length username after canonicalization).
The result of the foregoing operations is an output string that
conforms to the UsernameCasePreserved profile. Until an
implementation produces such an output string, it MUST NOT treat the
string as conforming (in particular, it MUST NOT assume that an input
string is conforming before the enforcement operation has been
completed).
3.4.4. Comparison 3.4.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.4.2 and profile MUST prepare each string as specified in Section 3.4.2 and
then MUST enforce the rules specified in Section 3.4.3. The two then MUST enforce the rules specified in Section 3.4.3. The two
strings are to be considered equivalent if and only if they are an strings are to be considered equivalent if and only if they are an
exact octet-for-octet match (sometimes called "bit-string identity"). exact octet-for-octet match (sometimes called "bit-string identity").
Until an implementation determines whether two strings are to be
considered equivalent, it MUST NOT treat them as equivalent (in
particular, it MUST NOT assume that an input string conforms to the
rules before the comparison operation has been completed).
3.5. Application-Layer Constructs 3.5. Application-Layer Constructs
Both the UsernameCaseMapped and UsernameCasePreserved profiles enable Both the UsernameCaseMapped and UsernameCasePreserved profiles enable
an application protocol, implementation, or deployment to create an application protocol, implementation, or deployment to create
application-layer constructs such as a username that is a space- application-layer constructs such as a username that is a space-
separated set of userparts like "Firstname Middlename Lastname". separated set of userparts like "Firstname Middlename Lastname".
Although such a construct is not a profile of the PRECIS Although such a construct is not a profile of the PRECIS
IdentifierClass (because U+0020 SPACE is not allowed in the IdentifierClass (because U+0020 SPACE is not allowed in the
IdentifierClass), it can be created at the application layer because IdentifierClass), it can be created at the application layer because
U+0020 SPACE can be used as a separator between instances of the U+0020 SPACE can be used as a separator between instances of the
skipping to change at page 13, line 8 skipping to change at page 14, line 8
password = 1*(freepoint) password = 1*(freepoint)
; ;
; a "freepoint" is a Unicode code point that ; a "freepoint" is a Unicode code point that
; can be contained in a string conforming to ; can be contained in a string conforming to
; the PRECIS FreeformClass ; the PRECIS 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 code points, 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 [RFC4013] (when corrected
[Err1812]). per [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
be restarted without human intervention). From the perspective of be restarted without human intervention). From the perspective of
this document (and RFC 4013 before it), these empty strings are this document (and RFC 4013 before it), these empty strings are
not passwords but are workarounds for the practical difficulty of not passwords but are workarounds for the practical difficulty of
skipping to change at page 14, line 48 skipping to change at page 15, line 48
that the same string will be displayed differently on a layout that the same string will be displayed differently on a layout
system set for right-to-left display and a layout system set for system set for right-to-left display and a layout system set for
left-to-right display; however, passwords are typically not left-to-right display; however, passwords are typically not
displayed at all and are rarely meant to be interoperable across displayed at all and are rarely meant to be interoperable across
different layout systems in the way that non-secret strings like different layout systems in the way that non-secret strings like
domain names and usernames are. Furthermore, it is perfectly domain names and usernames are. Furthermore, it is perfectly
acceptable for opaque strings other than passwords to be acceptable for opaque strings other than passwords to be
presented differently in different layout systems, as long as the presented differently in different layout systems, as long as the
presentation is consistent in any given layout system. presentation is consistent in any given layout system.
The result of the foregoing operations is an output string that
conforms to the OpaqueString profile. Until an implementation
produces such an output string, it MUST NOT treat the string as
conforming (in particular, it MUST NOT assume that an input string is
conforming before the enforcement operation has been completed).
4.2.3. Comparison 4.2.3. 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 4.2.1 and profile MUST prepare each string as specified in Section 4.2.1 and
then MUST enforce the rules specified in Section 4.2.2. The two then MUST enforce the rules specified in Section 4.2.2. The two
strings are to be considered equivalent if and only if they are an strings are to be considered equivalent if and only if they are an
exact octet-for-octet match (sometimes called "bit-string identity"). exact octet-for-octet match (sometimes called "bit-string identity").
Until an implementation determines whether two strings are to be
considered equivalent, it MUST NOT treat them as equivalent (in
particular, it MUST NOT assume that an input string conforms to the
rules before the comparison operation has been completed).
See Section 8.2 regarding comparison of passwords and passphrases. See Section 8.2 regarding comparison of passwords and passphrases.
4.3. Examples 4.3. Examples
The following examples illustrate a small number of passwords that The following examples illustrate a small number of passwords that
are consistent with the format defined above (note that the are consistent with the format defined above (note that the
characters "<" and ">" are used here to delineate the actual characters "<" and ">" are used here to delineate the actual
passwords and are not part of the password strings). passwords and are not part of the password strings).
+------------------------------------+------------------------------+ +------------------------------------+------------------------------+
skipping to change at page 16, line 44 skipping to change at page 17, line 44
restrictions on allowable code points 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].
Applying the rules for any given PRECIS profile is not necessarily an Applying the rules for any given PRECIS profile is not necessarily an
idempotent procedure for all code points. Therefore, implementations idempotent procedure for all code points. Therefore, an
might need to apply the rules more than once to an internationalized implementation SHOULD apply the rules repeatedly until the output
string. string is stable; if the output string does not stabilize within a
reasonable number of iterations, the implementation SHOULD terminate
application of the rules and reject the input string as invalid.
6. Migration 6. Migration
The rules defined in this specification differ slightly from those The rules defined in this specification differ slightly from those
defined by the SASLprep specification [RFC4013] (but not from defined by the SASLprep specification [RFC4013] (but not from
[RFC7613]). In order to smooth the process of migrating from [RFC7613]). In order to smooth the process of migrating from
SASLprep to the approach defined herein, the following sections SASLprep to the approach defined herein, the following sections
describe these differences, along with their implications for describe these differences, along with their implications for
migration, in more detail. migration, in more detail.
skipping to change at page 22, line 32 skipping to change at page 23, line 32
Unicode code points in usernames and passwords. Unicode code points in usernames and passwords.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-precis-7564bis] [I-D.ietf-precis-7564bis]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", Internationalized Strings in Application Protocols",
draft-ietf-precis-7564bis-08 (work in progress), June draft-ietf-precis-7564bis-09 (work in progress), July
2017. 2017.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
 End of changes. 18 change blocks. 
46 lines changed or deleted 83 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/