RFC 8265

Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords

📅 published October 2017, from ietf

RFC 8265 🎀

Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords 💖

Authors: P. Saint-Andre (Jabber.org) and A. Melnikov (Isode Ltd) 👑

Category: Standards Track 🏆

Date: October 2017 📅

Obsoletes: RFC 7613 🔁

ISSN: 2070-1721 🌈

Internet Engineering Task Force (IETF) 🌸

Abstract 💜

okay so this doc is all about updated ways to handle Unicode strings for usernames and passwords 💅 The old approach was called SASLprep (RFC 4013), which was built on Stringprep (RFC 3454). The methods in here are a more sustainable way to handle internationalized usernames and passwords ✨ This document obsoletes RFC 7613. 🦋

Status of This Memo 📜

bestie this is an Internet Standards Track document 🏆

It's an official IETF product. It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) signed off on it for publication. More on Internet Standards lives in Section 2 of RFC 7841 🔍

Want the latest on this doc, its errata, or how to send feedback? Check https://www.rfc-editor.org/info/rfc8265 🔗

Copyright Notice ©️

This doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions 📖

Any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License 🚫⚠️

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Usernames . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  3.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . .   5
  3.2.  Case Mapping vs. Case Preservation  . . . . . . . . . . .   6
  3.3.  UsernameCaseMapped Profile  . . . . . . . . . . . . . . .   7
    3.3.1.  Rules . . . . . . . . . . . . . . . . . . . . . . . .   7
    3.3.2.  Preparation . . . . . . . . . . . . . . . . . . . . .   8
    3.3.3.  Enforcement . . . . . . . . . . . . . . . . . . . . .   8
    3.3.4.  Comparison  . . . . . . . . . . . . . . . . . . . . .   9
  3.4.  UsernameCasePreserved Profile . . . . . . . . . . . . . .   9
    3.4.1.  Rules . . . . . . . . . . . . . . . . . . . . . . . .   9
    3.4.2.  Preparation . . . . . . . . . . . . . . . . . . . . .   9
    3.4.3.  Enforcement . . . . . . . . . . . . . . . . . . . . .  10
    3.4.4.  Comparison  . . . . . . . . . . . . . . . . . . . . .  10
  3.5.  Application-Layer Constructs  . . . . . . . . . . . . . .  11
  3.6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  11
4.  Passwords . . . . . . . . . . . . . . . . . . . . . . . . . .  13
  4.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . .  13
  4.2.  OpaqueString Profile  . . . . . . . . . . . . . . . . . .  14
    4.2.1.  Preparation . . . . . . . . . . . . . . . . . . . . .  14
    4.2.2.  Enforcement . . . . . . . . . . . . . . . . . . . . .  14
    4.2.3.  Comparison  . . . . . . . . . . . . . . . . . . . . .  15
  4.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  15
5.  Use in Application Protocols  . . . . . . . . . . . . . . . .  16
6.  Migration . . . . . . . . . . . . . . . . . . . . . . . . . .  17
  6.1.  Usernames . . . . . . . . . . . . . . . . . . . . . . . .  17
  6.2.  Passwords . . . . . . . . . . . . . . . . . . . . . . . .  19
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
  7.1.  UsernameCaseMapped Profile  . . . . . . . . . . . . . . .  20
  7.2.  UsernameCasePreserved Profile . . . . . . . . . . . . . .  20
  7.3.  OpaqueString Profile  . . . . . . . . . . . . . . . . . .  21
  7.4.  Stringprep Profile  . . . . . . . . . . . . . . . . . . .  22
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
  8.1.  Password/Passphrase Strength  . . . . . . . . . . . . . .  22
  8.2.  Password/Passphrase Comparison  . . . . . . . . . . . . .  22
  8.3.  Identifier Comparison . . . . . . . . . . . . . . . . . .  22
  8.4.  Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . .  22
  8.5.  Reuse of Unicode  . . . . . . . . . . . . . . . . . . . .  22
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  24
Appendix A.  Changes from RFC 7613  . . . . . . . . . . . . . . .  25
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  26
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1. Introduction ✨

Usernames and passwords are everywhere on the Internet for authentication and authorization 🔐 Sometimes they travel in plaintext, like with the PLAIN Simple Authentication and Security Layer (SASL) mechanism [RFC4616] and the HTTP Basic scheme [RFC7617]. Other times they get fed into a cryptographic algorithm, like a hash function, as in the Salted Challenge Response Authentication Mechanism (SCRAM) SASL mechanism [RFC5802] and the HTTP Digest scheme [RFC7616].

So that typing and comparing usernames and passwords makes sense for people all over the world 🌍, this document sets rules for handling internationalized strings that represent them. These strings are made of code points from the Unicode coded character set [Unicode], with extra attention paid to code points outside the ASCII range [RFC20]. The rules are spelled out as profiles of the string classes from the preparation, enforcement, and comparison of internationalized strings (PRECIS) framework specification [RFC8264] 💜

PRECIS profiles let software handle non-ASCII Unicode code points automatically, so they get treated carefully and consistently across application protocols. Mostly these profiles protect app developers from the risks of supporting the whole Unicode range 🛡️ For example, in almost every application protocol, treating ¹ (SUPERSCRIPT ONE, U+00B9) as equivalent to 1 (DIGIT ONE, U+0031) would be dangerous 🙈 It would cause false accepts during comparison, authentication, and authorization. An attacker could easily spoof the account user1@example.com. 😱

Without a careful approach, naive Unicode use would make attacks trivially easy 😈, but the username profile defined here generally keeps applications from causing these problems by accident. (Passwords have similar concerns, but there it's actually desirable to support a wider range of characters, so you get more entropy for authentication 🔑.)

The methods here might apply anywhere usernames or passwords show up. They're not meant for strings that aren't usernames, like Lightweight Directory Access Protocol (LDAP) distinguished names 🙅. They're also not meant for cases where identifiers or secrets aren't strings, like keys and certificates, or where they need specialized handling.

The historical ancestor of this doc was the SASLprep profile of Stringprep [RFC3454], but the approach here can be used by technologies other than SASL [RFC4422], like HTTP authentication as specified in [RFC7617] and [RFC7616] 🌸

🛑 Big note: this document doesn't change how existing application protocols that use SASLprep handle internationalized strings in usernames and passwords. If a community wants to modernize and move from Stringprep to PRECIS, it has to explicitly update that application protocol's definition (one example is [RFC7622]). Uncoordinated updates to protocol implementations are discouraged, since they can hurt interoperability and security 💀

2. Terminology 📖

A "username" or "user identifier" is a string of characters that designates an account on a computing device or system 🧑‍💻, often but not necessarily for a person to use. Sure, some devices let a username be part or all of a person's name, and people might want their account designator to match their name. But because of the complexities involved, that isn't guaranteed for every human name on every device or system that follows these rules 🥺 Protocol designers and app developers who want to allow a wider range of characters are encouraged to separate more restrictive account identifiers from more expressive display names or nicknames (see [RFC8266]) 🦋

A "password" is a string of characters that allows access to a computing device or system, often tied to a particular username 🔐 It's not literally limited to a single word, since a password could be a passphrase made of several words, perhaps separated by spaces, punctuation, or other non-alphanumeric characters ✨

Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) say that the authentication identity used in those mechanisms is a "simple username" (see Section 2 of [RFC4422] as well as [RFC4013]). Lots of application technologies also assume a user's identity takes the form of a username (like authentication for the Hypertext Transfer Protocol as specified in [RFC7617] and [RFC7616]), whether or not they use SASL 🌈 Note well: the exact form of a username in any particular SASL mechanism or application technology is up to implementation and deployment 👀 A username also doesn't necessarily map to any particular application identifier.

Lots of important terms in this doc are defined in [RFC5890], [RFC6365], [RFC8264], and [Unicode] 📚 The term "non-ASCII space" refers to any Unicode code point with a Unicode general category of Zs 🌟, naturally except for SPACE (U+0020) 🙄

Okay, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like here 💅

3. Usernames 🎀

Part 1 ends right here, bestie! 💖 Part 2 picks up with Section 3, so stay tuned 🧚

3.1. Definition

okay so bestie, this is the big one ✨. A username is a string of Unicode code points [Unicode] structured as an ordered sequence of "userparts", written in a standard Unicode Encoding Form (such as UTF-8 [RFC3629]). Every userpart can only hold code points that the PRECIS IdentifierClass from Section 4.2 of [RFC8264] allows, which is why it's almost totally letters and digits 🌸. A username can be one userpart on its own, or a bunch of userparts separated by spaces 💖.

Here's the grammar, written in Augmented Backus-Naur Form (ABNF) [RFC5234] 🎀:

username   = userpart *(1*SP userpart)
userpart   = 1*(idpoint)
             ;
             ; an "idpoint" is a Unicode code point that
             ; can be contained in a string conforming to
             ; the PRECIS IdentifierClass
             ;

Anything the IdentifierClass doesn't explicitly allow is out, no exceptions 🙅‍♀️. That includes private-use code points, surrogate code points, and all the other code points and blocks that were called "Prohibited Output" in Section 2.3 of [RFC4013] (once they're corrected per [Err1812]). The one plot twist is that common constructions like user@example.com (for example, the Network Access Identifier from [RFC7542]) are still allowed as usernames under this spec, same as they were under [RFC4013] 🦋.

Implementation Note: Don't assume this definition matches everything your deployed apps call a "username" or "userid" 🙈. This is really a relatively safe subset of Unicode code points that works with existing SASL mechanisms, with application protocols that use SASL, and even with plenty of application protocols that don't use SASL yet 💅.

A username MUST NOT be zero bytes in length. This rule gets enforced after any normalization and mapping of code points, so nothing sneaks past it 👑.

