RFC 7542
The Network Access Identifier
RFC 7542: The Network Access Identifier 💖 (Part 1 of 6)
okay bestie, let's get into this one 🎀 It's from the IETF, written by A. DeKok at FreeRADIUS, and it's a Standards Track doc, so it's the real deal, no cap 💅 It's dated May 2015, its ISSN is 2070-1721 🦋, and it obsoletes RFC 4282 (so 4282 is officially retired, bye 👋). It doesn't list any updates.
Abstract 🦋
okay so, to do inter-domain authentication services properly, domains need a standardized way to identify each other's users ✨ This doc defines the syntax for the Network Access Identifier (NAI), which is the user identifier the client submits before it gets access to resources 🔑 This is a revised version of RFC 4282, and it fixes issues with international character sets plus a bunch of other corrections to 4282 🌍 it's giving glow-up energy fr
Status of This Memo 📜
this is an Internet Standards Track document 🌟
this document is a product of the Internet Engineering Task Force (IETF) 🫶 it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✅ if you want more on Internet Standards, check out Section 2 of RFC 5741 📚
for info on the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7542 🔗
Copyright Notice ©️
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. please review these docs carefully, because they describe your rights and restrictions with respect to 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're provided without warranty as described in the Simplified BSD License ⚖️
this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. without getting an adequate license from the person(s) controlling the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English 🌈
Table of Contents 🗂️
1. Introduction ....................................................4
1.1. Terminology ................................................6
1.2. Requirements Language ......................................7
1.3. Purpose ....................................................7
1.4. Motivation .................................................9
2. NAI Definition .................................................10
2.1. UTF-8 Syntax and Normalization ............................10
2.2. Formal Syntax .............................................11
2.3. NAI Length Considerations .................................11
2.4. Support for Username Privacy ..............................12
2.5. International Character Sets ..............................13
2.6. The Normalization Process .................................14
2.6.1. Issues with the Normalization Process ..............15
2.7. Use in Other Protocols ....................................16
2.8. Using the NAI Format for Other Identifiers ................17
3. Routing inside of AAA Systems ..................................18
3.1. Compatibility with Email Usernames ........................19
3.2. Compatibility with DNS ....................................20
3.3. Realm Construction ........................................20
3.3.1. Historical Practices ...............................21
3.4. Examples ..................................................22
4. Security Considerations ........................................23
4.1. Correlation of Identities over Time and Protocols .........23
4.2. Multiple Identifiers ......................................24
5. Administration of Names ........................................25
6. References .....................................................26
6.1. Normative References ......................................26
6.2. Informative References ....................................26
Appendix A. Changes from RFC 4282 .................................29
Acknowledgments ...................................................30
Author's Address ..................................................301. Introduction 🌸
okay so there's a LOT of interest in a set of features that fall under inter-domain authentication, aka "roaming capability" for network access 🧚 that covers dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications, and it's giving main character energy ✨
by "inter-domain authentication", this doc means situations where a user has authentication credentials at one "home" domain but can present them at a second "visited" domain to get access to certain services there 🏠➡️🌍 the two domains usually have a pre-existing relationship, so the credentials can be passed from the visited domain to the home domain for verification 🤝 the home domain typically sends back a permit/deny response, which might also include authorization parameters that the visited domain is expected to enforce on the user 👑
so the "roaming" scenario is basically a user visiting, or "roaming" to, a non-home domain and asking to use services at that visited domain 🦋
these are some of the folks who are interested:
- Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to team up with other regional providers to offer dialup service over a wider area 🗺️
- Telecommunications companies who want to combine their operations with those of one or more companies in other areas or nations, so they can offer more comprehensive network access service in places where there's no native service (e.g., in another country) 🌏
- Wireless LAN hotspots providing service to one or more ISPs 📶
- Businesses that want to offer their employees a comprehensive package of dialup services on a global basis 💼 those services may include Internet access as well as secure access to corporate intranets via a VPN, enabled by tunneling protocols such as the Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301] 🔐
- Other protocols that are interested in leveraging the users' credentials to take advantage of an existing authentication framework 🧩
to make these services play nicely together, we need a standardized method for identifying users 🫶 this doc defines the syntax for the Network Access Identifier (NAI) 📛 examples of implementations that use the NAI, plus descriptions of what it means, can be found in [RFC2194] 📚
when the NAI was defined for network access, it had the side effect of defining an identifier that could be used in non-AAA systems 🎀 some non-AAA systems defined identifiers that were compatible with the NAI, and deployments used the NAI too 🙌 this made credential management simpler, because the same credential could be reused in multiple situations 🔁 protocols that reuse the same credential or the same identifier format can benefit from that simplicity 💖 the alternative is protocol-specific credentials or identifier formats, which raises costs for both the user and the administrator 😩
heads up: using one identifier across multiple protocols has privacy implications 👀 see Sections 2.7 and 4 for more on this topic.
the goal of this doc is to define the format of an identifier that can be used in many protocols 🦋 a protocol may transport an encoded version of the NAI (e.g., '.' as %2E), but the definition of the NAI is protocol independent 🌈 the goal is to encourage widespread adoption of the NAI format, which will cut down the work needed to leverage identification and authentication in other protocols, and reduce the complexity of non-AAA systems for end users and administrators 🧚♀️
this document only suggests that the NAI format be used; it does not require such use 🌸 many protocols already define their own identifier formats, and some of those are incompatible with the NAI, while others allow the NAI in addition to non-NAI identifiers 🫶 the definition of the NAI in this document has no requirements on protocol specifications, implementations, or deployments ✨
however, this doc suggests that using one standard identifier format is preferable to using multiple incompatible identifier formats 💅 where identifiers need to be used in new protocols and/or specifications, it is RECOMMENDED that the format of the NAI be used 🔥 in other words, the interpretation of the identifier is context specific, while the format of the identifier stays the same 🎀 these issues are discussed in more detail in Section 2.8, below 👀
the recommendation for a standard identifier format is not a recommendation that each user have one universal identifier 🙈 this doc actually allows for the use of multiple identifiers, and it recommends using anonymous identifiers wherever those identifiers are publicly visible 🦋
this document is a revised version of [RFC4282], which originally defined internationalized NAIs 🌍 the differences and enhancements compared to that document are listed in Appendix A 💜 more parts are coming, so stay tuned bestie 👀✨
1.1. Terminology ✨
okay so this doc keeps using a few terms over and over, so let's get them locked in first 💅
"Local" or "Localized" Text 🌸
"Local" or "localized" text is text that is in either non-UTF-8 or non-normalized form. The character set, encoding, and locale are (in general) unknown to Authentication, Authorization, and Accounting (AAA) network protocols. The client that "knows" the locale may have a different concept of this text than other AAA entities, which do not know the same locale.
ngl this is giving "only the client knows what the text really means and everyone else is just guessing" 😭
Network Access Identifier 🦋
The Network Access Identifier (NAI) is a common format for user identifiers submitted by a client during authentication. The purpose of the NAI is to allow a user to be associated with an account name, as well as to assist in the routing of the authentication request across multiple domains. Please note that the NAI may not necessarily be the same as the user's email address or the user identifier submitted in an application-layer authentication.
bestie, the NAI is NOT automatically your email 🙈 it's its own thing that helps with account names and routing requests across domains
Network Access Server 🧚
The Network Access Server (NAS) is the device that clients connect to in order to get access to the network. In PPTP terminology, this is referred to as the PPTP Access Concentrator (PAC), and in L2TP terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point.
so the NAS is basically the front door 🚪 and it goes by a different name depending on which protocol family you're talking about. PAC for PPTP, LAC for L2TP, Access Point for 802.11. iconic naming 💜
Roaming Capability 🌈
Roaming capability can be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support.
roaming is giving "use lots of ISPs but only have a contract with one" and yes that's the whole main character energy of it ✨
Normalization or Canonicalization 🍓
These terms are defined in Section 4 of [RFC6365]; those definitions are incorporated here by reference.
so these two words have their meaning spelled out in Section 4 of [RFC6365], and this doc just borrows that definition 🫶
Locale 🌸
This term is defined in [RFC6365], Section 8; that definition is incorporated here by reference.
same vibe as above, the definition of locale lives in [RFC6365] Section 8, and we're just reusing it here 💅
Tunneling Service 🎀
A tunneling service is any network service enabled by tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One example of a tunneling service is secure access to corporate intranets via a Virtual Private Network (VPN).
so a tunneling service is any service that runs on top of tunnels like PPTP, L2F, L2TP, or IPsec tunnel mode 🦋 the classic example is a VPN that gets you into corporate intranets
1.2. Requirements Language 💖
okay the key words are the important little guys here. they're interpreted exactly the way [RFC2119] describes, so please don't freestyle them 🙏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.3. Purpose 🧚♀️
okay here's the vibe of why this doc exists ✨
As described in [RFC2194], there are a number of providers offering network access services, and essentially all Internet Service Providers are involved in roaming consortia.
so basically every ISP is in a roaming group, which is kind of the whole point 💅
In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server. For use in roaming, this function is accomplished via the Network Access Identifier (NAI) submitted by the user to the NAS in the initial network authentication. It is also expected that NASes will use the NAI as part of the process of opening a new tunnel, in order to determine the tunnel endpoint.
to offer roaming you have to figure out the user's home auth server, and the NAI is how that happens. the user sends it to the NAS during the first auth, and NASes also use it to figure out where a new tunnel should end 🦋
This document suggests that other protocols can take advantage of the NAI format. Many protocols include authentication capabilities, including defining their own identifier formats. These identifiers can then end up being transported in AAA protocols, so that the originating protocols can leverage AAA for user authentication. There is therefore a need for a definition of a user identifier that can be used in multiple protocols.
this doc is basically going "hey other protocols, you can totally use the NAI format too" 🌈 lots of protocols have their own IDs, those IDs can end up riding along in AAA, so we need one identifier that works everywhere
While the NAI is defined herein, it should be noted that existing protocols and deployments do not always use it. AAA systems MUST therefore be able to handle user identifiers that are not in the NAI format. The process by which that is done is outside of the scope of this document.
ok real talk, not everyone uses NAI yet, so AAA systems MUST still handle identifiers that aren't NAIs 💀 how they do it is out of scope for this doc
Non-AAA systems can accept user identifiers in forms other than the NAI. This specification does not forbid that practice. It only codifies the format and interpretation of the NAI. This document cannot change existing protocols or practices. It can, however, suggest that using a consistent form for a user identifier is of benefit to the community.
non-AAA systems can take other ID forms and this doc isn't banning that 🙅♀️ it just nails down what NAI looks like. the doc can't change existing stuff, but it can totally hype up using one consistent format 🫶
This document does not make any protocol-specific definitions for an identifier format, and it does not make changes to any existing protocol. Instead, it defines a protocol-independent form for the NAI. It is hoped that the NAI is a user identifier that can be used in multiple protocols.
no protocol-specific stuff here, no edits to existing protocols either 🌸 it's a protocol-independent NAI, and the hope is that it works across lots of protocols
Using a common identifier format simplifies protocols requiring authentication, as they no longer need to specify a protocol-specific format for user identifiers. It increases security, as multiple identifier formats allow attackers to make contradictory claims without being detected (see Section 4.2 for further discussion of this topic). It simplifies deployments, as a user can have one identifier in multiple contexts, which allows them to be uniquely identified, so long as that identifier is itself protected against unauthorized access.
a common format is so much easier for protocols that need auth, since they don't need their own special ID format 😭 it also helps security, because if you have a bunch of formats, attackers can make contradictory claims and slip past unnoticed (more on that in Section 4.2 👀). and users get one ID across contexts, which is great as long as that ID is locked down tight 🔐
In short, having a standard is better than having no standard at all.
in short, a standard is better than no standard. no cap 💖
1.4. Motivation 🌷
the detailed list of what changed from [RFC4282] lives in Appendix A, but there's some extra tea worth spilling first 🫖
The motivation to revise [RFC4282] began with internationalization concerns raised in the context of [EDUROAM]. Section 2.1 of [RFC4282] defines ABNF for realms and limits the realm grammar to English letters, digits, and the hyphen "-" character. The intent appears to have been to encode, compare, and transport realms with the Punycode [RFC3492] encoding form as described in [RFC5891]. There are a number of problems with this approach:
- The [RFC4282] ABNF is not aligned with internationalization of DNS.
- The requirement in Section 2.1 of [RFC4282] that realms are ASCII conflicts with the Extensible Authentication Protocol (EAP) as defined in [RFC3748], and RADIUS, which are both 8-bit clean, and which both recommend the use of UTF-8 for identifiers.
- Section 2.4 of [RFC4282] required mappings that are language specific and that are nearly impossible for intermediate nodes to perform correctly without information about that language.
- Section 2.4 of [RFC4282] requires normalization of usernames, which may conflict with local system or administrative requirements.
- The recommendations in Section 2.4 of [RFC4282] for treatment of bidirectional characters have proven to be unworkable.
- The prohibition of the use of unassigned code points in Section 2.4 of [RFC4282] effectively prohibits support for new scripts.
- No Authentication, Authorization, and Accounting (AAA) client, proxy, or server has implemented any of the requirements in Section 2.4 of [RFC4282], among other sections.
so the old NAI rules from [RFC4282] had a bunch of problems 🙈
- the ABNF doesn't line up with internationalized DNS 🌍
- it says realms must be ASCII, but EAP and RADIUS are 8-bit clean and both recommend UTF-8, so they clash 💀
- the language-specific mappings are basically impossible for middle nodes to get right without knowing the language 😵
- forced username normalization can fight with local system or admin rules 🙅♀️
- the bidi character advice has been proven unworkable 🫠
- banning unassigned code points means no support for new scripts, which is just sad 💔
- no AAA client, proxy, or server has actually implemented the Section 2.4 stuff, among other sections 😭
With international roaming growing in popularity, it is important for these issues to be corrected in order to provide robust and interoperable network services.
international roaming is blowing up, so these issues NEED fixing if we want robust, interoperable services 🔥
Furthermore, this document was motivated by a desire to codify existing practice related to the use of the NAI format and to encourage widespread use of the format.
and on top of that, this doc wants to write down what people are already doing with NAI and get everyone using the format more 🫶
2. NAI Definition 👑
2.1. UTF-8 Syntax and Normalization 💅
UTF-8 characters can be defined in terms of octets using the following ABNF [RFC5234], taken from [RFC3629]:
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail /
%xE1-EC 2( UTF8-tail ) /
%xED %x80-9F UTF8-tail /
%xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
%xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BFthese grammar bits are normatively defined in [RFC3629], but they got copied into this doc for convenience 🎀
See [RFC5198] and Section 2.6 of this specification for a discussion of normalization. Strings that are not Normal Form Composed (NFC) are not valid NAIs and SHOULD NOT be treated as such. Implementations that expect to receive an NAI but that instead receive non-normalized (but otherwise valid) UTF-8 strings instead SHOULD attempt to create a local version of the NAI, which is normalized from the input identifier. This local version can then be used for local processing. This local version of the identifier MUST NOT be used outside of the local context.
for normalization, check out [RFC5198] and Section 2.6 of this spec 🧐 strings that aren't NFC are not valid NAIs, so you SHOULD NOT treat them like they are 🙅♀️ if you get non-normalized UTF-8 but it's otherwise valid, you SHOULD make a local normalized copy for your own processing. and that local copy MUST NOT leave the local context, no exceptions bestie 🔒
Where protocols carry identifiers that are expected to be transported over a AAA protocol, it is RECOMMENDED that the identifiers be in NAI format. Where the identifiers are not in the NAI format, it is up to the AAA systems to discover this and to process them. This document does not suggest how that is done. However, existing practice indicates that it is possible.
if a protocol is sending IDs through AAA, it is RECOMMENDED that they be NAIs 💖 if they aren't, the AAA systems have to figure that out and deal with it themselves. this doc won't tell you how, but people are already doing it, so it's doable ✨
As internationalized domain names become more widely used, existing practices are likely to become inadequate. This document therefore defines the NAI, which is a user identifier format that can correctly deal with internationalized identifiers.
as internationalized domain names get more popular, the old ways are gonna be inadequate 😤 so this doc defines an NAI that can actually handle internationalized IDs properly 🌈
2.2. Formal Syntax 🦋
The grammar for the NAI is given below, described in Augmented Backus-Naur Form (ABNF) as documented in [RFC5234].
nai = utf8-username
nai =/ "@" utf8-realm
nai =/ utf8-username "@" utf8-realm
utf8-username = dot-string
dot-string = string *("." string)
string = 1*utf8-atext
utf8-atext = ALPHA / DIGIT /
"!" / "#" /
"$" / "%" /
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~" /
UTF8-xtra-char
utf8-realm = 1*( label "." ) label
label = utf8-rtext *(ldh-str)
ldh-str = *( utf8-rtext / "-" ) utf8-rtext
utf8-rtext = ALPHA / DIGIT / UTF8-xtra-charhere's the official grammar for the NAI, written in ABNF as described in [RFC5234] 💜 the username part is made of dot-separated strings, the realm part is labels separated by dots, and the whole NAI can be just a username, just a realm with an @ in front, or username@realm 🫶
2.3. NAI Length Considerations 🎀
okay bestie, let's talk about how long an NAI can be 📏✨ Devices handling NAIs MUST support an NAI length of at least 72 octets. 💖 They SHOULD support 253 octets, which is the dream length 🌈 but there are some implementation issues you need to keep in mind, periodt 💅
- NAI octet length constraints may impose a more severe constraint on the number of UTF-8 characters. 🙈 So the byte count is what really matters, not how many characters you think you typed 🔥
- NAIs are often transported in the User-Name attribute of the Remote Authentication Dial-In User Service (RADIUS) protocol. 🦋 The vibe check here is rough: [RFC2865], Section 5.1 says "the ability to handle at least 63 octets is recommended." 💀 So it may not be possible to get NAIs longer than 63 octets through every device 😭 Also, only one User-Name attribute fits in a RADIUS message, and the max attribute length is 253 octets, so RADIUS just can't do NAIs longer than 253 octets. 🚫
- NAIs can also ride along in the User-Name attribute of Diameter [RFC6733], which supports content lengths up to 2^24 - 9 octets. 👑 So NAIs that only ever touch Diameter nodes can be super long, iconic 🌸 But heads up, an NAI sent over Diameter might eventually get translated to RADIUS, and then all the RADIUS limits above apply again 🥺
- NAIs may be transported in other protocols too. 🧚 Each protocol can have its own limit on maximum NAI length, so always check the fine print ✨
The above criteria should permit the widest use and widest possible interoperability of the NAI. 🫶 That's the whole goal, bestie 💜
2.4. Support for Username Privacy 🔐
okay this one is giving main character energy 👑 Interpreting the username part of the NAI depends on the realm in question. 🌈 So the utf8-username portion SHOULD be treated as opaque data when processed by nodes that are not a part of the home domain for that realm. 🙈
Like, the only domain that can interpret the utf8-username portion of the NAI is the home domain 🏠 Third-party domains cannot form any conclusions about it and cannot decode it into subfields 🚫 It might be used as "firstname.lastname", or it might be entirely digits, or it might be a random hex identifier 🦋 There is simply no way (and no reason) for any other domain to read the utf8-username field as meaning anything whatsoever 💅
In some situations, NAIs are used together with a separate authentication method that can transfer the username part in a more secure manner to increase privacy 🔒 In that case, NAIs MAY be provided in an abbreviated form by omitting the username part. ✨ Omitting the username part is RECOMMENDED over using a fixed username part, such as "anonymous", since a fixed username is ambiguous about whether the NAI refers to a single user 🤔 However, current practice is to use the username "anonymous" instead of omitting the username part, and that behavior is also permitted 🌸
The most common use case for omitting or obfuscating the username part is with TLS-based EAP methods such as Tunneled Transport Layer Security (TTLS) [RFC5281]. 🎀 These methods allow for an "outer" identifier, which is typically an anonymous "@realm" 🫣 That outer identifier lets the authentication request get routed from a visited domain to a home domain 🗺️ At the same time, the username part stays confidential from the visited network 🤫 The protocol also provides for an "inner" authentication exchange, where a full identifier is used to authenticate a user 🧚
That scenario is the best of both worlds, no cap 💖 An anonymous NAI can route authentication to the home domain, and the home domain has enough info to identify and authenticate users 👑
However, some protocols don't support authentication methods that allow for "inner" and "outer" exchanges 😬 Those protocols are limited to an identifier that is publicly visible 👀 So it is RECOMMENDED that such protocols use ephemeral identifiers ✨ The authors recognize this practice isn't currently used and will likely be difficult to implement 😭
Similar to the anonymous user, there may be situations where portions of the realm are sensitive 🫢 For those, it is RECOMMENDED that the sensitive portion of the realm also be omitted (e.g., use "@example.com" instead of "@sensitive.example.com", or "anonymous@sensitive.example.com") 🌷 The home domain is authoritative for users in all subdomains and can (if necessary) route the authentication request to the appropriate subsystem within the home domain 🏰
For roaming, it's typically necessary to locate the right backend authentication server for the given NAI before the authentication conversation can proceed 🛰️ So authentication routing is impossible unless the realm portion is available and in a well-known format 💅
2.5. International Character Sets 🌍
This spec allows both international usernames and realms 🌏 International usernames are based on Unicode characters, encoded as UTF-8 🫶 The internationalization of the username portion of the NAI is based on the "Internationalized Email Headers" [RFC6532] extensions to the "local-part" of email addresses [RFC5322] 💌
To make sure there's one canonical representation, characters of the realm portion in an NAI MUST match the ABNF in this specification as well as the requirements in [RFC5891] 📐 In practice, these requirements boil down to this one item:
- Realms MUST be of the form that can be registered as a Fully Qualified Domain Name (FQDN) within the DNS. 🌐
This list is way shorter and simpler than the list in Section 2.4 of [RFC4282] 🙌 The form suggested in [RFC4282] depended on intermediate nodes doing canonicalizations based on insufficient information, which meant the form was not canonical 🙃
Specifying the realm requirement this way means the requirements depend on specifications referenced here, rather than being copied here 🧠 That lets the realm definition get updated when the referenced documents change, without needing a revision of this specification ✨
One caveat on the above is the issues noted in [RFC6912] ⚠️ That document notes there are extra DNS registration restrictions that forbid some code points from being valid in a DNS U-label 😵 These restrictions cannot be expressed algorithmically 💀
For this spec, that caveat means the following: realms not matching the above ABNF are not valid NAIs 🚫 However, some realms that do match the ABNF are still invalid NAIs 🫠 So matching the ABNF is a necessary, but not sufficient, requirement for an NAI 💅
In general, the above requirement means following the requirements specified in [RFC5891] 📚
2.6. The Normalization Process 🧼
Conversion to Unicode and normalization SHOULD be performed by edge systems (e.g., laptops, desktops, smart phones, etc.) that take "local" text as input 💻📱 These edge systems are best suited to determine the user's intent and can best convert "local" text into a normalized form 🎯
Other AAA systems, like proxies, don't have access to the locale and character set info that edge systems have 🫤 So they may not always be able to convert local input to Unicode 😬
That is, all processing of NAIs from "local" character sets and locales to UTF-8 SHOULD be performed by edge systems, before the NAIs enter the AAA system 🚪 Inside an AAA system, NAIs are sent over the wire in their canonical form, and this canonical form is used for all NAI and/or realm comparisons 🔁
Copying localized text into fields that can later be placed into the RADIUS User-Name attribute is problematic 🙅♀️ This practice can result in a AAA proxy encountering non-UTF-8 characters inside what it expects to be an NAI 💥 An example of this is Section 2.1 of [RFC3579], which says:
the NAS MUST copy the contents of the Type-Data field of the
EAP-Response/Identity received from the peer into the User-Name
attributeSo AAA proxies expect the contents of the EAP-Response/Identity sent by an EAP supplicant to be UTF-8 characters, not localized text 🌈 Using localized text in AAA username or identity fields makes realm routing difficult or impossible 😩
Unlike Section 2.4 of [RFC4282], AAA systems are now expected to perform NAI comparisons, matching, and AAA routing based on the NAI as it is received 🆕 This spec provides a canonical representation, makes sure intermediate AAA systems like proxies don't have to do translations, and can be expected to work through AAA systems that don't know about international character sets 🫶
In an ideal world, the following would be widely implemented 🦄
- Edge systems using "localized" text SHOULD normalize the NAI before it is used as an identifier in an authentication protocol. ✨
- AAA systems SHOULD NOT normalize the NAI, since they may not have sufficient information to perform the normalization. 🙅♀️
There are issues with this approach, though 😤
2.6.1. Issues with the Normalization Process 🛠️
The requirements in the preceding section are not implemented today 😭 For example, most EAP implementations use a user identifier passed to them from some other local system 📨 This identifier is treated as an opaque blob and is placed as is into the EAP Identity field 🫥 Any later system that receives that identifier is assumed to be able to understand and process it 🤞
This opaque blob can unfortunately contain localized text, which means AAA systems have to process that text 🌀
These limitations have the following theoretical and practical implications 📋
- Edge systems used today generally do not normalize the NAI. 🙈
- Therefore, AAA systems SHOULD attempt to normalize the NAI. 🔧
The suggestions above contradict the suggestions in the previous section 🙃 This is the reality of imperfect protocols 💔
Where the user identifier can be normalized, or determined to be in normal form, the normal form MUST be used as the NAI. ✅ In all other circumstances, the user identifier MUST NOT be treated as an NAI. 🚫 That data is still a user identifier, though 🫶 AAA systems MUST NOT fail authentication simply because the user identifier is not an NAI 🙌
So, when the realm portion of the NAI isn't recognized by a AAA server, it SHOULD try to normalize the NAI into NFC form 🔄 That normalized form can then be used to check whether the realm matches a known realm 🔍 If no match is found, the original form of the NAI SHOULD be used in all subsequent processing 📜
The AAA server may also convert realms to Punycode and perform all realm comparisons on the resulting Punycode strings 🌸 This conversion follows the recommendations above but may have different operational effects and failure modes ⚠️
2.7. Use in Other Protocols ✨
okay so you know how the NAI format can be used outside of AAA stuff too? 💅 Bestie, the spec says it is RECOMMENDED that you use the definition here unchanged. If you start making your own version of user identifiers, interoperability can get messy, and the user might not be able to authenticate successfully 😭. So it is RECOMMENDED that any protocol that needs a user identifier just uses the NAI format 🫶
That said, this document cannot force other protocols to use NAIs for user identifiers. Their needs are unknown, and honestly they are unknowable right now 🙈 What we can say is that interoperability and inter-domain authentication are useful and should be encouraged 🌈
Now the transport part, which is lowkey important. If a protocol is 8-bit clean, it can probably carry the NAI as is, no changes needed ✨
If a protocol is not 8-bit clean, it can't carry the NAI as is 💀 Instead, this document assumes there's a protocol-specific transport layer that handles encoding the NAI when it goes into the protocol and decoding it when it comes back out 🦋 The encoded or escaped version is not a valid NAI, so it MUST NOT be presented to the AAA system. Do not let that escaped mess near AAA, periodt 🙅♀️
Here's an example, because examples are everything. HTTP carries user identifiers, but it escapes the . character as %2E (among other things). So if you send the NAI fred@example.com over HTTP, what actually travels is:
fred@example%2EcomThat data only lives inside HTTP and has zero relevance to any AAA system 💖
And the big rule for all of this: any comparison, validation, or use of the NAI MUST be done on its unescaped (i.e., utf8-clean) form. Unescaped, always. No exceptions, no cap 👑
2.8. Using the NAI Format for Other Identifiers 🌸
Remember back in Section 1? We said it is RECOMMENDED that the NAI format be the standard format for user identifiers. This section is where we get into the details of that 🧚
Sometimes people want to make brand-new identifiers for specific contexts. These can have all kinds of properties, most of which don't matter to this document. What does matter is the goal here: we want identifiers that use a well-known format and have namespaces. The NAI format checks both boxes ✨
A great example is the "private user identity" from the 3rd Generation Partnership Project (3GPP) 📡 This identifier uniquely identifies the user to the network, and it's used for authorization, authentication, accounting, administration, and so on. It's globally unique and defined by the home network operator. The format is explicitly the NAI, as stated in Section 13.3 of [3GPP]:
The private user identity shall take the form of an NAI, and shall
have the form username@realm as specified in clause 2.1 of IETF
RFC 4282For 3GPP, the "username" part is a unique identifier derived from device-specific information. The "realm" part is made of information about the home network, followed by the base string "3gppnetwork.org". For example: 234150999999999@ims.mnc015.mcc234.3gppnetwork.org 🥹
Why is this so smart? The format is globally unique because it's based on the "3gppnetwork.org" domain. The "ims.mnc015.mcc234" prefix makes the realm specific to one particular home network (or organization). And the "username" part follows a well-known format. Iconic, honestly 👑
So the spec suggests that the NAI format be used for all new specifications and/or protocols where a user identifier is needed. And if the username parts need subfields, a well-known and documented method (like what 3GPP did) is preferred over ad hoc methods. No winging it, bestie 💅
3. Routing inside of AAA Systems 🦋
Lots of AAA systems use the "utf8-realm" part of the NAI to route requests inside an AAA proxy network 🗺️ The idea is a logical AAA routing table, where the "utf8-realm" acts as the key, and the values are one or more "next hop" AAA servers. It's giving map, it's giving GPS 🧭
Intermediate nodes MUST use the "utf8-realm" portion of the NAI without modification to do this lookup. Here's the tea: intermediate nodes might not have access to the same locale information as the system that first put the NAI into the AAA routing system. So almost all "case insensitive" comparisons can be wrong 😭 That said, where the "utf8-realm" is entirely ASCII, current AAA systems sometimes do case-insensitive matching on realms. This method MAY be continued, since it's been shown to work in practice ✨
Now, many existing non-AAA systems have user identifiers that look a lot like NAIs but don't follow this spec. They might use non-NFC form, or they might have multiple "@" characters in the identifier 🙈 In that case, intermediate nodes SHOULD normalize non-NFC identifiers to NFC before looking up the "utf8-realm" in the logical routing table. But intermediate nodes MUST NOT modify the identifiers they forward. The data as the user entered it is inviolate 🫶 Hands off, babe.
The "utf8-realm" in the logical AAA routing table SHOULD be provisioned to the proxy before it gets any AAA traffic. And the "utf8-realm" SHOULD be supplied by the "next hop" or "home" system that also supplies the routing info needed for packets to reach the next hop 📬
That "next hop" info can be any or all of the following: an IP address, a port, a RADIUS shared secret, a TLS certificate, a DNS host name, or an instruction to use dynamic DNS discovery (aka look up a record in the "utf8-realm" domain). This list isn't exhaustive, and future specs can extend it 🌈
It is RECOMMENDED to use the entirety of the "utf8-realm" for routing decisions. However, AAA systems MAY use a portion of the "utf8-realm", as long as that portion is a valid "utf8-realm" and is handled as above. For example, routing "fred@example.com" to a "com" destination is forbidden, because "com" is not a valid "utf8-realm". But routing "fred@sales.example.com" to the "example.com" destination is totally fine 💖
Another reason to forbid single labels (like "fred@sales") is that many non-AAA systems treat a single label as a local identifier within their realm. So if someone logs in as "fred@sales" to a domain "example.com", they'd be treated as if the NAI was "fred@sales.example.com" instead. Letting single labels in would change the meaning of a single label, and that can't be done 🙅♀️
3.1. Compatibility with Email Usernames 📧
As proposed here, the Network Access Identifier takes the form "user@realm". Quick heads-up: the user part is based on the "local-part" from the "Internet Message Format" [RFC5322], as extended by "Internationalized Email Headers" [RFC6532]. But it's been modified for the purposes of Section 2.2. It doesn't allow quoted text or the "folding" or "non-folding" whitespace that's common in email addresses. So the NAI isn't necessarily the same as email usernames 🧐
Still, using email addresses as user identifiers in AAA systems is super common 💌 The ABNF in Section 2.2 is designed to be close to the "addr-spec" part of [RFC5322] as extended by [RFC6532], while still being compatible with [RFC4282].
Unlike Section 2.5 of [RFC4282], this document says the internationalization requirements for NAIs and email addresses are substantially similar. The NAI and email identifiers may be the same, and both need to be entered by the user and/or the operator giving that user network access. So it makes total sense for the internationalization rules to match 🎀
3.2. Compatibility with DNS 🌐
The "utf8-realm" part of the NAI is meant to be compatible with Internationalized Domain Names (IDNs) [RFC5890]. As defined above, the "utf8-realm" as transported in an 8-bit clean protocol like RADIUS and EAP can hold any valid UTF-8 character. So there's no reason for a NAS to convert the "utf8-realm" into Punycode encoding form [RFC3492] before putting the NAI into a RADIUS User-Name attribute 🙌
The NAI doesn't make a distinction between A-labels and U-labels, because those are DNS-specific terms. Instead, it's an IDNA-valid label, per the first item in Section 2.3.2.1 of [RFC5890]. As that section notes, "IDNA-valid label" covers both "A-label" and "U-label" 🧠
When the realm part of the NAI is used for name resolution, it may be necessary to convert internationalized realm names to Punycode [RFC3492] encoding form, as described in [RFC5891]. But watch out: as Section 2 of [RFC6055] points out, resolver Application Programming Interfaces (APIs) aren't necessarily DNS specific, so the conversion to Punycode has to be done carefully:
Applications that convert an IDN to A-label form before calling (for
example) getaddrinfo() will result in name resolution failures if the
Punycode name is directly used in such protocols. Having libraries
or protocols to convert from A-labels to the encoding scheme defined
by the protocol (e.g., UTF-8) would require changes to APIs and/or
servers, which Internationalized Domain Names for Applications (IDNA)
was intended to avoid.So as a result, applications SHOULD NOT assume that non-ASCII names are resolvable using the public DNS and blindly convert them to A-labels, without knowing which protocol the name resolution library will select 💀 Don't just yolo it, bestie.
3.3. Realm Construction 🏠
The home realm usually shows up in the "utf8-realm" part of the NAI, but sometimes a different realm can be used. This might be useful, for instance, when the home realm can only be reached through intermediate proxies 🗺️
Using a different realm can prevent interoperability unless the parties involved have a mutual agreement that it's allowed. So, in particular, NAIs MUST NOT use a different realm than the home realm unless the sender has explicit knowledge that (a) the specified other realm is available and (b) the other realm supports that usage. The sender can figure out whether those conditions are met through a database, dynamic discovery, or other means not specified here. Also note that the first condition is affected by roaming, since the availability of the other realm may depend on the user's location or the desired application 🌍
And the default? The use of the home realm MUST be the default unless it's otherwise configured. Home realm, always the main character 👑🎀
3.3.1. Historical Practices ✨
okay so some AAA systems have historically used NAI modifications with multiple "prefix" and "suffix" decorations 🎀 to do explicit routing through several proxies inside a AAA network. it's giving old-school hand-drawn map energy 🗺️
in RADIUS-based environments, decorated NAI is NOT RECOMMENDED, and here's why 💅
- explicit routing paths are fragile 🥀 they don't respond well when servers go up or down, or when business relationships change
- there is no RADIUS routing protocol, so routing paths have to be shared "out of band" with every intermediate AAA node, and also with every edge system (like supplicants) that expects to get network access 📮
- explicit routing paths mean thousands, if not millions, of edge systems need new path info whenever an AAA routing path changes 😭 that's a huge expense for updates that would be way better done at just a few AAA systems in the network
- manual updates to RADIUS paths are expensive, time-consuming, and prone to error 🙃
- building compatible NAI formats is hard when locally defined "prefixes" and "suffixes" clash with similar practices elsewhere in the network 💀 those clashes can mean two networks can't be connected at all, since there's no way for packets to be routed properly in a way that meets every requirement at every intermediate proxy
- using DNS for realm names gives you a globally unique namespace for realms 🌍✨
tl;dr network practices and capabilities have changed a lot since NAIs were first overloaded to define AAA routes. manually managed explicit path routing was once useful, but the time has come for better methods 🦋
notwithstanding all that, this practice is still widely used for Diameter routing [RFC5729] 👀 those routes are managed automatically, for both credential provisioning and routing updates. they also live inside a particular framework (typically 3G) where membership is controlled and system behavior is standardized. there are no known issues with using explicit routing in that kind of environment 🫶
however, if decorated identifiers are used, like this:
homerealm.example.org!user@otherrealm.example.netthen the part before the (non-escaped) '!' MUST be a "utf8-realm" as defined in the ABNF in Section 2.2. when a system receives an identifier like this, the "otherrealm.example.net" system MUST convert the identifier to "user@homerealm.example.org" before forwarding the request. then the forwarding system MUST apply normal AAA routing for the transaction, based on the updated identifier 🔁
3.4. Examples 🍓
here are some valid Network Access Identifiers 💖
bob
joe@example.com
fred@foo-9.example.com
jack@3rd.depts.example.com
fred.smith@example.com
fred_smith@example.com
fred$@example.com
fred=?#$&*+-/^smith@example.com
nancy@eng.example.net
eng.example.net!nancy@example.net
eng%nancy@example.net
@privatecorp.example.net
\(user\)@example.netthere's also one more valid NAI 🌸 shown here as a hex string, since this document can only contain ASCII characters:
626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6dand here are some invalid ones, so you know what to avoid 🙈
fred@example
fred@example_9.com
fred@example.net@example.net
fred.@example.net
eng:nancy@example.net
eng;nancy@example.net
(user)@example.net
<nancy>@example.netone example from [RFC4282] is still permitted by the ABNF, but it is NOT RECOMMENDED 😬 because it uses the Punycode [RFC3492] encoding form for what is now a valid UTF-8 string:
alice@xn--tmonesimerkki-bfbb.example.net4. Security Considerations 🔐
okay this section is serious, bestie 😭 since an NAI reveals the home affiliation of a user, it may help an attacker probe the username space even further. this is usually the biggest worry in protocols that send the username in clear-text across the Internet, like RADIUS [RFC2865] [RFC2866]. to stop people snooping on usernames, protocols can use the confidentiality services of the protocols carrying them, like RADIUS protected by IPsec [RFC3579] or Diameter protected by TLS [RFC6733] 🛡️
this spec adds the option of hiding the username part of the NAI by leaving it out. as discussed in Section 2.4, that only works when NAIs are used together with a separate authentication method that can transfer the username securely 🤫 some applications also use their own privacy mechanisms with NAIs. for example, some EAP methods put method-specific pseudonyms in the username part of the NAI [RFC3748]. neither of these approaches can protect the realm part, but their advantage over transport protection is that the privacy of the username holds even through intermediate nodes such as NASes ✨
4.1. Correlation of Identities over Time and Protocols 🕵️♀️
the recommendations in Sections 2.7 and 2.8 for using the NAI in other protocols have privacy implications 👀 anyone who can observe traffic containing the NAI can track the user and link their activity across time and across multiple protocols. so the authentication credentials SHOULD be sent over channels that allow private communications, or multiple identifiers SHOULD be used, so user tracking is impossible 🙅♀️
it is RECOMMENDED that user privacy be boosted by configuring multiple identifiers for one user 💜 those identifiers can be changed over time, which makes tracking harder for a malicious observer. however, provisioning and managing the identifiers may be tricky in practice, which is a likely reason multiple identifiers are rarely used today 😩
4.2. Multiple Identifiers 🎭
Section 1.3 says multiple identifier formats let attackers make contradictory claims without being detected. this statement deserves more discussion 🧐
Section 2.4 talked about "inner" and "outer" identifiers in the context of TTLS [RFC5281]. a close reading of that spec shows there's no requirement that the inner and outer identifiers be related in any way. so it's perfectly valid to use "@example.com" as an outer identifier and "user@example.org" as an inner identifier. the authentication request will then be routed to "example.com", which will likely be unable to authenticate "user@example.org" 🤷♀️
even worse, a misconfigured "example.com" might proxy the inner authentication request on to the "example.org" domain 💀 cross-domain authentication like this is highly problematic, and there are few good reasons to allow it.
so it is RECOMMENDED that systems allowing anonymous "outer" identifiers require the "inner" domain to be the same as, or a subdomain of, the "outer" domain 🙌 an authentication request using disparate realms is a security violation, and the request SHOULD be rejected 🚫
it gets worse when multiple protocols are involved 😱 TTLS lets Microsoft CHAP (MS-CHAP) [RFC2433] be carried inside the TLS tunnel. MS-CHAP defines its own identifier, which is encapsulated inside the MS-CHAP exchange. that identifier isn't required to follow any particular format, isn't required to be in UTF-8, and in practice can be one of many unknown character sets. there's no practical way to figure out which character set was used for it 🫠
the result is that the "outer" EAP Identity carried by TTLS is likely not even in the same character set as the "inner" identifier used by MS-CHAP. the two identifiers are totally independent and fundamentally incomparable 🥲
such a protocol design is NOT RECOMMENDED 🚫💅
5. Administration of Names 📛
to avoid creating any new administrative procedures, administration of the NAI realm namespace piggybacks on the administration of the DNS namespace 🎀 smart, right?
NAI realm names are required to be unique. the rights to use a given NAI realm for roaming are obtained at the same time as the rights to use a particular Fully Qualified Domain Name (FQDN) 🌐 anyone who wants to use an NAI realm name should first acquire the rights to use the matching FQDN. administrators MUST NOT publicly use an NAI realm without first owning the matching FQDN 🙅 private use of unowned NAI realms inside an administrative domain is allowed, though it is RECOMMENDED that example names be used, like "example.com" 🧸
note that using an FQDN as the realm name doesn't require using DNS to locate the authentication server 🗺️ while Diameter [RFC6733] supports DNS for locating authentication servers, existing RADIUS implementations usually use proxy configuration files to find authentication servers within a domain and do authentication routing. the implementations described in [RFC2194] didn't use DNS to locate the authentication server within a domain. similarly, existing implementations haven't needed dynamic routing protocols or propagation of global routing information 🙌 and finally, there's no requirement that the NAI be a valid email address, so don't panic if it isn't 📧
6. References 📚
6.1. Normative References 🔖
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, http://www.rfc-editor.org/info/rfc2119.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, http://www.rfc-editor.org/info/rfc3629.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008, http://www.rfc-editor.org/info/rfc5198.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, http://www.rfc-editor.org/info/rfc5234.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, http://www.rfc-editor.org/info/rfc5890.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010, http://www.rfc-editor.org/info/rfc5891.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011, http://www.rfc-editor.org/info/rfc6365.
that's the whole vibe for part 5, bestie 🌈💖
6.2. Informative References
Okay bestie, this is the bonus reading list 📚🫶 These are informative, so you don't need them, but they're giving background and I'm obsessed with how much history is packed in here.
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang,
"Review of Roaming Implementations", RFC 2194,
September 1997, <http://www.rfc-editor.org/info/rfc2194>.
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco
Layer Two Forwarding (Protocol) "L2F"", RFC 2341,
May 1998, <http://www.rfc-editor.org/info/rfc2341>.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998,
<http://www.rfc-editor.org/info/rfc2433>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, July 1999,
<http://www.rfc-editor.org/info/rfc2637>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999,
<http://www.rfc-editor.org/info/rfc2661>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000,
<http://www.rfc-editor.org/info/rfc2866>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003,
<http://www.rfc-editor.org/info/rfc3492>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003,
<http://www.rfc-editor.org/info/rfc3579>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005,
<http://www.rfc-editor.org/info/rfc4282>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005,
<http://www.rfc-editor.org/info/rfc4301>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008,
<http://www.rfc-editor.org/info/rfc5281>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5335] Yang, A., Ed., "Internationalized Email Headers",
RFC 5335, September 2008,
<http://www.rfc-editor.org/info/rfc5335>.
[RFC5729] Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou,
"Clarifications on the Routing of Diameter Requests Based
on the Username and the Realm", RFC 5729, December 2009,
<http://www.rfc-editor.org/info/rfc5729>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055,
February 2011, <http://www.rfc-editor.org/info/rfc6055>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, February 2012,
<http://www.rfc-editor.org/info/rfc6532>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
[RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman,
"Principles for Unicode Code Point Inclusion in Labels in
the DNS", RFC 6912, April 2013,
<http://www.rfc-editor.org/info/rfc6912>.
[EDUROAM] "eduroam (EDUcation ROAMing)", <http://eduroam.org>.
[3GPP] 3GPP, "Numbering, addressing and Identification", 3GPP TS
23.003, Release 12, July 2014,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.Appendix A. Changes from RFC 4282 🦋
Okay so this is the glow-up recap ✨ Here's everything that changed from the earlier NAI definition in [RFC4282]:
- The formal syntax in Section 2.1 now forbids non-UTF-8 characters, like anything with the "high bit" set. 🙅♀️
- The formal syntax in Section 2.1 of [RFC4282] now allows UTF-8 in the "realm" portion of the NAI. 🌏
- The formal syntax in Section 2.1 of [RFC4282] applied to the NAI after it was "internationalized" via the
ToAsciifunction, and the contents before that step were left indeterminate. This document defines an internationalized form of the NAI and forbids the use of theToAsciifunction for NAI "internationalization". 🚫 - The grammar for the user and realm portion is based on a combination of the "nai" defined in Section 2.1 of [RFC4282] and the "utf8-addr-spec" defined in Section 4.4 of [RFC5335]. 🧩
- All use of the
ToAsciifunction has been moved to the normal requirements on DNS implementations when realms are used as the basis for DNS lookups. Good news: this involves no changes to the existing DNS infrastructure. 🌸 - The discussions on internationalized character sets in Section 2.4 of [RFC4282] have been updated, and the suggestion to use the
ToAsciifunction for realm comparisons has been removed. No AAA system has implemented these suggestions, so this change should have no operational impact. 💅 - The "Routing inside of AAA Systems" section is brand new in this document. The concept of a "local AAA routing table" is also new, although it accurately describes the functionality of widespread implementations. 🧚
- The "Compatibility with EMail Usernames" and "Compatibility with DNS" sections have been revised and updated. The Punycode transformation is suggested only when a realm name is used for DNS lookups. Even then, the function is only used by a resolving API on the local system, and it is recommended that only the home network perform this conversion. 🍓
- The "Realm Construction" section has been updated to note that editing of the NAI is NOT RECOMMENDED. 🙈
- The "Examples" section has been updated to remove the instance of the IDN being converted to ASCII. This behavior is now forbidden. 💀
Acknowledgments 🫶
The initial text for this document was [RFC4282], which was then heavily edited. The original authors of [RFC4282] were Bernard Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. Iconic team 👑
Author's Address 🎀
Alan DeKok
The FreeRADIUS Server Project
EMail: aland@freeradius.org📦 where this page comes from
- ietf: rfc7542 2015-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms