RFC 6885

Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)

📅 published March 2013, from ietf

RFC 6885: Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) 🎀

Okay bestie, RFC 6885 is an Informational doc from the IETF, published March 2013 and labelled ISSN 2070-1721. It's written by M. Blanchet from Viagenie and A. Sullivan from Dyn, Inc. 💖 Its title block doesn't list anything it obsoletes or updates, so it just stands on its own ✨

Abstract 🦋

Picture this 🫶 If a protocol wants to compare two strings and it was only ever built for ASCII, then the moment Unicode code points show up, those strings need to get prepared somehow, or the comparisons get messy 💀 Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols then made their own Stringprep profiles. IDNA2008 is a brand new approach, different from Stringprep and Nameprep. So other Stringprep profiles need similar updates, or Stringprep needs a replacement. This doc is the tea on the issues people designing a Stringprep replacement will have to face 🧚

Status of This Memo 🌈

Heads up, this one isn't an Internet Standards Track spec. It's published for informational purposes only 📚

It is a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 💅

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6885 🍓

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🫶 Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⭐

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
2.  Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
3.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
4.  Stringprep Profiles Limitations  . . . . . . . . . . . . . . .  6
5.  Major Topics for Consideration . . . . . . . . . . . . . . . .  8
  5.1.  Comparison . . . . . . . . . . . . . . . . . . . . . . . .  8
    5.1.1.  Types of Identifiers . . . . . . . . . . . . . . . . .  8
    5.1.2.  Effect of Comparison . . . . . . . . . . . . . . . . .  8
  5.2.  Dealing with Characters  . . . . . . . . . . . . . . . . .  9
    5.2.1.  Case Folding, Case Sensitivity, and Case
            Preservation . . . . . . . . . . . . . . . . . . . . .  9
    5.2.2.  Stringprep and NFKC  . . . . . . . . . . . . . . . . .  9
    5.2.3.  Character Mapping  . . . . . . . . . . . . . . . . . . 10
    5.2.4.  Prohibited Characters  . . . . . . . . . . . . . . . . 10
    5.2.5.  Internal Structure, Delimiters, and Special
            Characters . . . . . . . . . . . . . . . . . . . . . . 10
    5.2.6.  Restrictions Because of Glyph Similarity . . . . . . . 11
  5.3.  Where the Data Comes from and Where It Goes  . . . . . . . 11
    5.3.1.  User Input and the Source of Protocol Elements . . . . 11
    5.3.2.  User Output  . . . . . . . . . . . . . . . . . . . . . 12
    5.3.3.  Operations . . . . . . . . . . . . . . . . . . . . . . 12
6.  Considerations for Stringprep Replacement  . . . . . . . . . . 13
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9.  Informative References . . . . . . . . . . . . . . . . . . . . 15
Appendix A.  Classification of Stringprep Profiles . . . . . . . . 19
Appendix B.  Evaluation of Stringprep Profiles . . . . . . . . . . 19
  B.1.  iSCSI Stringprep Profile: RFC 3720, RFC 3721, RFC 3722 . . 19
  B.2.  SMTP/POP3/ManageSieve Stringprep Profiles: RFC 4954,
        RFC 5034, RFC 5804 . . . . . . . . . . . . . . . . . . . . 21
  B.3.  IMAP Stringprep Profiles for Usernames: RFC 4314, RFC
        5738 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
  B.4.  IMAP Stringprep Profiles for Passwords: RFC 5738 . . . . . 26
  B.5.  Anonymous SASL Stringprep Profiles: RFC 4505 . . . . . . . 28
  B.6.  XMPP Stringprep Profiles for Nodeprep: RFC 3920  . . . . . 30
  B.7.  XMPP Stringprep Profiles for Resourceprep: RFC 3920  . . . 31
  B.8.  EAP Stringprep Profiles: RFC 3748  . . . . . . . . . . . . 33

1. Introduction 🌸

Okay so Internationalizing Domain Names in Applications (here called IDNA2003) [RFC3490] [RFC3491] [RFC3492] and [RFC3454] describes a mechanism for encoding the Unicode labels that make up Internationalized Domain Names (IDNs) as standard DNS labels 🌐 Those labels got processed with a method called Nameprep [RFC3491] and Punycode [RFC3492]. That method was specific to IDNA2003, but it got generalized as Stringprep [RFC3454]. Other protocols with similar needs (but different constraints than IDNA2003) use the general mechanism too 🧠

Stringprep is basically a framework that lets protocols define their own Stringprep profiles. Here are some known IETF specs that use it 👑

  • The Nameprep profile [RFC3490] for use in Internationalized Domain Names (IDNs);
  • The Inter-Asterisk eXchange (IAX) using Nameprep [RFC5456];
  • NFSv4 [RFC3530] and NFSv4.1 [RFC5661];
  • The Internet Small Computer System Interface (iSCSI) profile [RFC3722] for use in iSCSI names;
  • The Extensible Authentication Protocol (EAP) [RFC3748];
  • The Nodeprep and Resourceprep profiles [RFC3920] (which was obsoleted by [RFC6120]) for use in the Extensible Messaging and Presence Protocol (XMPP), and the XMPP to Common Presence and Instant Messaging (CPIM) mapping [RFC3922] (the latter of these relies on the former);
  • The Internationalized Resource Identifier (IRI) and URI in XMPP [RFC5122];
  • The Policy MIB profile [RFC4011] for use in the Simple Network Management Protocol (SNMP);
  • Transport Layer Security (TLS) [RFC4279];
  • The Lightweight Directory Access Protocol (LDAP) profile [RFC4518] for use with LDAP [RFC4511] and its authentication methods [RFC4513];
  • PKIX subject identification using LDAPprep [RFC4683];
  • PKIX Certificate Revocation List (CRL) using LDAPprep [RFC5280];
  • The Simple Authentication and Security Layer (SASL) [RFC4422] and SASLprep profile [RFC4013] for use in SASL;
  • Plain SASL using SASLprep [RFC4616];
  • SMTP Auth using SASLprep [RFC4954];
  • The Post Office Protocol (POP3) Auth using SASLprep [RFC5034];
  • TLS Secure Remote Password (SRP) using SASLprep [RFC5054];
  • SASL Salted Challenge Response Authentication Mechanism (SCRAM) using SASLprep [RFC5802];
  • Remote management of Sieve using SASLprep [RFC5804];
  • The Network News Transfer Protocol (NNTP) using SASLprep [RFC4643];
  • IMAP4 using SASLprep [RFC4314];
  • The trace profile [RFC4505] for use with the SASL ANONYMOUS mechanism;
  • Internet Application Protocol Collation Registry [RFC4790];
  • The unicode-casemap Unicode Collation [RFC5051].