This spec defines two profiles for usernames: the UsernameCaseMapped profile does case mapping, and the UsernameCasePreserved profile does case preservation. (There's more tea on that in Section 3.2 🍓.)

In protocols that feed usernames into a cryptographic algorithm, like a hash function, the client will need to enforce the rules for the UsernameCaseMapped or UsernameCasePreserved profile before it applies the algorithm 🔐.

3.2. Case Mapping vs. Case Preservation

So to fit the widest range of username setups in apps, this document defines two profiles: UsernameCaseMapped and UsernameCasePreserved. The only real difference between them is whether they use the Case Mapping Rule, and otherwise they're identical 💜.

Case mapping is up to the application protocol, the protocol implementation, or the end deployment. In general this document suggests that UsernameCaseMapped is the better pick, so you do case mapping. Skipping it can lead to false accepts during authentication and authorization (as described in [RFC6943]), and it can confuse end users, since so many existing protocols and apps already do case mapping 🤔. That said, there can be good reasons to go with UsernameCasePreserved and skip case mapping, like backward compatibility with infrastructure that's already out there 🛠️.

Here's the breakdown:

SASL mechanisms that follow the recommendations in this document MUST specify whether and when case mapping is applied to authentication identifiers. Case mapping loses information, so implementations SHOULD delay any case mapping until the last possible moment to keep that info around as long as possible. That moment is things like doing a lookup by username, comparing usernames, or generating a cryptographic salt from a username. (If the last possible moment happens on a server, then case mapping decisions can just be a matter of service deployment policy 🧁.) Following [RFC4422], SASL mechanisms aren't allowed to apply this or any other profile to authorization identifiers, only to authentication identifiers 🚫.
Application protocols that use SASL (like IMAP [RFC3501] and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120]) and that directly reuse this profile MUST specify whether or not case mapping is applied to authorization identifiers. These "SASL application protocols" SHOULD delay any case mapping of authorization identifiers to the last possible moment, which always ends up being on the server side. (That way, case mapping decisions are a matter of service deployment policy ✨.) Following [RFC4422] again, SASL application protocols aren't allowed to apply this or any other profile to authentication identifiers, only to authorization identifiers 💅.
Application protocols that don't use SASL (like HTTP authentication with the HTTP Basic and Digest schemes in [RFC7617] and [RFC7616]) but that directly reuse this profile MUST specify whether and when case mapping is applied to authentication identifiers, authorization identifiers, or both 🌈. These "non-SASL application protocols" SHOULD delay any case mapping to the last possible moment, like doing a lookup by username, comparing usernames, or generating a cryptographic salt from a username. (If that last moment happens on the server, case mapping decisions can be a matter of service deployment policy 🫶.)

If the spec for a SASL mechanism, a SASL application protocol, or a non-SASL application protocol uses the UsernameCaseMapped profile, it MUST clearly describe whether case mapping is applied at the level of the protocol itself, its implementations, or service deployments. Each of those approaches can be legit, depending on the app you're building 👑.

3.3. UsernameCaseMapped Profile

3.3.1. Rules

These rules are defined for use within the UsernameCaseMapped profile of the PRECIS IdentifierClass 🦋.

Width Mapping Rule: Map fullwidth and halfwidth code points to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]).
Additional Mapping Rule: There is no additional mapping rule. Nothing extra here, bestie 🙌.
Case Mapping Rule: Map uppercase and titlecase code points to their lowercase equivalents, preferably using the Unicode toLowerCase() operation as defined in the Unicode Standard [Unicode]. See further discussion in Section 3.2 📚.
Normalization Rule: Apply Unicode Normalization Form C (NFC) to all strings 💎.
Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893] to strings that contain right-to-left code points (so each of the six conditions of the Bidi Rule must be satisfied). For strings that don't contain right-to-left code points, there's no special directionality processing 🧭.

3.3.2. Preparation

An entity that prepares an input string for later enforcement under this profile MUST go through these steps, in the order shown 📝.

Apply the width mapping rule specified in Section 3.3.1. This has to happen at this point, because otherwise the PRECIS "HasCompat" category specified in Section 9.17 of [RFC8264] would forbid fullwidth and halfwidth code points 🚫.
Make sure the string only has Unicode code points that are explicitly allowed by the PRECIS IdentifierClass defined in Section 4.2 of [RFC8264] ✅.

3.3.3. Enforcement

An entity that enforces this profile MUST prepare an input string as described in Section 3.3.2, and MUST also apply the following rules from Section 3.3.1, in the order shown 🔥:

Case Mapping Rule
Normalization Rule
Directionality Rule

After all of those rules have been enforced, the entity MUST make sure the username is not zero bytes in length. This check happens last so applications don't accidentally skip the username entirely. When internationalized strings are accepted, a non-empty sequence of characters can end up as a zero-length username after canonicalization 😭.

The result of all that 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 an input string is conforming before enforcement has finished 🙅‍♀️.)

3.3.4. Comparison

An entity that compares two strings under this profile MUST prepare each string as specified in Section 3.3.2, and then MUST enforce the rules in Section 3.3.3. The two strings are equivalent if and only if they're an exact octet-for-octet match (sometimes called "bit-string identity") 💜.

Until an implementation decides whether two strings are equivalent, it MUST NOT treat them as equivalent. (In particular, it MUST NOT assume two input strings are equivalent before the comparison has been completed 🫠.)

3.4. UsernameCasePreserved Profile

3.4.1. Rules

These rules are defined for use within the UsernameCasePreserved profile of the PRECIS IdentifierClass 🎀.

Width Mapping Rule: Map fullwidth and halfwidth code points to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]).
Additional Mapping Rule: There is no additional mapping rule.
Case Mapping Rule: There is no case mapping rule. Case stays exactly as it was typed 🌸.
Normalization Rule: Apply Unicode Normalization Form C (NFC) to all strings.
Directionality Rule: Apply the "Bidi Rule" defined in [RFC5893] to strings that contain right-to-left code points (so each of the six conditions of the Bidi Rule must be satisfied). For strings that don't contain right-to-left code points, there's no special directionality processing.

