draft-ietf-precis-7613bis-09.txt   draft-ietf-precis-7613bis-10.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: January 17, 2018 July 16, 2017 Expires: January 25, 2018 July 24, 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-09 draft-ietf-precis-7613bis-10
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 January 17, 2018. This Internet-Draft will expire on January 25, 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 3, line 40 skipping to change at page 3, line 40
[I-D.ietf-precis-7564bis]. [I-D.ietf-precis-7564bis].
Profiles of the PRECIS framework enable software to handle Unicode Profiles of the PRECIS framework enable software to handle Unicode
code points outside the ASCII range in an automated way, so that such code points outside the ASCII range in an automated way, so that such
code points 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 code points. 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 code point SUPERSCRIPT ONE (U+00B9) as equivalent to DIGIT Unicode code point SUPERSCRIPT ONE (U+00B9) as equivalent to DIGIT
ONE (U+0031), because that would result in false positives during ONE (U+0031), because that would result in false accepts 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
desirable to support a wider range of characters so as to maximize desirable to support a wider range of characters so as to maximize
entropy for purposes of authentication.) entropy for purposes of authentication.)
skipping to change at page 6, line 36 skipping to change at page 6, line 36
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.
Case mapping is a matter for the application protocol, protocol Case mapping is a matter for the application protocol, protocol
implementation, or end deployment. In general, this document implementation, or end deployment. In general, this document
suggests that it is preferable to apply the UsernameCaseMapped suggests that it is preferable to apply the UsernameCaseMapped
profile and therefore perform case mapping, because not doing so can profile and therefore perform case mapping, because not doing so can
lead to false positives during authentication and authorization (as lead to false accepts during authentication and authorization (as
described in [RFC6943]) and can result in confusion among end users, described in [RFC6943]) and can result in confusion among end users,
given the prevalence of case mapping in many existing protocols and given the prevalence of case mapping in many existing protocols and
applications. However, there can be good reasons to apply the applications. However, there can be good reasons to apply the
UsernameCasePreserved profile and thus not perform case mapping, such UsernameCasePreserved profile and thus not perform case mapping, such
as backward compatibility with deployed infrastructure. as backward compatibility with deployed infrastructure.
In particular: In particular:
o SASL mechanisms that follow the recommendations in this document o SASL mechanisms that follow the recommendations in this document
MUST specify whether and when case mapping is to be applied to MUST specify whether and when case mapping is to be applied to
skipping to change at page 15, line 26 skipping to change at page 15, line 26
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). As was the case in RFC 4013, the inclusion exception of U+0020). As was the case in RFC 4013, the inclusion
of only ASCII space prevents confusion with various non-ASCII of only ASCII space prevents confusion with various non-ASCII
space code points, many of which are difficult to reproduce space code points, many of which are difficult to reproduce
across different input methods. across different input methods.
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 code points to their lowercase uppercase and titlecase code points to their lowercase
equivalents would lead to false positives and thus to reduced equivalents would lead to false accepts and thus to reduced
security). security).
4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be 4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
applied to all strings. 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 and inapplicable to passwords, because they can reduce the
repertoire of characters that are allowed in a string and repertoire of characters that are allowed in a string and
therefore reduce the amount of entropy that is possible in a therefore reduce the amount of entropy that is possible in a
skipping to change at page 17, line 41 skipping to change at page 17, line 41
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 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 accepts. 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, an idempotent procedure for all code points. Therefore, an
implementation SHOULD apply the rules repeatedly until the output implementation SHOULD apply the rules repeatedly until the output
string is stable; if the output string does not stabilize within a string is stable; if the output string does not stabilize within a
reasonable number of iterations, the implementation SHOULD terminate reasonable number of iterations, the implementation SHOULD terminate
application of the rules and reject the input string as invalid. application of the rules and reject the input string as invalid.
6. Migration 6. Migration
skipping to change at page 19, line 46 skipping to change at page 19, line 46
specification might not involve any scrubbing of data (because specification might not involve any scrubbing of data (because
passwords might not be stored in the clear anyway); however, service passwords might not be stored in the clear anyway); however, service
providers need to be aware of possible issues that might arise during providers need to be aware of possible issues that might arise during
migration. In particular: migration. In particular:
o SASLprep specified the use of Unicode Normalization Form KC o SASLprep specified the use of Unicode Normalization Form KC
(NFKC), whereas the OpaqueString profile employs Unicode (NFKC), whereas the OpaqueString profile employs Unicode
Normalization Form C (NFC). Because NFKC is more aggressive about Normalization Form C (NFC). Because NFKC is more aggressive about
finding matches than NFC, in practice this change is unlikely to finding matches than NFC, in practice this change is unlikely to
cause significant problems and indeed has the security benefit of cause significant problems and indeed has the security benefit of
probably resulting in fewer false positives when comparing probably resulting in fewer false accepts when comparing
passwords. A few examples might suffice to indicate the nature of passwords. A few examples might suffice to indicate the nature of
the problem: the problem:
1. LATIN SMALL LETTER LONG S (U+017F) is compatibility equivalent 1. LATIN SMALL LETTER LONG S (U+017F) is compatibility equivalent
to LATIN SMALL LETTER S (U+0073). to LATIN SMALL LETTER S (U+0073).
2. ROMAN NUMERAL FOUR (U+2163) is compatibility equivalent to 2. ROMAN NUMERAL FOUR (U+2163) is compatibility equivalent to
LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V
(U+0056). (U+0056).
skipping to change at page 23, line 9 skipping to change at page 23, line 9
comparison defined in Section 4.2.3. Instead, because the system comparison defined in Section 4.2.3. Instead, because the system
performs cryptographic calculations to verify the password, it will performs cryptographic calculations to verify the password, it will
prepare the password as defined in Section 4.2.1 and enforce the prepare the password as defined in Section 4.2.1 and enforce the
rules as defined in Section 4.2.2 before performing the relevant rules as defined in Section 4.2.2 before performing the relevant
calculations. calculations.
8.3. Identifier Comparison 8.3. Identifier Comparison
The process of comparing identifiers (such as SASL simple user names, The process of comparing identifiers (such as SASL simple user names,
authentication identifiers, and authorization identifiers) can lead authentication identifiers, and authorization identifiers) can lead
to either false negatives or false positives, both of which have to either false rejects or false accepts, both of which have security
security implications. A more detailed discussion can be found in implications. A more detailed discussion can be found in [RFC6943].
[RFC6943].
8.4. Reuse of PRECIS 8.4. Reuse of PRECIS
The security considerations described in [I-D.ietf-precis-7564bis] The security considerations described in [I-D.ietf-precis-7564bis]
apply to the IdentifierClass and FreeformClass base string classes apply to the IdentifierClass and FreeformClass base string classes
used in this document for usernames and passwords, respectively. used in this document for usernames and passwords, respectively.
8.5. Reuse of Unicode 8.5. 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
skipping to change at page 26, line 39 skipping to change at page 26, line 39
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.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Filament Filament
P.O. Box 787 18335 E 103rd Ave, Suite 203
Parker, CO 80134 Commerce City, CO 80022
USA USA
Phone: +1 720 256 6756 Phone: +1 720 256 6756
Email: peter@filament.com Email: peter@filament.com
URI: https://filament.com/ URI: https://filament.com/
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
 End of changes. 10 change blocks. 
13 lines changed or deleted 12 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/