Now here's the thing 🤔 A review (see [78PRECIS]) of these protocol specs found that they're super similar and can be grouped into a small number of classes. Plus, lots of them reuse the same Stringprep profile, like the SASL one 🫶

IDNA2003 got replaced because of some limitations described in [RFC4690]. The new IDN spec, called IDNA2008 [RFC5890], [RFC5891], [RFC5892], [RFC5893], was designed based on the considerations in [RFC5894] ✨ One big effect of IDNA2008 is that Nameprep and Stringprep aren't used at all anymore. Instead, it uses an algorithm based on Unicode properties of code points. That algorithm generates a stable and complete table of the supported Unicode code points for each Unicode version 📊

The difference is the approach. This algorithm is inclusion-based, while Stringprep/Nameprep is exclusion-based. IDNA2003 made an explicit list of excluded or mapped-away characters, so anything in Unicode 3.2 that wasn't on that list could be assumed allowed under the protocol. IDNA2008 flips that. It starts from the assumption that code points are disallowed, and then it uses Unicode properties to figure out whether a given code point is actually allowed 🔥

Last but not least, this doc lists the shortcomings and issues found by the protocols above that defined Stringprep profiles. It also lists the requirements for any potential replacement of Stringprep 💅

2. Keywords 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This doc uses a bunch of internationalization terms, which are defined and discussed in [RFC6365] 🌍

On top of that, this doc defines one more keyword:

  • PRECIS: Preparation and Comparison of Internationalized Strings ✨

3. Conventions 🎀

A single Unicode code point in this memo is written as U+ followed by four to six hexadecimal digits, as used in [Unicode61], Appendix A. 🦋

4. Stringprep Profiles Limitations ✨

okay so bestie, let's talk about Stringprep 🧚 During IETF 77 (March 2010), a BOF (basically a one-off meeting to figure stuff out) looked at where all the protocols that have defined Stringprep profiles [NEWPREP] are at right now. Here's what came out of it:

  • Stringprep is stuck on Version 3.2 of Unicode 😭 It hasn't been updated for newer versions of Unicode. So the protocols using it are stuck on Unicode 3.2too, and their specs need updating so they can support newer versions.
  • The protocols want to stop being glued to one specific Unicode version. They want the kind of version agility IDNA2008 has 🦋 This matters a lot because an application basically can't demand Unicode 3.2. It just gets whatever version the host has.
  • The protocols need better bidirectional support (bidi) than Stringprep currently gives them 🔥
  • If the protocols move to a newer Stringprep version or some other framework, backward compatibility is a must-have 🫶 For example, Stringprep normalization is based on and profiles may use Unicode Normalization Form KC (NFKC) [UAX15], while IDNA2008 mostly uses Unicode Normalization Form C (NFC) [UAX15]. Those are not the same thing, so this needs care 💅
  • Identifiers get passed between protocols! The same username string of code points might show up in SASL, XMPP, LDAP, and EAP. So a shared set of rules or classes of strings is way more appealing than separate rules for each protocol. Honestly, many Stringprep profiles reuse other profiles, so this ended up working by accident rather than by planning 💀

Protocols that use Stringprep profiles use strings for different things, too:

  • XMPP uses a different Stringprep profile for each part of the XMPP address Jabber Identifier (JID) 🎀 There's the localpart, which is similar to a username and used for authentication; the domainpart, which is a domain name; and the resourcepart, which is less restrictive than the localpart.
  • iSCSI uses a Stringprep profile for the names of protocol participants (called initiators and targets) 🌸 The iSCSI Qualified Name (IQN) format of iSCSI names contains a reversed DNS domain name.
  • SASL and LDAP use a Stringprep profile for usernames 🍓
  • LDAP also uses a set of Stringprep profiles, so it's a whole collection situation 🌈

The apparent judgement of the BOF attendees [NEWPREP] was that it would be highly desirable to have a replacement for Stringprep, with similar characteristics to IDNA2008 🦋 That replacement should let protocols use internationalized strings without a lot of specialized internationalization work, since internationalization expertise isn't really available in those protocols or working groups. So the IESG formed the PRECIS working group to take on the task 👑

Here's the plot twist, though 🙈 Even with all that love for the replacement in [NEWPREP] and the chartering of a working group, IDNA2008 might be a poor model for what other protocols should do. It's designed to support an old protocol that operates on the scale of the entire Internet. On top of that, IDNA2008 is meant to be deployed without any change to the base DNS protocol. Other protocols may aim for deployment in more local environments, or may have protocol version negotiation built in ✨

5. Major Topics for Consideration

This section gives you the overview of the big topics a Stringprep replacement needs to address 💖 The headings loosely match the categories that known Stringprep-using protocol RFCs have been evaluated under. For the details of those evaluations, see Appendix A.

5.1. Comparison

5.1.1. Types of Identifiers

Following [ID-COMP], identifiers can be organized into three classes based on how they may be compared with one another 🔍

Absolute Identifiers: Identifiers that can be compared byte-by-byte for equality.

Definite Identifiers: Identifiers that have a well-defined comparison algorithm that all parties agree on.

Indefinite Identifiers: Identifiers that have no single comparison algorithm that all parties agree on.

Definite Identifiers include cases like comparing Unicode code points in different encodings. They don't match byte for byte, but they can all be converted to a single encoding, which then does match byte for byte 🧠 Indefinite Identifiers are sometimes algorithmically comparable by well-specified subsets of parties. For more on these categories, see [ID-COMP].

The section on the existing known cases, Appendix A, uses the categories above 🎀

5.1.2. Effect of Comparison

The three classes of comparison style from Section 5.1.1 can have different effects when applied 👀 It's necessary to evaluate those effects if a comparison gives a false positive or a false negative, especially in terms of the consequences for security and usability. Big deal, right? It really is 😭

5.2. Dealing with Characters