3.4.2. Preparation

An entity that prepares a string for later enforcement under this profile MUST go through these steps, in the order shown ✨.

Apply the width mapping rule specified in Section 3.4.1. This has to happen here, because otherwise the PRECIS "HasCompat" category specified in Section 9.17 of [RFC8264] would forbid fullwidth and halfwidth code points 💖.
Make sure the string only has Unicode code points that are explicitly allowed by the PRECIS IdentifierClass defined in Section 4.2 of [RFC8264] 🦋.

3.4.3. Enforcement ✨

okay so, an entity enforcing this profile MUST prepare the string the way Section 3.4.2 describes, and it MUST also apply the rules from Section 3.4.1 in this exact order: 🎀

Normalization Rule
Directionality Rule

once all of that is done, the entity MUST ensure the username is not zero bytes in length. this check goes last on purpose so apps don't accidentally drop a username entirely 😭 (with internationalized strings, a non-empty run of characters can turn into a zero-length username after canonicalization, so it's a real trap 💀)

the result is an output string that conforms to the UsernameCasePreserved profile 💖. until an implementation actually produces that output string, it MUST NOT treat the string as conforming. (in particular, it MUST NOT assume an input string is conforming before enforcement is finished 🙈)

3.4.4. Comparison 💜

an entity comparing two strings under this profile MUST prepare each string as specified in Section 3.4.2, and then MUST enforce the rules in Section 3.4.3. the two strings count as equivalent if and only if they're an exact octet-for-octet match, which is sometimes called "bit-string identity" 🧚

until an implementation has figured out whether two strings are equivalent, it MUST NOT treat them as equivalent. (in particular, it MUST NOT assume two input strings are equivalent before the comparison is done 🫶)

3.5. Application-Layer Constructs 🌈

both the UsernameCaseMapped and UsernameCasePreserved profiles let an application protocol, implementation, or deployment build application-layer constructs, like a username that's a space-separated set of userparts such as "Firstname Middlename Lastname" 🍓

this isn't a profile of the PRECIS IdentifierClass, because SPACE (U+0020) isn't allowed in the IdentifierClass 🙅‍♀️. BUT it can still be created at the application layer, because SPACE (U+0020) can be used as a separator between instances of the PRECIS IdentifierClass (e.g., userparts as defined in this specification) ✨

3.6. Examples 🦋

