Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
obsoleted by
- rfc-8265 — Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
obsoletes
- rfc-4013 — SASLprep: Stringprep Profile for User Names and Passwords
Extracted elements (27)
NFC normalization replaces NFKC (used in SASLprep/RFC 4013) because the PRECIS IdentifierClass entirely disallows characters with compatibility equivalents, making NFKC's compatibility decomposition unnecessary. For passwords, the switch from NFKC to NFC has the security benefit of fewer false positives during comparison.
No Bidi Rule is applied to passwords because it would reduce the range of allowed characters and thus entropy. Passwords are typically not displayed and are rarely meant to be interoperable across different layout systems in the way that usernames or domain names are.
PRECIS profiles use an 'inclusion model' (disallowing all characters except those explicitly allowed), in contrast to stringprep's 'exclusion model' (allowing all characters except those explicitly disallowed). This mirrors the approach originally used for internationalized domain names in RFC 5891.
Two separate username profiles (UsernameCaseMapped and UsernameCasePreserved) are defined to accommodate different application needs. Case mapping is generally preferable to avoid false positives in authentication, but case preservation may be needed for backward compatibility with deployed infrastructure.
Deployments migrating from SASLprep (RFC 4013) to this specification for usernames may need to scrub existing data: NFKC-normalized usernames using characters with compatibility equivalents (e.g., ROMAN NUMERAL FOUR U+2163) may conflict with or differ from PRECIS-processed equivalents, potentially requiring operator resolution of conflicting accounts.
For password migration from RFC 4013, service providers should be aware that passwords containing characters with compatibility equivalents (e.g., LATIN SMALL LETTER LONG S U+017F) that matched under NFKC may no longer match under NFC; however, passwords are often not stored in the clear, so migration may not require data scrubbing.
This document does not modify handling of internationalized strings in existing application protocols that use SASLprep; such protocols must be explicitly updated to use PRECIS (e.g., via a separate document). Non-coordinated updates to protocol implementations are discouraged due to interoperability and security impact.
A password MUST NOT be zero bytes in length. This rule is enforced after any normalization and mapping of code points, to prevent accidental omission of a password when internationalized characters are accepted.
A username MUST NOT be zero bytes in length. This rule is enforced after any normalization and mapping of code points, to prevent a non-empty sequence of internationalized characters from canonicalizing to an empty string.
Comparison of two strings under any username profile MUST prepare and enforce each string, then consider them equivalent only if they are an exact octet-for-octet match (bit-string identity).
In both username profiles, applications MUST apply the Bidi Rule defined in RFC 5893 to strings that contain right-to-left characters (all six conditions of the Bidi Rule must be satisfied).
In both username profiles, Unicode Normalization Form C (NFC) MUST be applied to all characters as the normalization rule.
In the OpaqueString profile, any instance of non-ASCII space (Unicode general category 'Zs', except U+0020) MUST be mapped to ASCII space (U+0020).
In the OpaqueString profile, fullwidth and halfwidth characters MUST NOT be mapped to their decomposition mappings, in contrast to username profiles. This preserves the distinctiveness of such characters in passwords.
In the UsernameCaseMapped profile, an entity preparing a string MUST first map fullwidth and halfwidth characters to their decomposition mappings and MUST ensure the string consists only of PRECIS IdentifierClass code points, then MUST encode as UTF-8.
In the UsernameCaseMapped profile, uppercase and titlecase characters MUST be mapped to their lowercase equivalents using Unicode Default Case Folding.
SASL mechanisms that follow this document's recommendations MUST specify whether and when case mapping is applied to authentication identifiers, and SHOULD delay any case mapping to the last possible moment (e.g., at username lookup or comparison on the server).
A password is a UTF-8 encoded string of Unicode code points conformant to the OpaqueString profile of the PRECIS FreeformClass. Passwords allow a wider range of characters than usernames (including symbols and non-ASCII letters) to maximize entropy for authentication.
A username is a UTF-8 encoded string of Unicode code points structured as an ordered sequence of 'userparts', where each userpart consists only of code points allowed by the PRECIS IdentifierClass. A username may be a single userpart or a space-separated sequence of userparts (ABNF: username = userpart *(1*SP userpart)).
The OpaqueString profile applies to the PRECIS FreeformClass and enforces five rules: (1) fullwidth/halfwidth characters MUST NOT be mapped to decompositions, (2) non-ASCII space MUST be mapped to ASCII space U+0020, (3) no case mapping, (4) NFC normalization, (5) no directionality rule.
The UsernameCaseMapped profile applies to the PRECIS IdentifierClass and enforces five rules in order: (1) width mapping, (2) no additional mapping, (3) case folding to lowercase via Unicode Default Case Folding, (4) NFC normalization, (5) Bidi Rule from RFC 5893.
The UsernameCasePreserved profile applies to the PRECIS IdentifierClass and differs from UsernameCaseMapped solely in the case-mapping rule: uppercase and titlecase characters MUST NOT be mapped to their lowercase equivalents. All other rules (width mapping, NFC, Bidi Rule) are identical.
IANA has added three entries to the 'PRECIS Profiles' registry: UsernameCaseMapped (IdentifierClass, with case folding), UsernameCasePreserved (IdentifierClass, no case folding), and OpaqueString (FreeformClass, for passwords). All three replace the SASLprep profile of stringprep.
IANA has marked the SASLprep profile of stringprep (registered under RFC 4013) as 'Not Current' in the 'Stringprep Profiles' registry, citing RFC 7613 as an additional reference.
Comparing internationalized identifiers can lead to false negatives or false positives, both with security implications. For example, treating SUPERSCRIPT ONE (U+00B9) as equivalent to DIGIT ONE (U+0031) would allow attackers to spoof accounts. PRECIS profiles protect against this by disallowing characters with compatibility equivalents in usernames.
Supporting a wide range of Unicode characters in passwords can increase entropy and password strength, but this must be weighed against the practical ability to reproduce those characters on various devices and input methods.
The security considerations of RFC 7564 (PRECIS framework) apply to the IdentifierClass and FreeformClass base string classes, and the security considerations of Unicode Technical Standard #39 (Unicode Security Mechanisms) apply to use of Unicode characters in usernames and passwords.