This section lays out a range of issues about characters in the target protocols 💅 It covers the ways IDNA2008 might be a good analogy for other protocols, and the ways it might be a poor one.

5.2.1. Case Folding, Case Sensitivity, and Case Preservation

In IDNA2003, labels are always mapped to lowercase before the Punycode transformation 🍓 In IDNA2008, there's no mapping at all. Input is either a valid U-label or it isn't. Uppercase characters are, by definition, not valid U-labels, because they fall into the Unstable category (category B) of [RFC5892] 🔥

If there are protocols that require case to be preserved, then the analogy with IDNA2008 breaks down 💀 So existing protocols should be evaluated according to these criteria:

  1. Does the protocol use case folding? And if so, for all blocks of code points or just for certain subsets?
  2. Is the system or protocol case-sensitive?
  3. Does the system or protocol preserve case?

5.2.2. Stringprep and NFKC

Stringprep profiles may use normalization. If they do, they use NFKC [UAX15] (most profiles do) 🌸 It isn't clear that NFKC is the right normalization to use in all cases. [UAX15] has this observation about Normalization Forms KC and KD: "It is best to think of these Normalization Forms as being like uppercase or lowercase mappings: useful in certain contexts for identifying core meanings, but also performing modifications to the text that may not always be appropriate." 🫠

In general, NFKC is more aggressive about finding matches between code points than NFC is. For things like the spelling of users' names, NFKC may not be the best form to use 🙈 But one of the nice things about NFKC is that it deals with the width of characters that are otherwise similar, by canonicalizing half-width to full-width. In practice, that mapping step can be crucial ✨ So a replacement for Stringprep depends on analyzing the different use profiles and considering whether NFKC or NFC is the better normalization for each profile.

For the purposes of evaluating an existing example of Stringprep use, it helps to know whether it uses no normalization, NFKC, or NFC 🧚

5.2.3. Character Mapping

Along with the case mapping issues raised in Section 5.2.1, there's the question of whether some characters get mapped to other characters, or to nothing, during Stringprep 🌈 [RFC3454], Section 3, outlines a number of characters that are mapped to nothing, and it also lets Stringprep profiles define their own mappings 💖

5.2.4. Prohibited Characters

Along with case folding and other character mappings, many protocols have characters that are just flat-out disallowed 🚫 For example, control characters and special characters such as "@" or "/" may be prohibited in a protocol.

One of the main changes in IDNA2008 is how it approaches Unicode code points, using the new inclusion-based approach (see Section 1) 👑

Because IDNA2008 assumes by default that a code point is not allowed by the protocol, it has more than one class of "allowed by the protocol." That's different from IDNA2003 🧠 While some code points are disallowed outright, some are allowed only in certain contexts. The context-dependent rules come from how some characters are actually used. For instance, the ZERO WIDTH JOINER and ZERO WIDTH NON-JOINER (ZWJ, U+200D and ZWNJ, U+200C) are allowed with contextual rules because they're required in some circumstances. Yet Unicode considers them punctuation, so they would be DISALLOWED under the usual IDNA2008 derivation rules 🙃 The goal of IDNA2008 is to provide the widest repertoire of code points possible, consistent with the traditional DNS "LDH" (letters, digits, hyphen) rule (see [RFC0952]). It trusts the operators of individual zones to make sensible, and usually more restrictive, policies for their zones 🎀

5.2.5. Internal Structure, Delimiters, and Special Characters

IDNA2008 has a special problem with delimiters, because the delimiter "character" in the DNS wire format isn't really part of the data 😵‍💫 In DNS, labels aren't separated exactly. Instead, a label carries an indicator that says how long it is. When the label is displayed in presentation format as part of a fully qualified domain name, the label separator FULL STOP, U+002E (.) is used to break up the labels. But because that separator doesn't travel with the wire format of the domain name, there's no way to encode a different, "internationalized" separator in IDNA2008 💔

Other protocols may include characters with similar special meanings within the protocol. Common characters for these purposes include FULL STOP, U+002E (.); COMMERCIAL AT, U+0040 (@); HYPHEN-MINUS, U+002D (-); SOLIDUS, U+002F (/); and LOW LINE, U+005F (_) 🍓 Including one of these characters in a protocol isn't enough to make it similar to another protocol using the same character. How the character is handled has to be taken into consideration too.

An important issue to tackle is whether it's valuable to map to or from these special characters as part of the Stringprep replacement 🌍 In some locales, the analogue to FULL STOP, U+002E is some other character, and users may expect to be able to substitute their normal stop for FULL STOP, U+002E. At the same time, there are predictability arguments in favor of treating identifiers with FULL STOP, U+002E in them just the way they're treated under IDNA2008 🤓

5.2.6. Restrictions Because of Glyph Similarity

Homoglyphs are similarly (or identically) rendered glyphs of different code points 👀 For DNS names, homoglyphs may enable phishing, which is not it 🚨 If a protocol requires some visual comparison by end-users, then the issue of homoglyphs needs to be considered. In the DNS context, these issues are documented in [RFC5894] and [RFC4690]. However, IDNA2008 doesn't have a mechanism to deal with them. It trusts DNS zone operators to enact sensible policies for the subset of Unicode they wish to support, given their user community 🫶 A similar policy/protocol split may not be desirable in every protocol.

5.3. Where the Data Comes from and Where It Goes

5.3.1. User Input and the Source of Protocol Elements ✨

Okay so, some protocol elements get typed in by users and some don't 💅 The ones users never touch can presumably face tighter restrictions, but the ones users do provide likely need to allow the broadest range of code points 🌈 A few questions help sort this out:

  1. Do users input the strings directly?
  2. If so, how? (keyboard, stylus, voice, copy-paste, etc.)
  3. Where do we draw the line between user interface and protocol? (see [RFC5895]) 🎀

5.3.2. User Output 🦋

Just like only some protocol elements get typed in by users, only some get read by users 👀 It really matters how users are supposed to consume these elements, because every environment brings its own drama. An element that only ever shows up inside a vCard stays machine-readable, so visual confusion isn't as big a deal there 💜 But is the element published in a vCard, a web directory, on a business card, or on "the side of a bus"? 🚌 And do users treat it as an identifier, meaning they might type it in again somewhere else? (See also Section 5.2.6.) 🧚

5.3.3. Operations ⚙️