these examples show a few userparts (not usernames) that fit the format we just talked about. (the "<" and ">" characters are only here to mark where each userpart starts and ends. they aren't part of the userpart strings 💅)

+--------------------------+---------------------------------+
| # | Userpart             | Notes                           |
+--------------------------+---------------------------------+
| 1 | <juliet@example.com> | The "at" sign ("@") is allowed  |
|   |                      | in the PRECIS IdentifierClass   |
+--------------------------+---------------------------------+
| 2 | <fussball>           |                                 |
+--------------------------+---------------------------------+
| 3 | <fußball>            | The third character is LATIN    |
|   |                      | SMALL LETTER SHARP S (U+00DF)   |
+--------------------------+---------------------------------+
| 4 | <π>                  | A userpart of GREEK SMALL       |
|   |                      | LETTER PI (U+03C0)              |
+--------------------------+---------------------------------+
| 5 | <Σ>                  | A userpart of GREEK CAPITAL     |
|   |                      | LETTER SIGMA (U+03A3)           |
+--------------------------+---------------------------------+
| 6 | <σ>                  | A userpart of GREEK SMALL       |
|   |                      | LETTER SIGMA (U+03C3)           |
+--------------------------+---------------------------------+
| 7 | <ς>                  | A userpart of GREEK SMALL       |
|   |                      | LETTER FINAL SIGMA (U+03C2)     |
+--------------------------+---------------------------------+

                 Table 1: A Sample of Legal Userparts

okay so about examples 2 and 3 🥨: in German writing, the eszett "ß" (LATIN SMALL LETTER SHARP S, U+00DF) can mostly be swapped with the two characters "ss". but these userparts are still different, so (if you want) a server would need to enforce a registration policy that blocks one of them if the other is already registered 🔒

and for examples 5, 6, and 7 💫: optional case mapping of "Σ" (GREEK CAPITAL LETTER SIGMA, U+03A3) to the lowercase "σ" (GREEK SMALL LETTER SIGMA, U+03C3) during comparison would make the userparts in examples 5 and 6 match. however, the PRECIS mapping rules don't account for the special status of "ς" (GREEK SMALL LETTER FINAL SIGMA, U+03C2), so examples 5 and 7, or examples 6 and 7, would NOT match during comparison 😭

next up are strings that are NOT valid userparts (not usernames) because they break the format above 🚫

+--------------------------+---------------------------------+
| # | Non-Userpart String  | Notes                           |
+--------------------------+---------------------------------+
| 8 | <foo bar>            | SPACE (U+0020) is disallowed in |
|   |                      | the userpart                    |
+--------------------------+---------------------------------+
| 9 | <>                   | Zero-length userpart            |
+--------------------------+---------------------------------+
| 10| <henryⅣ>            | The sixth character is ROMAN    |
|   |                      | NUMERAL FOUR (U+2163)           |
+--------------------------+---------------------------------+
| 11| <∞>                  | A userpart of INFINITY (U+221E) |
+--------------------------+---------------------------------+

 Table 2: A Sample of Strings That Violate the Userpart Rules

example 8 is a bit of a plot twist 🎭: it's not a valid userpart, BUT it IS a valid username, because it's a space-separated sequence of userparts ✨

example 10: the character "Ⅳ" (ROMAN NUMERAL FOUR, U+2163) has a compatibility equivalent of "I" (LATIN CAPITAL LETTER I, U+0049) and "V" (LATIN CAPITAL LETTER V, U+0056). but code points with compatibility equivalents aren't allowed in the PRECIS IdentifierClass, so no dice 🙅‍♀️

example 11: symbols like "∞" (INFINITY, U+221E) aren't allowed in the PRECIS IdentifierClass either 💀

4. Passwords 🔐

4.1. Definition 💖

this document says a password is a string of Unicode code points [Unicode] that conforms to the OpaqueString profile (specified below) of the PRECIS FreeformClass defined in Section 4.3 of [RFC8264], and it's expressed in a standard Unicode Encoding Form (such as UTF-8 [RFC3629]) 🌸

the syntax for a password is defined using the Augmented Backus-Naur Form (ABNF) [RFC5234] 📜

password   = 1*(freepoint)
             ;
             ; a "freepoint" is a Unicode code point that
             ; can be contained in a string conforming to
             ; the PRECIS FreeformClass
             ;

everything that isn't explicitly allowed in the PRECIS FreeformClass is disallowed 🚧. that includes private-use code points, surrogate code points, and the other code points and blocks listed as "Prohibited Output" in Section 2.3 of [RFC4013] (when corrected per [Err1812]) 🙈

a password MUST NOT be zero bytes in length. this rule gets enforced after any normalization and mapping of code points 🫶

Note: Some existing systems let an empty string sit where a password would go (for example, command-line tools that might get called from an automated script, or servers that might need to restart without a human around). From the perspective of this document (and RFC 4013 before it), these empty strings are NOT passwords. They're just workarounds for the practical difficulty of using passwords in certain scenarios 🧃

Note: The zero-length password ban is NOT a recommendation about password strength (a one-byte password is super insecure, obviously 😭). It's there to stop apps from accidentally leaving the password out entirely. That can happen with internationalized strings, because a non-empty sequence of characters can turn into a zero-length password after canonicalization 💀

in protocols that hand passwords to a cryptographic algorithm like a hash function, the client will need to perform enforcement of the OpaqueString profile rules before applying the algorithm. that's because the server never gets to see the password in plaintext form 🔥

4.2. OpaqueString Profile 🫧

the OpaqueString profile is defined in the sections that follow, including detailed info about preparation, enforcement, and comparison. (if you want the difference between those actions spelled out, check [RFC8264] 📚)

4.2.1. Preparation 🌟

an entity that prepares a string under this profile MUST ensure the string consists only of Unicode code points that are explicitly allowed by the FreeformClass string class defined in [RFC8264] 💅

4.2.2. Enforcement

An entity that enforces this profile MUST prepare a string as described in Section 4.2.1 and MUST also apply the rules specified below for the OpaqueString profile (these rules MUST be applied in the order shown):

Width Mapping Rule: Fullwidth and halfwidth code points MUST NOT be mapped to their decomposition mappings (see Unicode Standard Annex #11 [UAX11]).
Additional Mapping Rule: Any instances of non-ASCII space MUST be mapped to SPACE (U+0020); a non-ASCII space is any Unicode code point having a Unicode general category of "Zs", with the exception of SPACE (U+0020). As was the case in RFC 4013, the inclusion of only SPACE (U+0020) prevents confusion with various non-ASCII space code points, many of which are difficult to reproduce across different input methods.
Case Mapping Rule: There is no case mapping rule (because mapping uppercase and titlecase code points to their lowercase equivalents would lead to false accepts and thus to reduced security).
Normalization Rule: Unicode Normalization Form C (NFC) MUST be applied to all strings.
Directionality Rule: There is no directionality rule. The "Bidi Rule" (defined in [RFC5893]) and similar rules are unnecessary and inapplicable to passwords, because they can reduce the repertoire of characters that are allowed in a string and therefore reduce the amount of entropy that is possible in a password. Such rules are intended to minimize the possibility that the same string will be displayed differently on a layout system set for right-to-left display and a layout system set for left-to-right display; however, passwords are typically not displayed at all and are rarely meant to be interoperable across different layout systems in the way that non-secret strings like domain names and usernames are. Furthermore, it is perfectly acceptable for opaque strings other than passwords to be presented differently in different layout systems, as long as the 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

An entity that performs comparison of two strings according to this 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 strings are to be considered equivalent if and only if they are an 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 two input strings are equivalent before the comparison operation has been completed).

See Section 8.2 regarding comparison of passwords and passphrases.

4.3. Examples

The following examples illustrate a small number of passwords that are consistent with the format defined above (note that the characters "<" and ">" are used here to delineate the actual passwords and are not part of the password strings).

+------------------------------------+------------------------------+
| # | Password                       | Notes                        |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | SPACE (U+0020) is allowed    |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Differs by case from         |
|   |                                | example 12                   |
+------------------------------------+------------------------------+
| 14| <πßå>                          | Non-ASCII letters are OK     |
|   |                                | (e.g., GREEK SMALL LETTER    |
|   |                                | PI (U+03C0))                 |
+------------------------------------+------------------------------+
| 15| <Jack of ♦s>                   | Symbols are OK (e.g., BLACK  |
|   |                                | DIAMOND SUIT (U+2666))       |
+------------------------------------+------------------------------+
| 16| <foo bar>                      | OGHAM SPACE MARK (U+1680) is |
|   |                                | mapped to SPACE (U+0020);    |
|   |                                | thus, the full string is     |
|   |                                | mapped to <foo bar>          |
+------------------------------------+------------------------------+

                 Table 3: A Sample of Legal Passwords

The following examples illustrate strings that are not valid passwords because they violate the format defined above.

+------------------------------------+------------------------------+
| # | Password                       | Notes                        |
+------------------------------------+------------------------------+
| 17| <>                             | Zero-length passwords are    |
|   |                                | disallowed                   |
+------------------------------------+------------------------------+
| 18| <my cat is a &#x9;by>          | Control characters like TAB  |
|   |                                | (U+0009) are disallowed      |
+------------------------------------+------------------------------+

     Table 4: A Sample of Strings That Violate the Password Rules

Note: Following the "XML Notation" used in [RFC3987], the character TAB (U+0009) in example 18 is represented as &#x9 because otherwise it could not be shown in running text.

5. Use in Application Protocols ✨

This specification defines only the PRECIS-based rules for the handling of strings conforming to the UsernameCaseMapped and UsernameCasePreserved profiles of the PRECIS IdentifierClass, and strings conforming to the OpaqueString profile of the PRECIS FreeformClass. It is the responsibility of an application protocol to specify the protocol slots in which such strings can appear, the entities that are expected to enforce the rules governing such strings, and at what points during protocol processing or interface handling the rules need to be enforced. See Section 6 of [RFC8264] for guidelines on using PRECIS profiles in applications.

Above and beyond the PRECIS-based rules specified here, application protocols can also define application-specific rules governing such strings (rules regarding minimum or maximum length, further restrictions on allowable code points or character ranges, safeguards to mitigate the effects of visually similar characters, etc.), application-layer constructs (see Section 3.5), and related matters.

Some PRECIS profile definitions encourage entities that enforce the rules to be liberal in what they accept. However, for usernames and passwords such a policy can be problematic, because it can lead to false accepts. An in-depth discussion can be found in [RFC6943].

Applying the rules for any given PRECIS profile is not necessarily an idempotent procedure for all code points. Therefore, an implementation SHOULD apply the rules repeatedly until the output string is stable; if the output string does not stabilize after reapplying the rules three (3) additional times after the first application, the implementation SHOULD terminate application of the rules and reject the input string as invalid.

6. Migration 🧳

The rules defined in this specification differ slightly from those defined by the SASLprep specification [RFC4013] (but not from [RFC7613]). In order to smooth the process of migrating from SASLprep to the approach defined herein, the following sections describe these differences, along with their implications for migration, in more detail.

6.1. Usernames 🧹

okay so if your deployment has been using SASLprep for usernames, you might need to scrub existing data when you migrate to the rules in this spec. here's the tea 🫖💅

Normalization form (NFKC vs NFC) 🔥 SASLprep specified Unicode Normalization Form KC (NFKC), but the UsernameCaseMapped and UsernameCasePreserved profiles use Unicode Normalization Form C (NFC). ngl this change is unlikely to cause significant problems, because NFKC maps code points with compatibility equivalents to those equivalents, whereas the PRECIS IdentifierClass entirely disallows Unicode code points with compatibility equivalents. so during comparison, NFKC is more "aggressive" about finding matches than NFC 👀 a few examples will give you the vibe:
1. ſ (LATIN SMALL LETTER LONG S, U+017F) is compatibility equivalent to s (LATIN SMALL LETTER S, U+0073).
2. Ⅳ (ROMAN NUMERAL FOUR, U+2163) is compatibility equivalent to I (LATIN CAPITAL LETTER I, U+0049) and V (LATIN CAPITAL LETTER V, U+0056).
3. ﬁ (LATIN SMALL LIGATURE FI, U+FB01) is compatibility equivalent to f (LATIN SMALL LETTER F, U+0066) and i (LATIN SMALL LETTER I, U+0069).

Under SASLprep, the use of NFKC also handled the mapping of fullwidth and halfwidth code points to their decomposition mappings.

For migration purposes, operators might want to search their database of usernames for names containing Unicode code points with compatibility equivalents and, where there is no conflict, map those code points to their equivalents. Naturally, it is possible that during this process the operator will discover conflicting usernames. for instance, "HENRYIV" with the last two code points being LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V (U+0056) as opposed to "HENRYⅣ" with the last character being "Ⅳ" (ROMAN NUMERAL FOUR, U+2163), which is compatibility equivalent to U+0049 and U+0056). in these cases, the operator will need to determine how to proceed, for instance, by disabling the account whose name contains a Unicode code point with a compatibility equivalent. such cases are probably rare, but it is important for operators to be aware of them 🥺

