The Network Access Identifier
obsoletes
- rfc-4282 — The Network Access Identifier
Extracted elements (29)
Decorated NAI routing (using prefix/suffix decorations to specify explicit AAA routing paths) is NOT RECOMMENDED in RADIUS environments because it is fragile, unresponsive to network changes, requires out-of-band updates to millions of edge systems, and creates namespace conflicts between networks. DNS-based realm names already provide a globally unique namespace.
Normalization of NAIs from local character sets to UTF-8 SHOULD be performed by edge systems (laptops, phones, etc.) rather than AAA intermediaries, because edge systems have access to locale and character set information that intermediate nodes lack. However, in practice, edge systems do not normalize, so AAA systems SHOULD attempt normalization despite this contradiction.
RFC 4282 was revised primarily due to internationalization failures: its ABNF restricted realms to ASCII conflicting with EAP and RADIUS (both 8-bit clean and UTF-8 recommending); it required language-specific mappings impossible for intermediate nodes; its normalization requirements conflicted with local system requirements; and no AAA client, proxy, or server had implemented its Section 2.4 requirements.
The NAI format is defined as protocol-independent so that a single standard identifier can be reused across AAA and non-AAA protocols. Multiple incompatible identifier formats increase cost, complexity, and allow attackers to make contradictory identity claims without detection.
RFC 2865 (RADIUS) recommends handling at least 63 octets in the User-Name attribute, and the maximum RADIUS attribute length is 253 octets. NAIs transported in RADIUS are therefore effectively limited to 253 octets; any NAI that passes through a Diameter-to-RADIUS translation may be truncated if it exceeds this limit.
The AAA system may also convert realms to Punycode and perform all realm comparisons on the resulting Punycode strings as an alternative normalization strategy. Where the utf8-realm is entirely ASCII, case-insensitive matching MAY be continued as it has been shown to work in practice.
The NAI username syntax is based on the RFC 5322 'local-part' as extended by RFC 6532 internationalized email headers, but it does not permit quoted text, folding whitespace, or non-folding whitespace common in email. The NAI is therefore not necessarily equivalent to email usernames, though email addresses are commonly used as NAI user identifiers in AAA systems.
The utf8-realm portion is compatible with Internationalized Domain Names (IDNs) and does not need to be converted to Punycode before being placed in a RADIUS User-Name attribute. Punycode conversion should only occur when the realm is used for DNS lookups, and applications SHOULD NOT blindly convert non-ASCII names to A-labels without knowing which protocol the name resolution library will select.
AAA systems MUST be able to handle user identifiers that are not in NAI format, since existing protocols and deployments do not always use the NAI format.
Administrators MUST NOT publicly use an NAI realm without first owning the corresponding FQDN. Administration of NAI realm names piggybacks on the DNS namespace administration, and rights to use an NAI realm are obtained coincident with acquiring the corresponding FQDN.
Devices handling NAIs MUST support an NAI length of at least 72 octets. Devices SHOULD support an NAI length of 253 octets, which is also the maximum length supported by the RADIUS User-Name attribute.
If decorated identifiers (e.g., '[email protected]') are used, the part before the unescaped '!' MUST be a valid utf8-realm. The receiving system MUST convert the identifier to '[email protected]' before forwarding, then apply normal AAA routing.
Intermediate AAA nodes MUST use the 'utf8-realm' portion of the NAI without modification to perform routing lookups. Intermediate nodes MUST NOT modify the identifiers that they forward; the data as entered by the user is inviolate.
It is RECOMMENDED that systems permitting anonymous 'outer' identifiers require that the 'inner' domain 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.
NAIs MUST NOT use a different realm than the home realm unless the sender has explicit knowledge that the specified other realm is available and supports such usage. The use of the home realm MUST be the default unless otherwise configured.
Realm characters in an NAI MUST match the ABNF in Section 2.2 as well as RFC 5891 requirements; specifically, realms MUST be of the form registerable as a Fully Qualified Domain Name (FQDN) in the DNS. Matching the ABNF is necessary but not sufficient — some ABNF-matching realms are still invalid due to DNS restrictions on code points.
Strings that are not in Unicode Normal Form Composed (NFC) are not valid NAIs and SHOULD NOT be treated as such. Implementations that receive a non-normalized but otherwise valid UTF-8 string SHOULD create a local normalized copy for local processing only; that local version MUST NOT be used outside the local context.
The encoded or escaped version of an NAI (e.g., HTTP-escaped form) is not a valid NAI and MUST NOT be presented to the AAA system. Any comparison, validation, or use of the NAI MUST be done on its unescaped (utf8-clean) form.
The utf8-username portion of the NAI SHOULD be treated as opaque data when processed by nodes that are not part of the home domain for that realm. Third-party domains cannot decode it into subfields or ascribe meaning to it.
When NAIs are used with a separate authentication method that secures the username, NAIs MAY be provided in abbreviated form by omitting the username. Omitting the username is RECOMMENDED over using a fixed username such as 'anonymous', as a fixed username is ambiguous about whether the NAI refers to a single user.
Where the identifier can be normalized or determined to be in normal form, that normal form MUST be used as the NAI. In all other circumstances, the user identifier MUST NOT be treated as an NAI. AAA systems MUST NOT fail authentication simply because the user identifier is not an NAI.
The most common privacy technique is the outer/inner identifier split in TLS-based EAP methods (e.g., EAP-TTLS): an anonymous '@realm' outer identifier routes the request to the home domain while keeping the real username confidential from the visited network; the real identity is exchanged only in the inner TLS-protected authentication.
Using one identifier across multiple protocols enables cross-protocol identity correlation. It is RECOMMENDED that user privacy be enhanced by configuring multiple identifiers for one user and rotating them over time to hinder tracking by malicious observers, though provisioning and management of multiple identifiers is difficult in practice.
The Network Access Identifier (NAI) is a user identifier submitted by a client during authentication, used to route authentication requests across domains and associate a user with a home account. It takes the form 'utf8-username@utf8-realm', or may omit either the username or the realm portion.
Any attacker capable of observing traffic containing the NAI can track the user and correlate activity across time and across multiple protocols. Authentication credentials SHOULD be transported over channels permitting private communications, or multiple identifiers SHOULD be used to make user tracking impossible.
Multiple identifier formats allow attackers to make contradictory claims without being detected. In TTLS, there is no requirement that inner and outer identifiers be related, enabling cross-domain authentication abuses where a misconfigured home domain proxies inner authentication to a completely different domain. Such disparate-realm requests SHOULD be rejected.
Since an NAI reveals the home affiliation of a user, it may assist an attacker in probing the username space. Protocols that transmit the NAI in clear text (such as RADIUS) should use confidentiality services such as RADIUS over IPsec or Diameter over TLS to prevent username snooping.
The NAI ABNF grammar (Section 2.2) defines three forms: username-only, realm-only ('@utf8-realm'), or 'utf8-username@utf8-realm'. The username is a dot-string of utf8-atext characters; the realm is one or more dot-separated labels composed of ALPHA, DIGIT, or UTF8-xtra-char, following IDNA rules.
UTF-8 multi-byte characters in NAIs are encoded per RFC 3629: UTF8-2 covers %xC2-DF + tail, UTF8-3 covers %xE0-EF sequences, and UTF8-4 covers %xF0-F4 sequences, where UTF8-tail is %x80-BF. All non-ASCII characters in NAIs must be valid UTF-8.