Some strings are useful in the protocol but never get fed into other operations (think purely informative or descriptive text) 🍓 Other strings go straight into other operations, like cryptographic hash functions, or get stuck together with other strings to make a unique identifier 🔥

5.3.3.1. String Classes 🧩

Strings often do the same job across different protocols 💖 Lots of protocols have user identifiers or passwords, so a single profile for all of those uses might be seriously desirable 👑

Also, a string in one protocol is often basically a protocol element from a different protocol. For example, different systems might use the same credentials database for authentication 🔐

5.3.3.2. Community Considerations 🫶

Any Stringprep replacement that does more than just update Stringprep to the latest version of Unicode will probably come with some changes 🌸 It's super important to figure out whether the protocol-using community is actually willing to accept backwards-incompatible changes 😭 And by the same token, we need to check how much the community wants features that Stringprep doesn't offer ✨

5.3.3.3. Unicode Incompatible Changes 🙈

IDNA2008 uses an algorithm to decide whether a Unicode code point is valid for use under IDNA2008 💅 It does this by checking each code point's properties.

This whole approach depends heavily on the idea that once a code point is valid for a protocol profile, it won't ever become invalid later 💀 Unicode doesn't currently guarantee that. Code point properties can change between Unicode versions, and every once in a while a change like that could make a code point invalid under a protocol profile, even though it was valid with an earlier version of Unicode 😱 This isn't just a "what if" either, because it has actually happened [RFC6452]! 🥲

So, just like IDNA2008, a Stringprep replacement that wants to be Unicode version agnostic will need a mechanism for handling cases where new Unicode versions cause incompatible changes 🔧

6. Considerations for Stringprep Replacement 🌟

Here's the vibe check from everything above, bestie 👑 The guidance looks like this:

  • A Stringprep replacement should be defined. 💖
  • The replacement should take an approach similar to IDNA2008 (e.g., by using properties of code points instead of whitelisting of code points), in that it enables better Unicode agility. 🦄
  • Protocols share similar characteristics of strings. Therefore, defining internationalization preparation algorithms for the smallest set of string classes may be sufficient for most cases, providing coherence among a set of related protocols or protocols where identifiers are exchanged. 🧚
  • The sets of string classes need to be evaluated according to the considerations that make up the headings in Section 5 📋
  • It is reasonable to limit scope to Unicode code points and rule the mapping of data from other character encodings outside the scope of this effort. 🌍
  • The replacement ought to at least provide guidance to applications using the replacement on how to handle protocol incompatibilities resulting from changes to Unicode. In an ideal world, the Stringprep replacement would handle the changes automatically, but it appears that such automatic handling would require magic and cannot be expected. ✨🪄
  • Compatibility within each protocol between a technique that is Stringprep-based and the technique's replacement has to be considered very carefully. 🫣

Existing deployments already depend on Stringprep profiles, so a replacement has to think hard about what any new strategy does to them 🥺 For comparison, some characters were fine in IDNA labels under IDNA2003 but aren't protocol-valid under IDNA2008 (and the reverse is also true). People disagreed about what to do during the transition, which led to different approaches to mapping 🙃 Implementers might make different calls in those cases, and that could cause interoperability problems 😬 Basically, better support for different linguistic environments has to be weighed against the possible side effects of backward incompatibility 💅

7. Security Considerations 🚨

This document only states what problems are to be solved. It does not define a protocol. There are undoubtedly security implications of the particular results that will come from the work to be completed. Moreover, the Stringprep Security Considerations [RFC3454] Section applies. See also the analysis in the subsections of Appendix B, below. 🔒💀

8. Acknowledgements 🫶

This document is the product of the PRECIS IETF Working Group, and participants in that working group were helpful in addressing issues with the text 💜

Specific contributions came from David Black, Alan DeKok, Simon Josefsson, Bill McQuillan, Alexey Melnikov, Peter Saint-Andre, Dave Thaler, and Yoshiro Yoneya 🎀

Dave Thaler provided the "buckets" insight in Section 5.1.1, central to the organization of the problem. 🌈👑

Evaluations of Stringprep profiles that are included in Appendix B were done by David Black, Alexey Melnikov, Peter Saint-Andre, and Dave Thaler 🙌

9. Informative References ✨

