The Network Access Identifier
obsoleted by
- rfc-7542 — The Network Access Identifier
obsoletes
- rfc-2486 — The Network Access Identifier
Extracted elements (23)
Conversion of internationalized domain names to ASCII is left to end systems (clients and AAA servers) so that intermediate AAA proxies need not perform translations and can operate without awareness of international character sets, providing a canonical wire representation.
NAI realm namespace administration piggybacks on DNS: rights to use an NAI realm for roaming are obtained coincident with acquiring the corresponding FQDN, avoiding the creation of a separate administrative procedure. Use of a realm without ownership of the corresponding FQDN is discouraged as it risks conflicts.
The realm BNF was changed to allow a leading digit (e.g., '3com.com'), which RFC 1035 prohibits, to reflect common current practice where such FQDNs are widely used and accepted by deployed software.
RADIUS (RFC 2865) recommends handling at least 63 octets in the User-Name attribute and supports a maximum of 253 octets per attribute; NAIs longer than 253 octets cannot be transported over RADIUS. NAIs processed only by Diameter can be much longer, but may be translated to RADIUS downstream, reinstating the 253-octet limit.
RFC 4282 adds support for UTF-8 characters (%x80–FF) in the username portion, which may be unacceptable to RFC 2486-compliant nodes that only support ASCII. Similarly, NAIs without a username (for privacy) and long NAIs (beyond 63 octets) may not be accepted by RFC 2486-compliant nodes.
The username portion of the NAI is based on the RFC 821 BNF but extended for internationalization and mediating-realm syntax; it is not necessarily compatible with e-mail usernames. Internationalization requirements for NAIs and e-mail addresses also differ.
Characters in the username portion of an NAI MUST satisfy the ABNF in Section 2.1 and the requirements of RFC 4013 (SASLprep), including mapping, normalization, prohibited output, bidirectional character handling, and exclusion of unassigned code points.
Devices handling NAIs MUST support an NAI length of at least 72 octets.
Mapping, normalization, and bidirectional character processing MUST be performed by end systems (typically the client and AAA server) that accept international text as input. End systems MUST also check for prohibited output and unassigned code points.
NAIs MUST NOT use a realm other than the home realm unless the sender has explicit knowledge that (a) the specified other realm is available and (b) it supports such usage.
Omitting the username part is RECOMMENDED over using a fixed username such as 'anonymous', because omission unambiguously signals that no unique user identity is being conveyed.
Support for an NAI length of 253 octets is RECOMMENDED to accommodate RADIUS transport constraints, where a single User-Name attribute may carry at most 253 octets.
The home realm MUST be the default realm used in an NAI unless otherwise explicitly configured.
The username part of an NAI SHOULD be treated as opaque data when processed by nodes that are not part of the authoritative domain for that realm.
When a mediating realm receives an NAI in the 'realm!user@otherrealm' form, it MUST convert it back to 'user@homerealm' format when forwarding, and MUST apply appropriate AAA routing for the transaction.
When used with a separate authentication method that transfers the username securely, NAIs MAY be provided in abbreviated form by omitting the username part entirely.
The NAI has three valid forms: a username alone, '@' followed by a realm, or a username followed by '@' and a realm. The username grammar derives from RFC 821 (SMTP), extended for internationalization, and the realm grammar is based on RFC 1035 DNS labels.
The realm portion of an NAI is an 'IDN-unaware domain name slot' (per RFC 3490) and therefore carries only ASCII characters. An implementation MAY support Internationalized Domain Names by applying the ToASCII operation before transmission.
When routing through a mediating realm is required, an NAI of the form '[email protected]' MAY be encoded as '[email protected]'. The part before the unescaped '!' MUST be a realm name as defined in Section 2.1 ABNF. This encoding may be applied recursively for multiple mediating realms.
An NAI reveals the user's home realm affiliation, enabling an attacker to narrow the username space to probe. This risk is highest in protocols that transmit the NAI in clear-text, such as RADIUS over an unprotected link.
To prevent username snooping, protocols carrying NAIs SHOULD use confidentiality services such as RADIUS protected by IPsec (RFC 3579) or Diameter protected by TLS (RFC 3588).
Username privacy can be achieved by omitting the username from the NAI, but only when a separate authentication method (e.g., an EAP method using pseudonyms per RFC 3748) transfers the true username securely. Neither approach protects the realm portion of the NAI.
The NAI username (dot-string) permits printable ASCII characters except '"', '(', ')', ',', '.', ':', ';', '<', '>', '@', '[', '\', ']', and DEL, plus escaped any-octet sequences and UTF-8 octets %x80–FF. The realm is composed of dot-separated labels of letters, digits, and hyphens.