Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
obsoletes
- rfc-7613 — Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
Extracted elements (25)
Passwords use NFC rather than NFKC normalization (as SASLprep used) because the PRECIS FreeformClass does not disallow compatibility equivalents, and using NFC results in fewer false accepts during comparison, which is a security benefit.
The OpaqueString profile for passwords omits the Bidi Rule because directionality rules reduce the character repertoire and thus reduce password entropy. Passwords are typically not displayed and are not meant to be interoperable across different layout systems the way usernames are.
Two username profiles (UsernameCaseMapped and UsernameCasePreserved) are defined to accommodate both case-insensitive and case-sensitive deployments. Case mapping is generally preferred to avoid false accepts during authentication, but case preservation may be needed for backward compatibility with deployed infrastructure.
Width mapping for usernames must be applied before the PRECIS IdentifierClass check because the HasCompat category would otherwise forbid fullwidth and halfwidth code points, even though they should be permitted after mapping to their decomposition equivalents.
Migration from SASLprep to this specification may require scrubbing existing username data due to differences in normalization (NFKC vs NFC) and handling of 'characters commonly mapped to nothing'. Operators should search for usernames with Unicode compatibility equivalents and resolve conflicts before migrating.
This document does not modify handling of internationalized strings in existing application protocols that use SASLprep. If a protocol community wishes to migrate to PRECIS, it must explicitly update the protocol definition; non-coordinated updates are discouraged because they can harm interoperability and security.
A password MUST NOT be zero bytes in length, enforced after normalization and mapping. This is not a recommendation about password strength but prevents applications from mistakenly omitting a password after canonicalization of internationalized strings.
A username MUST NOT be zero bytes in length. This rule is enforced after any normalization and mapping of code points, to prevent applications from mistakenly omitting a username entirely when internationalized strings are accepted.
An entity preparing a string under the UsernameCaseMapped profile MUST apply the width mapping rule first, then ensure only IdentifierClass code points are present. The width mapping must occur before the PRECIS HasCompat category check, which would otherwise forbid fullwidth and halfwidth code points.
An implementation SHOULD apply the PRECIS profile rules repeatedly until the output string is stable. If the output does not stabilize after three additional applications beyond the first, the implementation SHOULD terminate and reject the input string as invalid.
Comparison under UsernameCaseMapped MUST prepare and enforce rules on each string; two strings are equivalent if and only if they are an exact octet-for-octet match. An implementation MUST NOT treat two strings as equivalent before the comparison operation is completed.
Enforcement under UsernameCaseMapped MUST prepare the string and then apply Case Mapping, Normalization (NFC), and Directionality (Bidi Rule) in that order. The implementation MUST NOT treat a string as conforming until the enforcement operation has been completed.
In OpaqueString enforcement, fullwidth and halfwidth code points MUST NOT be mapped to their decomposition mappings, and any non-ASCII space MUST be mapped to SPACE (U+0020). NFC normalization MUST be applied; there is no case mapping or directionality rule.
SASL mechanisms that follow this document's recommendations MUST specify whether and when case mapping is applied to authentication identifiers. Implementations SHOULD delay case mapping to the last possible moment (e.g., username lookup or comparison) to retain information for as long as possible.
A password is a string of Unicode code points conformant to the OpaqueString profile of the PRECIS FreeformClass, expressed in a standard Unicode Encoding Form such as UTF-8. Unlike usernames, passwords may include spaces, symbols, and a wider range of characters.
A username is a string of Unicode code points structured as an ordered sequence of 'userparts', where each userpart contains only code points allowed by the PRECIS IdentifierClass. A username can be a single userpart or a space-separated sequence of userparts, expressed in a standard Unicode Encoding Form such as UTF-8.
The OpaqueString profile for passwords uses the PRECIS FreeformClass with: no Width Mapping, Additional Mapping of non-ASCII space to SPACE (U+0020), no Case Mapping, NFC Normalization, and no Directionality Rule. The absence of the Bidi Rule is intentional to maximize password entropy.
The UsernameCaseMapped profile applies to usernames and uses the PRECIS IdentifierClass with rules: Width Mapping (fullwidth/halfwidth to decomposition), Case Mapping (uppercase/titlecase to lowercase via Unicode toLowerCase()), NFC Normalization, and the Bidi Rule for right-to-left strings.
The UsernameCasePreserved profile is identical to UsernameCaseMapped except it omits the Case Mapping Rule, preserving the original case of uppercase and titlecase code points. It applies the same Width Mapping, NFC Normalization, and Bidi Rule.
IANA has added the OpaqueString profile to the 'PRECIS Profiles' registry. It is based on FreeformClass, replaces the SASLprep profile of Stringprep, maps non-ASCII spaces to SPACE (U+0020), applies NFC normalization, and has no Width Mapping, Case Mapping, or Directionality Rule.
IANA has added the UsernameCaseMapped profile to the 'PRECIS Profiles' registry. It is based on IdentifierClass, replaces the SASLprep profile of Stringprep, applies Width Mapping, Case Mapping to lowercase, NFC normalization, and the Bidi Rule.
IANA has added the UsernameCasePreserved profile to the 'PRECIS Profiles' registry. It is based on IdentifierClass, replaces the SASLprep profile of Stringprep, applies Width Mapping, NFC normalization, and the Bidi Rule, but has no Case Mapping Rule.
In systems conforming to modern best practices, password verification during authentication should not use the comparison defined in Section 4.2.3. Instead, the system should prepare and enforce rules before performing cryptographic calculations, since the password is not available in plaintext on the server.
The ability to include a wide range of characters in passwords can increase entropy and thus strength, but this must be weighed against the practical need to reproduce those characters on various devices with various input methods.
The process of comparing identifiers (SASL simple usernames, authentication identifiers, authorization identifiers) can lead to false rejects or false accepts, both of which have security implications. A detailed discussion is in RFC 6943.