okay bestie, this is the reference shelf 📚💖 these are the documents the spec points to for background, and I've kept every single one with all its details so nothing gets lost 🫶

  • [78PRECIS] Blanchet, M., "PRECIS Framework", Proceedings of IETF 78, July 2010, <http://www.ietf.org/proceedings/78/slides/precis-2.pdf>.
  • [ID-COMP] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", Work in Progress, March 2013.
  • [NEWPREP] "Newprep BoF Meeting Minutes", March 2010, <http://www.ietf.org/proceedings/77/minutes/newprep.txt>.
  • [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
  • [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
  • [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
  • [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
  • [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
  • [RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
  • [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
  • [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
  • [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, October 2004.
  • [RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based Management MIB", RFC 4011, March 2005.
  • [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
  • [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
  • [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
  • [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
  • [RFC4505] Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006.
  • [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
  • [RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
  • [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006.
  • [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
  • [RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer Protocol (NNTP) Extension for Authentication", RFC 4643, October 2006.
  • [RFC4683] Park, J., Lee, J., Lee, H., Park, S., and T. Polk, "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", RFC 4683, October 2006.
  • [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
  • [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
  • [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
  • [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism", RFC 5034, July 2007.
  • [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
  • [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, November 2007.
  • [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
  • [RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K. Shumard, "IAX: Inter-Asterisk eXchange Version 2", RFC 5456, February 2010.
  • [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, January 2010.
  • [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
  • [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", RFC 5804, July 2010.
  • [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
  • [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
  • [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
  • [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
  • [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
  • [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010.
  • [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
  • [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011.
  • [RFC6452] Faltstrom, P. and P. Hoffman, "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0", RFC 6452, November 2011.
  • [UAX15] "Unicode Standard Annex #15: Unicode Normalization Forms", UAX 15, September 2009.
  • [Unicode61] The Unicode Consortium. The Unicode Standard, Version 6.1.0, (Mountain View, CA: The Unicode Consortium, 2012. ISBN 978-1-936213-02-3). <http://www.unicode.org/versions/Unicode6.1.0/>.

Appendix A. Classification of Stringprep Profiles 💅

okay so this is where we look at how a bunch of real Stringprep users behave 🔍✨ a few known cases got evaluated while this doc was being written, and they're described two ways. first, the ID type column (pulled from Section 5.1.1) uses the short forms "a" for Absolute, "d" for Definite, and "i" for Indefinite 🧚. then there's a User? column, which has an "i" if the protocol string comes from user input, an "o" if it becomes user-facing output, "b" if both are true, and "n" if neither is true 🎀

Table 1 is the whole vibe, so here it is, untouched 🦋

                     +------+--------+-------+
                     |  RFC | IDtype | User? |
                     +------+--------+-------+
                     | 3722 |    a   |   b   |
                     | 3748 |    -   |   -   |
                     | 3920 |   a,d  |   b   |
                     | 4505 |    a   |   i   |
                     | 4314 |   a,d  |   b   |
                     | 4954 |   a,d  |   b   |
                     | 5034 |   a,d  |   b   |
                     | 5804 |   a,d  |   b   |
                     +------+--------+-------+

                              Table 1

Appendix B. Evaluation of Stringprep Profiles 🌸

this part is a summary of the evaluation of Stringprep profiles, done so we could really get a good understanding of how Stringprep gets used 🧠 just to be super clear, it is by no means normative, and it's not the actual evaluations themselves 🙈 a template was used so reviewers could give a coherent view of all the evaluations, which is honestly so organized of them 💖

more parts are coming, so keep your eyes peeled 👀🫶

B.1. iSCSI Stringprep Profile: RFC 3720, RFC 3721, RFC 3722 🎀

Description: Okay so an iSCSI session is basically an initiator (the host or server that uses storage) chatting with a target (the storage array or other system that provides the storage) 🧚. Both of them get named with iSCSI names, and this profile is what handles those names 💖.

How it is used: Initiators and targets (see above) 💅. They can also identify SCSI ports (these are software entities in the iSCSI protocol, not hardware ports 🙈) and iSCSI logical units (storage volumes), although both are kinda unusual in practice.

What entities create these identifiers? A human user (1) sets up an automated system (2) that generates the names. The setup has to be configured in advance because the names embed unique identifiers from the DNS or the IEEE 🌸.

How is the string input in the system? Keyboard and copy-paste are both common ⌨️. Copy-paste is the real MVP here because iSCSI names are long enough to be a nightmare for humans to remember, so people send them over email, sneaker-net, text files, etc. to avoid mistypes 😭.

Where do we place the dividing line between user interface and protocol? The iSCSI protocol requires that all internationalization string preparation happens in the user interface. The protocol treats iSCSI names as opaque identifiers that get compared byte-by-byte for equality 🦋. Names are generally not checked for correct formatting by the protocol either.

What entities enforce the rules? There are no iSCSI-specific enforcers, though the unique identifier info in the names relies on DNS registrars and the IEEE Registration Authority 👑.

Comparison: Byte-by-byte 🔍.

Case Folding, Sensitivity, Preservation: Case folding is required for the code blocks specified in RFC 3454, Table B.2. The overall iSCSI naming system (UI + protocol) is case-insensitive ✨.

What is the impact if the comparison results in a false positive? Potential access to the wrong storage 😱.

  • If the initiator has no access to the wrong storage, an authentication failure is the probable result.
  • If the initiator has access to the wrong storage, the resulting misidentification could mean using the wrong data and possible corruption of stored data 💀.

What is the impact if the comparison results in a false negative? Denial of authorized storage access 🥲.

What are the security impacts? iSCSI names may be used as the authentication identities for storage systems. Comparison problems could cause authentication problems, although authentication failure softens some of the false positive cases 🔐.

Normalization: NFKC, as specified by RFC 3454.

Mapping: Yes, as specified by Table B.1 in RFC 3454.

Disallowed Characters: Only the following characters are allowed:

  • ASCII dash, dot, colon
  • ASCII lowercase letters and digits
  • Unicode lowercase characters as specified by RFC 3454.

All other characters are disallowed 🚫.

Which other strings or identifiers are these most similar to? None -- iSCSI names are unique to iSCSI 🌈.

Are these strings or identifiers sometimes the same as strings or identifiers from other protocols? No.

Does the identifier have internal structure that needs to be respected? Yes! ASCII dot, dash, and colon are used for the internal name structure. They aren't reserved characters, though, since they can show up in the name outside of their structural spots (e.g., only the first colon is structural, the others aren't) 🧩.

How are users exposed to these strings? How are they published? iSCSI names show up in server and storage system configuration interfaces. They also appear in system logs 📜.

Is the string / identifier used as input to other operations? Effectively, no. The rarely used port and logical unit names involve concatenation, which effectively extends a unique iSCSI name for a target so it can uniquely identify something within that target.

How much tolerance for change from existing Stringprep approach? Good tolerance! The community would prefer that internationalization experts solve internationalization problems 🌍.

How strong a desire for change (e.g., for Unicode agility)? Unicode agility is desired, in principle, as long as nothing significant breaks 🔥.

B.2. SMTP/POP3/ManageSieve Stringprep Profiles: RFC 4954, RFC 5034, RFC 5804 💌

Description: This is the authorization identity (user identifier) that gets exchanged during SASL authentication, via the AUTH (SMTP/POP3) or AUTHENTICATE (ManageSieve) command 🎟️.

How It's Used: It's used for proxy authorization, e.g., to [lawfully] impersonate a particular user after a privileged authentication 🕵️‍♀️.

Who Generates It:

  • Typically generated by email system administrators using some tools/conventions, sometimes from some backend database.
  • In some setups, human users can register their own usernames (e.g., webmail self-registration) 🙋‍♀️.

User Input Methods:

  • typing or selecting from a list
  • copy and paste
  • voice input
  • in configuration files or on the command line

Enforcement: Rules get enforced by the server / add-on service (e.g., gateway service) when the account is registered 🛡️.

Comparison Method: "Type 1" (byte-for-byte) or "Type 2" (compare by a common algorithm that everyone agrees on (e.g., normalize and then compare the result byte-by-byte) 🧮.

Case Folding, Sensitivity, Preservation: Most likely case-sensitive. The exact requirements on case-sensitivity and case-preservation depend on the specific implementation. For example, an implementation might treat all user identifiers as case-insensitive (or case-insensitive for the US-ASCII subset only) 🔤.

Impact of Comparison: False positives mean an unauthorized user gets email service access (login) 🚨. False negatives mean an authorized user is denied email service access 😢.

Normalization: NFKC (as per RFC 4013).

Mapping: (see Section 2 of RFC 4013 for the full list) Non-ASCII spaces are mapped to space, etc.

Disallowed Characters: (see Section 2 of RFC 4013 for the full list) Unicode Control characters, etc.

String Classes: Simple username. See Section 2 of RFC 4013 for details on the restrictions. Some implementations allow spaces in these, so watch out 👀. While implementations are not required to use a specific format, an authorization identity frequently has the same format as an email address (and Email Address Internationalization (EAI) email address in the future), or as the left hand side of an email address. Note: whatever is recommended for SMTP/POP/ManageSieve authorization identity should also be used for IMAP authorization identities, as IMAP/POP3/SMTP/ManageSieve are frequently implemented together 🤝.

Internal Structure: None.

User Output: Unlikely, but possible, for example if it's the same as an email address 📧.

Operations: Sometimes concatenated with other data and then used as input to a cryptographic hash function 🔐.

How much tolerance for change from existing Stringprep approach? Not sure 🤷‍♀️.

Background Information:

In RFC 5034, when describing the POP3 AUTH command:

   The authorization identity generated by the SASL exchange is a
   simple username, and SHOULD use the SASLprep profile (see
   [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to
   prepare these names for matching.  If preparation of the
   authorization identity fails or results in an empty string
   (unless it was transmitted as the empty string), the server
   MUST fail the authentication.

In RFC 4954, when describing the SMTP AUTH command:

   The authorization identity generated by this [SASL] exchange is
   a "simple username" (in the sense defined in [SASLprep]), and
   both client and server SHOULD (*) use the [SASLprep] profile of
   the [StringPrep] algorithm to prepare these names for
   transmission or comparison.  If preparation of the
   authorization identity fails or results in an empty string
   (unless it was transmitted as the empty string), the server
   MUST fail the authentication.

   (*) Note: Future revision of this specification may change this
   requirement to MUST.  Currently, the SHOULD is used in order to
   avoid breaking the majority of existing implementations.

In RFC 5804, when describing the ManageSieve AUTHENTICATE command:

   The authorization identity generated by this [SASL] exchange is
   a "simple username" (in the sense defined in [SASLprep]), and
   both client and server MUST use the [SASLprep] profile of the
   [StringPrep] algorithm to prepare these names for transmission
   or comparison.  If preparation of the authorization identity
   fails or results in an empty string (unless it was transmitted
   as the empty string), the server MUST fail the authentication.

B.3. IMAP Stringprep Profiles for Usernames: RFC 4314, RFC 5738 🎀

Evaluation Note: okay so these docs have 2 types of strings (usernames and passwords), which is why there are two separate templates 💖

Description: this is the "username" parameter for the IMAP LOGIN command, plus identifiers in IMAP Access Control List (ACL) commands. Any valid username is also an IMAP ACL identifier, but ACL identifiers can include other stuff too, like the name of a group of users 👯‍♀️

How It's Used: used for authentication (Usernames), or in IMAP Access Control Lists (Usernames or Group names) 🔐

Who Generates It:

  • Usually made by email system administrators using some tools and conventions, sometimes pulled from a backend database 🛠️
  • In some setups, human users can register their own usernames (like webmail self-registration) 🌸

User Input Methods:

  • typing or selecting from a list
  • copy and paste
  • voice input
  • in configuration files or on the command line

Enforcement: the rules get enforced by the server or an add-on service (like a gateway service) when the account is registered 🚪

Comparison Method: either "Type 1" (byte-for-byte) or "Type 2" (compare by a common algorithm that everyone agrees on, e.g., normalize and then compare the result byte-by-byte) 🦋

Case Folding, Sensitivity, Preservation: most likely case-sensitive 🙈. The exact rules depend on the specific implementation. For example, one implementation might treat all user identifiers as case-insensitive, or case-insensitive for the US-ASCII subset only.

Impact of Comparison: okay, this part is serious 💀

  • False positives: an unauthorized user gets IMAP access (login), or privileges get granted when they shouldn't (like access to a specific mailbox, or the ability to manage ACLs for a mailbox).
  • False negatives: an authorized user gets denied IMAP access, or can't use privileges they were actually granted (like access to a specific mailbox, or the ability to manage ACLs for a mailbox).

Normalization: NFKC (as per RFC 4013) ✨

Mapping: (see Section 2 of RFC 4013 for the full list) Non-ASCII spaces get mapped to space 🌈

Disallowed Characters: (see Section 2 of RFC 4013 for the full list) Unicode Control characters, etc. 🚫

String Classes: simple username. See Section 2 of RFC 4013 for the restrictions. Some implementations allow spaces in these, so watch out 👀. IMAP implementations aren't required to use a specific format, but an IMAP username often looks like an email address (and an EAI email address in the future), or like the left-hand side of an email address 💌. Also, whatever gets recommended for the IMAP username should be used for ManageSieve, POP3 and SMTP authorization identities too, since IMAP, POP3, SMTP and ManageSieve are frequently implemented together 🧚

Internal Structure: none 🫧

User Output: unlikely, but possible. For example, if the username is the same as an email address, it can show up in access control lists (like in the IMAP ACL extension), both when managing membership and when listing membership of existing access control lists. It often shows up as mailbox names under the Other Users IMAP namespace 📬

Operations: sometimes concatenated with other data and then used as input to a cryptographic hash function 🔑

How much tolerance for change from existing Stringprep approach? Not sure 🤷‍♀️. Non-ASCII IMAP usernames are currently prohibited by IMAP (RFC 3501). However, they're allowed when used in the IMAP ACL extension 🥹

B.4. IMAP Stringprep Profiles for Passwords: RFC 5738 🔒

Description: this is the "Password" parameter for the IMAP LOGIN command 🗝️

How It's Used: used for authentication (Passwords) 🔐

Who Generates It: either generated by email system administrators using some tools and conventions, or chosen by the human user 🙋‍♀️

User Input Methods:

  • typing or selecting from a list
  • copy and paste
  • voice input
  • in configuration files or on the command line

Enforcement: the rules get enforced by the server or an add-on service (like a gateway service or backend database) when the account is registered 🚪

Comparison Method: "Type 1" (byte-for-byte) 🦋

Case Folding, Sensitivity, Preservation: most likely case-sensitive 🙈

Impact of Comparison: okay, the stakes are high here too 😭

  • False positives: an unauthorized user gets IMAP access (login).
  • False negatives: an authorized user gets denied IMAP access.

Normalization: NFKC (as per RFC 4013) ✨

Mapping: (see Section 2 of RFC 4013 for the full list) Non-ASCII spaces get mapped to space 🌈

Disallowed Characters: (see Section 2 of RFC 4013 for the full list) Unicode Control characters, etc. 🚫

String Classes: currently defined as "simple username" (see Section 2 of RFC 4013 for the restrictions). This is likely to be a different class from usernames though, so don't mix them up 🙅‍♀️. Some implementations allow spaces in these. Passwords should be treated the same way across all email related protocols. The same passwords are frequently shared with web, IM, and etc. applications, which is why this matters so much 💅

Internal Structure: none 🫧

User Output: possible in the text of email messages (e.g., in "you forgot your password" emails), on a web page or directory, or side of the bus / in ads. Yes, really 💀

Operations: sometimes concatenated with other data and then used as input to a cryptographic hash function. Frequently stored as is, or hashed 🔑

How much tolerance for change from existing Stringprep approach? Not sure 🤷‍♀️. Non-ASCII IMAP passwords are currently prohibited by IMAP (RFC 3501). However, they're likely to be in widespread use already 👀

Background Information:

Here's what RFC 5738 says in its Section 5 ("UTF8=USER Capability"), word for word:

If the "UTF8=USER" capability is advertised, that indicates the
server accepts UTF-8 user names and passwords and applies
SASLprep [RFC4013] to both arguments of the LOGIN command.  The
server MUST reject UTF-8 that fails to comply with the formal
syntax in RFC 3629 [RFC3629] or if it encounters Unicode
characters listed in Section 2.3 of SASLprep RFC 4013
[RFC4013].

And here's RFC 4314's Section 3 ("Access control management commands and responses"), also verbatim:

Servers, when processing a command that has an identifier as a
parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS
commands), SHOULD first prepare the received identifier using
"SASLprep" profile [SASLprep] of the "stringprep" algorithm
[Stringprep].  If the preparation of the identifier fails or
results in an empty string, the server MUST refuse to perform
the command with a BAD response.  Note that Section 6
recommends additional identifier's verification steps.

Last one! RFC 4314's Section 6 ("Security Considerations") 🚨, verbatim:

This document relies on [SASLprep] to describe steps required
to perform identifier canonicalization (preparation).  The
preparation algorithm in SASLprep was specifically designed
such that its output is canonical, and it is well-formed.
However, due to an anomaly [PR29] in the specification of
Unicode normalization, canonical equivalence is not guaranteed
for a select few character sequences.  Identifiers prepared
with SASLprep can be stored and returned by an ACL server.  The
anomaly affects ACL manipulation and evaluation of identifiers
containing the selected character sequences.  These sequences,
however, do not appear in well-formed text.  In order to
address this problem, an ACL server MAY reject identifiers
containing sequences described in [PR29] by sending the tagged
BAD response.  This is in addition to the requirement to reject
identifiers that fail SASLprep preparation as described in
Section 3.

So the takeaway: an ACL server MAY reject those sequences, but it's still on top of the rule to reject identifiers that fail SASLprep. Pretty iconic of the security section to have a whole plot twist in it 🥀✨

B.5. Anonymous SASL Stringprep Profiles: RFC 4505 🦋

Description: RFC 4505 defines a "trace" field:

Comparison: Not for comparing, bestie. This field is not intended for comparison and is only used for logging 📝

Case folding; case-sensitivity, preserve case: No case folding. It's case-sensitive 💅

Do users input the strings directly? Yes! They might type it into configuration UIs or on a command line, and it can also be stored in configuration files. Clients can generate the value automatically too, like with a fixed string or a user's email address ✨

How users input strings? Keyboard or voice, a stylus (picking from a list), and maybe copy-paste 🖊️

Normalization: None.

Disallowed Characters: Control characters are disallowed. (See Section 3 of RFC 4505.) 🚫

Which other strings or identifiers are these most similar to? RFC 4505 says the trace "should take one of two forms: an Internet email address, or an opaque string that does not contain the '@' (U+0040) character and that can be interpreted by the system administrator of the client's domain". In practice, though, it's free-form text, so it's a totally different class from "email address" or "username" 🌈

Are these strings or identifiers sometimes the same as strings or identifiers from other protocols (e.g., does an IM system sometimes use the same credentials database for authentication as an email system)? Yes, see above. However, there's no strong need to keep them consistent in the future 🫶

How are users exposed to these strings, how are they published? Not really. The value can still be seen in server logs though 👀

Impacts of false positives and false negatives:

  • False positive: a user can be confused with another user. 😬
  • False negative: two distinct users are treated as the same user. 🙈

But note that the trace field is not authenticated, so it can be easily falsified. Lowkey a big deal! 🚨

Tolerance of changes in the community: The community would be flexible 🦋

Delimiters: No internal structure, but see the comments above about frequent use of email addresses 💌

Background Information:

RFC 4505, Section 2 ("The Anonymous Mechanism"): okay so the mechanism is just a single message from the client to the server. The client can include trace information as a string of [UTF-8]-encoded [Unicode] characters, prepared according to [StringPrep] and the "trace" stringprep profile in Section 3 of that document. The trace info has no semantic value and "should take one of two forms": an Internet email address, or an opaque string with no '@' (U+0040) character, which the system administrator of the client's domain can interpret. For privacy reasons, an Internet email address or other information identifying the user should only be used with the user's permission. Respect the privacy, periodt 🫶

RFC 4505, Section 3 ('The "trace" Profile of "Stringprep"'): this section defines the "trace" profile of [StringPrep]. It's built for the SASL ANONYMOUS Mechanism, and the client prepares the <message> production using this profile 🎀

  • The character repertoire is Unicode 3.2 [Unicode].
  • No mapping is required.
  • No Unicode normalization is required.
  • The unassigned code points list is the one in Appendix A of [StringPrep]. Unassigned code points are not prohibited.
  • These tables of [StringPrep] are prohibited:
    • C.2.1 (ASCII control characters)
    • C.2.2 (Non-ASCII control characters)
    • C.3 (Private use characters)
    • C.4 (Non-character code points)
    • C.5 (Surrogate codes)
    • C.6 (Inappropriate for plain text)
    • C.8 (Change display properties are deprecated)
    • C.9 (Tagging characters)

No additional characters are prohibited. This profile also requires bidirectional character checking per Section 6 of [StringPrep]. Very thorough, very iconic 💅✨

B.6. XMPP Stringprep Profiles for Nodeprep: RFC 3920 🌸

Description: Localpart of a JabberID ("JID"), as in localpart@domainpart/resourcepart 🧚

How It's Used:

  • Usernames (e.g., stpeter@jabber.org)
  • Chatroom names (e.g., precis@jabber.ietf.org)
  • Publish-subscribe nodes
  • Bot names 🤖

Who Generates It:

  • Typically, end users via an XMPP client
  • Sometimes created in an automated fashion

User Input Methods:

  • typing
  • copy and paste
  • voice input
  • clicking a URI/IRI

Enforcement: Rules are enforced by the server or an add-on service (e.g., a chatroom service) when an account is registered, a room is created, and so on 🔐

Comparison Method: "Type 2" (common algorithm) 💜

Case Folding, Sensitivity, Preservation:

  • Strings are always folded to lowercase
  • Case is not preserved

Impact of Comparison:

False positives:

  • unable to authenticate at server (or authenticate to the wrong account) 😱
  • add the wrong person to your buddy list
  • join the wrong chatroom
  • improperly grant privileges (e.g., chatroom admin)
  • subscribe to the wrong pubsub node
  • interact with the wrong bot
  • allow communication with a blocked entity 🚫

False negatives:

  • unable to authenticate
  • unable to add someone to your buddy list
  • unable to join the chatroom you want
  • unable to use granted privileges (e.g., chatroom admin)
  • unable to subscribe to the pubsub node you want
  • unable to interact with the bot you want
  • disallow communication with an unblocked entity 💔

Normalization: NFKC

Mapping: Spaces are mapped to nothing 🫧

Disallowed Characters: ,&,',/,:,<,>,@

String Classes:

  • Often similar to a generic username
  • Often similar to the localpart of an email address
  • Sometimes the same as the localpart of an email address

Internal Structure: None

User Output:

  • vCard
  • email signature
  • web page / directory
  • text of a message (e.g., in a chatroom) 💬

Operations: Sometimes concatenated with other data and then used as input to a cryptographic hash function 🔒

B.7. XMPP Stringprep Profiles for Resourceprep: RFC 3920 🎀

Description:

  • Resourcepart of a JabberID ("JID"), as in localpart@domainpart/resourcepart
  • Typically free-form text 📝

How It's Used:

  • Device or session names (e.g., stpeter@jabber.org/Home)
  • Nicknames (e.g., precis@jabber.ietf.org/StPeter) 🌈

Who Generates It:

  • Often human users via an XMPP client
  • Often generated automatically by a client or server

User Input Methods:

  • typing
  • copy and paste
  • voice input
  • clicking a URI/IRI

Enforcement: Rules are enforced by the server or an add-on service (e.g., a chatroom service) when someone logs in, joins a chatroom, and so on 🚪

Comparison Method: "Type 2" (byte-for-byte) 🔍

Case Folding, Sensitivity, Preservation:

  • Strings are never folded
  • Case is preserved 🍓

Impact of Comparison:

False positives:

  • interact with the wrong device (e.g., for a file transfer or voice call)
  • interact with the wrong chatroom participant
  • improperly grant privileges (e.g., chatroom moderator)
  • allow communication with a blocked entity 😬

False negatives:

  • unable to choose the chatroom nickname you want
  • unable to use granted privileges (e.g., chatroom moderator)
  • disallow communication with an unblocked entity 🥺

Normalization: NFKC

Mapping: Spaces are mapped to nothing

Disallowed Characters: None 🙌

String Classes: Basically a free-form identifier

Internal Structure: None

User Output:

  • text of a message (e.g., in a chatroom)
  • device names are often not exposed to human users 🙈

Operations: Sometimes concatenated with other data and then used as input to a cryptographic hash function 🔐

B.8. EAP Stringprep Profiles: RFC 3748 🌙

Description: Okay, so RFC 3748, Section 5, references Stringprep, but the WG didn't agree with that text (the IESG added it), and there are no known implementations that use Stringprep. The main problem is that using strings is a per-method concept, not a generic EAP concept. So RFC 3748 itself doesn't really use Stringprep, but individual EAP methods could. That means most of the template answers are not applicable, though a few answers are universal across methods. The list of IANA-registered EAP methods is at <http://www.iana.org/assignments/eap-numbers/eap-numbers.xml> 🗂️

Comparison Methods: n/a (per-method)

Case Folding, Case-Sensitivity, Case Preservation: n/a (per-method)

Impact of comparison: A false positive results in unauthorized network access (and possibly theft of service if someone else gets billed). A false negative results in a lack of authorized network access, so no connectivity. Yikes 😭

User input: n/a (per-method)

Normalization: n/a (per-method)

Mapping: n/a (per-method)

Disallowed characters: n/a (per-method)

String classes: Although some EAP methods may use a syntax similar to other types of identifiers, EAP mandates that the actual values must not be assumed to be identifiers usable with anything else. Don't assume, bestie! 🚫

Internal structure: n/a (per-method)

User output: Identifiers are never displayed to humans, except perhaps as a human typed them 💭

Operations: n/a (per-method)

Community considerations: There's no resistance to change for the base EAP protocol (like we said, the WG didn't want that text). However, actual use of Stringprep within specific EAP methods, if any, may face resistance. It's currently unknown whether any EAP methods use Stringprep 🤷‍♀️

Authors' Addresses 🌸

Marc Blanchet
Viagenie
246 Aberdeen
Quebec, QC  G1R 2E1
Canada

EMail: Marc.Blanchet@viagenie.ca
URI:   http://viagenie.ca


Andrew Sullivan
Dyn, Inc.
150 Dow St
Manchester, NH  03101
U.S.A.

EMail: asullivan@dyn.com
📦 where this page comes from