"Characters commonly mapped to nothing" 🫧 SASLprep mapped the "characters commonly mapped to nothing" (from Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS IdentifierClass entirely disallows most of these code points. those correspond to the code points from the PRECIS "M" category defined under Section 9.13 of [RFC8264]. for migration purposes, the operator might want to remove from usernames any code points contained in the PRECIS "M" category (e.g., SOFT HYPHEN (U+00AD)). because these code points would have been "mapped to nothing" in Stringprep, in practice a user would not notice the difference if, upon migration to PRECIS, the code points are removed ✨
Case handling 🔤 SASLprep allowed uppercase and titlecase code points, whereas the UsernameCaseMapped profile maps uppercase and titlecase code points to their lowercase equivalents. (by contrast, the UsernameCasePreserved profile matches SASLprep in this regard.) for migration purposes, the operator can use either the UsernameCaseMapped profile (thus losing the case information) or the UsernameCasePreserved profile (thus ignoring case difference when comparing usernames). pick your fighter 🥊

6.2. Passwords 🔐

depending on local service policy, migrating from SASLprep to this specification might not involve any scrubbing of data (because passwords might not be stored in the clear anyway). however, service providers need to be aware of possible issues that might arise during migration. the main ones:

Normalization form (NFKC vs NFC) 💖 SASLprep specified Unicode Normalization Form KC (NFKC), whereas the OpaqueString profile employs Unicode Normalization Form C (NFC). because NFKC is more aggressive about finding matches than NFC, in practice this change is unlikely to cause significant problems. it also has the security benefit of probably resulting in fewer false accepts when comparing passwords 🙌 a few examples:
1. ſ (LATIN SMALL LETTER LONG S, U+017F) is compatibility equivalent to s (LATIN SMALL LETTER S, U+0073).
2. Ⅳ (ROMAN NUMERAL FOUR, U+2163) is compatibility equivalent to I (LATIN CAPITAL LETTER I, U+0049) and V (LATIN CAPITAL LETTER V, U+0056).
3. ﬁ (LATIN SMALL LIGATURE FI, U+FB01) is compatibility equivalent to f (LATIN SMALL LETTER F, U+0066) and i (LATIN SMALL LETTER I, U+0069).

Under SASLprep, the use of NFKC also handled the mapping of fullwidth and halfwidth code points to their decomposition mappings. although it is expected that code points with compatibility equivalents are rare in existing passwords, some passwords that matched when SASLprep was used might no longer work when the rules in this specification are applied. yikes 😭

"Characters commonly mapped to nothing" 🫧 SASLprep mapped the "characters commonly mapped to nothing" (from Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS FreeformClass entirely disallows such code points. those correspond to the code points from the PRECIS "M" category defined under Section 9.13 of [RFC8264]. in practice, this change will probably have no effect on comparison, but user-oriented software might reject such code points instead of ignoring them during password preparation. so if a password field suddenly starts complaining, that's why 🙈

7. IANA Considerations 🦋

IANA has made the updates described below.

7.1. UsernameCaseMapped Profile 🌸

IANA has added the following entry to the "PRECIS Profiles" registry.

Name:  UsernameCaseMapped.

Base Class:  IdentifierClass.

Applicability:  Usernames in security and application protocols.

Replaces:  The SASLprep profile of Stringprep.

Width Mapping Rule:  Map fullwidth and halfwidth code points to their
   decomposition mappings.

Additional Mapping Rule:  None.

Case Mapping Rule:  Map uppercase and titlecase code points to
   lowercase.

Normalization Rule:  NFC.

Directionality Rule:  The "Bidi Rule" defined in RFC 5893 applies.

Enforcement:  To be defined by security or application protocols that
   use this profile.

Specification:  Section 3.3 of RFC 8265.

7.2. UsernameCasePreserved Profile 🌷

IANA has added the following entry to the "PRECIS Profiles" registry.

Name:  UsernameCasePreserved.

Base Class:  IdentifierClass.

Applicability:  Usernames in security and application protocols.

Replaces:  The SASLprep profile of Stringprep.

Width Mapping Rule:  Map fullwidth and halfwidth code points to their
   decomposition mappings.

Additional Mapping Rule:  None.

Case Mapping Rule:  None.

Normalization Rule:  NFC.

Directionality Rule:  The "Bidi Rule" defined in RFC 5893 applies.

Enforcement:  To be defined by security or application protocols that
   use this profile.

Specification:  Section 3.4 of RFC 8265.

7.3. OpaqueString Profile 🧁

IANA has added the following entry to the "PRECIS Profiles" registry.

Name:  OpaqueString.

Base Class:  FreeformClass.

Applicability:  Passwords and other opaque strings in security and
   application protocols.

Replaces:  The SASLprep profile of Stringprep.

Width Mapping Rule:  None.

Additional Mapping Rule:  Map non-ASCII space code points to SPACE
   (U+0020).

Case Mapping Rule:  None.

Normalization Rule:  NFC.

Directionality Rule:  None.

Enforcement:  To be defined by security or application protocols that
   use this profile.

Specification:  Section 4.2 of RFC 8265.

7.4. Stringprep Profile 🧾

The Stringprep specification [RFC3454] did not provide for entries in the "Stringprep Profiles" registry to have any state except "Current" or "Not Current". because RFC 7613 obsoleted RFC 4013, which registered the SASLprep profile of Stringprep, IANA previously marked that profile as "Not Current" and cited RFC 7613 as an additional reference. IANA has modified the profile so that the current document is now cited as the additional reference 💅

8. Security Considerations 💀

8.1. Password/Passphrase Strength 💪

The ability to include a wide range of characters in passwords and passphrases can increase the potential for creating a strong password with high entropy. however, in practice, the ability to include such characters ought to be weighed against the possible need to reproduce them on various devices using various input methods. so yes, more characters are great, but your users still have to be able to type them 📱⌨️

8.2. Password/Passphrase Comparison 🔍

In systems that conform to modern best practices for security, verification of passwords during authentication will not use the comparison defined in Section 4.2.3. instead, because the system performs cryptographic calculations to verify the password, it will 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 calculations. the vibe is: compare the hashes, not the raw strings 🧐

8.3. Identifier Comparison 🪪

The process of comparing identifiers (such as SASL simple usernames, authentication identifiers, and authorization identifiers) can lead to either false rejects or false accepts, and both of these have security implications 🚨. a more detailed discussion can be found in [RFC6943].

8.4. Reuse of PRECIS 🔁

The security considerations described in [RFC8264] apply to the IdentifierClass and FreeformClass string classes used in this document for usernames and passwords, respectively.

8.5. Reuse of Unicode 🌍

The security considerations described in [UTS39] apply to the use of Unicode code points in usernames and passwords.

9. References 📚

9.1. Normative References 📚✨

Okay bestie, these are the must-read docs the spec leans on 🫶 Every entry is listed with its full details:

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, https://www.rfc-editor.org/info/rfc3629.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, https://www.rfc-editor.org/info/rfc5234.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, https://www.rfc-editor.org/info/rfc5890.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, https://www.rfc-editor.org/info/rfc6365.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, https://www.rfc-editor.org/info/rfc8264.
[UAX11] Unicode Standard Annex #11, "East Asian Width", edited by Ken Lunde. An integral part of The Unicode Standard, http://unicode.org/reports/tr11/.
[Unicode] The Unicode Consortium, "The Unicode Standard", http://www.unicode.org/versions/latest/.

9.2. Informative References 🦋

These ones are the extra reading for when you want the full backstory 💅

[Err1812] RFC Errata, Erratum ID 1812, RFC 4013, https://www.rfc-editor.org/errata/eid1812.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, https://www.rfc-editor.org/info/rfc20.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, https://www.rfc-editor.org/info/rfc3454.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, https://www.rfc-editor.org/info/rfc3501.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, https://www.rfc-editor.org/info/rfc3987.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 2005, https://www.rfc-editor.org/info/rfc4013.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, https://www.rfc-editor.org/info/rfc4422.
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, DOI 10.17487/RFC4616, August 2006, https://www.rfc-editor.org/info/rfc4616.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI 10.17487/RFC5802, July 2010, https://www.rfc-editor.org/info/rfc5802.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, https://www.rfc-editor.org/info/rfc5893.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, https://www.rfc-editor.org/info/rfc6120.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, https://www.rfc-editor.org/info/rfc6943.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, https://www.rfc-editor.org/info/rfc7542.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, https://www.rfc-editor.org/info/rfc7613.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, https://www.rfc-editor.org/info/rfc7616.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, https://www.rfc-editor.org/info/rfc7617.
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 7622, DOI 10.17487/RFC7622, September 2015, https://www.rfc-editor.org/info/rfc7622.
[RFC8266] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 8266, DOI 10.17487/RFC8266, October 2017, https://www.rfc-editor.org/info/rfc8266.
[UTS39] Unicode Technical Standard #39, "Unicode Security Mechanisms", edited by Mark Davis and Michel Suignard, http://unicode.org/reports/tr39/.

Appendix A. Changes from RFC 7613 🎀

Here's the glow-up tea ☕ These are all the changes made from [RFC7613]:

Corrected the order of operations for the UsernameCaseMapped profile to ensure consistency with [RFC8264]. 💖
In accordance with working group discussions and updates to [RFC8264], removed the use of the Unicode toCaseFold() operation in favor of the Unicode toLowerCase() operation. 🧚
Modified the presentation (but not the content) of the rules. ✨
Removed UTF-8 as a mandatory encoding, because that is a matter for the application. 🍓
Clarified several editorial matters. 💅
Updated references. 📚

See [RFC7613] for a description of the differences from [RFC4013]. It's giving history lesson 🙈

Acknowledgements 🫶

Huge thanks to Christian Schudt and Sam Whited for their bug reports and feedback. You two are literally the reason this got better 💜

See [RFC7613] for acknowledgements related to the specification that this document supersedes. 👑

Authors' Addresses 🦋

Here are the girlies who wrote it 💖

Peter Saint-Andre
Jabber.org
P.O. Box 787
Parker, CO  80134
United States of America

Phone: +1 720 256 6756
Email: stpeter@jabber.org
URI:   https://www.jabber.org/

Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex  TW12 2BX
United Kingdom

Email: Alexey.Melnikov@isode.com

📦 where this page comes from

ietf: rfc8265 2017-10
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms