Request for Comments: 4282 Microsoft
Obsoletes: 2486 M. Beadles
Category: Standards Track ENDFORCE
J. Arkko
Ericsson
P. Eronen
Nokia
December 2005
The Network Access Identifier
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In order to provide roaming services, it is necessary to have a
standardized method for identifying users. This document defines the
syntax for the Network Access Identifier (NAI), the user identity
submitted by the client during network authentication. "Roaming" may
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 where roaming capabilities
might be required include ISP "confederations" and ISP-provided
corporate network access support. This document is a revised version
of RFC 2486, which originally defined NAIs. Enhancements include
international character set and privacy support, as well as a number
of corrections to the original RFC.
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Requirements Language ......................................4
1.3. Purpose ....................................................4
2. NAI Definition ..................................................4
2.1. Formal Syntax ..............................................4
2.2. NAI Length Considerations ..................................6
2.3. Support for Username Privacy ...............................6
2.4. International Character Sets ...............................7
2.5. Compatibility with E-Mail Usernames ........................8
2.6. Compatibility with DNS .....................................8
2.7. Realm Construction .........................................8
2.8. Examples ..................................................10
3. Security Considerations ........................................10
4. IANA Considerations ............................................11
5. References .....................................................11
5.1. Normative References ......................................11
5.2. Informative References ....................................12
Appendix A. Changes from RFC 2486 ................................14
Appendix B. Acknowledgements .....................................14
1. Introduction
Considerable interest exists for a set of features that fit within
the general category of "roaming capability" for network access,
including dialup Internet users, Virtual Private Network (VPN) usage,
wireless LAN authentication, and other applications. Interested
parties have included the following:
o Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer dialup service
over a wider area.
o National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive
dialup service in a group of countries or on a continent.
o Wireless LAN hotspots providing service to one or more ISPs.
o Businesses desiring 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 [RFC2401].
In order to enhance the interoperability of roaming services, it is
necessary to have a standardized method for identifying users. This
document defines syntax for the Network Access Identifier (NAI).
Examples of implementations that use the NAI, and descriptions of its
semantics, can be found in [RFC2194].
This document is a revised version of RFC 2486 [RFC2486], which
originally defined NAIs. Differences and enhancements compared to
RFC 2486 are listed in Appendix A.
1.1. Terminology
This document frequently uses the following terms:
Network Access Identifier
The Network Access Identifier (NAI) is the user identity submitted
by the client during network access authentication. In roaming,
the purpose of the NAI is to identify the user as well as to
assist in the routing of the authentication request. Please note
that the NAI may not necessarily be the same as the user’s e-mail
address or the user identity submitted in an application layer
authentication.
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.
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.
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).
1.2. Requirements Language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119].
1.3. Purpose
As described in [RFC2194], there are a number of providers offering
network access services, and the number of Internet Service Providers
involved in roaming consortia is increasing rapidly.
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.
2. NAI Definition
2.1. Formal Syntax
The grammar for the NAI is given below, described in Augmented
Backus-Naur Form (ABNF) as documented in [RFC4234]. The grammar for
the username is based on [RFC0821], and the grammar for the realm is
an updated version of [RFC1035].
nai = username
nai =/ "@" realm
nai =/ username "@" realm
username = dot-string
dot-string = string
dot-string =/ dot-string "." string
string = char
string =/ string char
char = c
char =/ "\" x
c = %x21 ; ’!’ allowed
; ’"’ not allowed
c =/ %x23 ; ’#’ allowed
c =/ %x24 ; ’$’ allowed
c =/ %x25 ; ’%’ allowed
c =/ %x26 ; ’&’ allowed
c =/ %x27 ; ’’’ allowed
; ’(’, ’)’ not allowed
c =/ %x2A ; ’*’ allowed
c =/ %x2B ; ’+’ allowed
; ’,’ not allowed
c =/ %x2D ; ’-’ allowed
; ’.’ not allowed
c =/ %x2F ; ’/’ allowed
c =/ %x30-39 ; ’0’-’9’ allowed
; ’;’, ’:’, ’<’ not allowed
c =/ %x3D ; ’=’ allowed
; ’>’ not allowed
c =/ %x3F ; ’?’ allowed
; ’@’ not allowed
c =/ %x41-5a ; ’A’-’Z’ allowed
; ’[’, ’\’, ’]’ not allowed
c =/ %x5E ; ’^’ allowed
c =/ %x5F ; ’_’ allowed
c =/ %x60 ; ’`’ allowed
c =/ %x61-7A ; ’a’-’z’ allowed
c =/ %x7B ; ’{’ allowed
c =/ %x7C ; ’|’ allowed
c =/ %x7D ; ’}’ allowed
c =/ %x7E ; ’~’ allowed
; DEL not allowed
c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)
; Where UTF-8-octet is any octet in the
; multi-octet UTF-8 representation of a
; unicode codepoint above %x7F.
; Note that c must also satisfy rules in
; Section 2.4, including, for instance,
; checking that no prohibited output is
; used (see also Section 2.3 of
; [RFC4013]).
x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8-octets as defined
; above (this was not allowed in
; RFC 2486). Note that x must nevertheless
; again satisfy the Section 2.4 rules.
realm = 1*( label "." ) label
label = let-dig *(ldh-str)
ldh-str = *( alpha / digit / "-" ) let-dig
let-dig = alpha / digit
alpha = %x41-5A ; ’A’-’Z’
alpha =/ %x61-7A ; ’a’-’z’
digit = %x30-39 ; ’0’-’9’
2.2. NAI Length Considerations
Devices handling NAIs MUST support an NAI length of at least 72
octets. Support for an NAI length of 253 octets is RECOMMENDED.
However, the following implementation issues should be considered:
o NAIs are often transported in the User-Name attribute of the
Remote Authentication Dial-In User Service (RADIUS) protocol.
Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the
ability to handle at least 63 octets is recommended." As a
result, it may not be possible to transfer NAIs beyond 63 octets
through all devices. In addition, since only a single User-Name
attribute may be included in a RADIUS message and the maximum
attribute length is 253 octets; RADIUS is unable to support NAI
lengths beyond 253 octets.
o NAIs can also be transported in the User-Name attribute of
Diameter [RFC3588], which supports content lengths up to 2^24 - 9
octets. As a result, NAIs processed only by Diameter nodes can be
very long. Unfortunately, an NAI transported over Diameter may
eventually be translated to RADIUS, in which case the above
limitations apply.
2.3. Support for Username Privacy
Interpretation of the username part of the NAI depends on the realm
in question. Therefore, the "username" part SHOULD be treated as
opaque data when processed by nodes that are not a part of the
authoritative domain (in the sense of Section 4) for that realm.
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 this 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 it provides an unambiguous way to
determine whether the username is intended to uniquely identify a
single user.
For roaming purposes, it is typically necessary to locate the
appropriate backend authentication server for the given NAI before
the authentication conversation can proceed. As a result, the realm
portion is typically required in order for the authentication
exchange to be routed to the appropriate server.
2.4. International Character Sets
This specification allows both international usernames and realms.
International usernames are based on the use of Unicode characters,
encoded as UTF-8 and processed with a certain algorithm to ensure a
canonical representation. Internationalization of the realm portion
of the NAI is based on "Internationalizing Domain Names in
Applications (IDNA)" [RFC3490].
In order to ensure a canonical representation, characters of the
username portion in an NAI MUST fulfill the ABNF in this
specification as well as the requirements specified in [RFC4013].
These requirements consist of the following:
o Mapping requirements, as specified in Section 2.1 of [RFC4013].
Mapping consists of mapping certain characters to others (such as
SPACE) in order to increase the likelihood of correctly performed
comparisons.
o Normalization requirements, as specified in Section 2.2 of
[RFC4013], are also designed to assist in comparisons.
o Prohibited output. Certain characters are not permitted in
correctly formed strings that follow Section 2.3 of [RFC4013].
Ensuring that NAIs conform to their ABNF is not sufficient; it is
also necessary to ensure that they do not contain prohibited
output.
o Bidirectional characters are handled as specified in Section 2.4
of [RFC4013].
o Unassigned code points are specified in Section 2.5 of [RFC4013].
The use of unassigned code points is prohibited.
The mapping, normalization, and bidirectional character processing
MUST be performed by end systems that take international text as
input. In a network access setting, such systems are typically the
client and the Authentication, Authorization, and Accounting (AAA)
server. NAIs are sent over the wire in their canonical form, and
tasks such as normalization do not typically need to be performed by
nodes that just pass NAIs around or receive them from the network.
End systems MUST also perform checking for prohibited output and
unassigned code points. Other systems MAY perform such checks, when
they know that a particular data item is an NAI.
The realm name is an "IDN-unaware domain name slot" as defined in
[RFC3490]. That is, it can contain only ASCII characters. An
implementation MAY support Internationalized Domain Names (IDNs)
using the ToASCII operation; see [RFC3490] for more information.
The responsibility for the conversion of internationalized domain
names to ASCII is left for the end systems, such as network access
clients and AAA servers. Similarly, we expect domain name
comparisons, matching, resolution, and AAA routing to be performed on
the ASCII versions of the internationalized domain names. This
provides a canonical representation, ensures that intermediate
systems such as AAA proxies do not need to perform translations, and
can be expected to work through systems that are unaware of
international character sets.
2.5. Compatibility with E-Mail Usernames
As proposed in this document, the Network Access Identifier is of the
form user@realm. Please note that while the user portion of the NAI
is based on the BNF described in [RFC0821], it has been extended for
internationalization support as well as for purposes of Section 2.7,
and is not necessarily compatible with the usernames used in e-mail.
Note also that the internationalization requirements for NAIs and
e-mail addresses are different, since the former need to be typed in
only by the user himself and his own operator, not by others.
2.6. Compatibility with DNS
The BNF of the realm portion allows the realm to begin with a digit,
which is not permitted by the BNF described in [RFC1035]. This
change was made to reflect current practice; although not permitted
by the BNF described in [RFC1035], Fully Qualified Domain Names
(FQDNs) such as 3com.com are commonly used and accepted by current
software.
2.7. Realm Construction
NAIs are used, among other purposes, for routing AAA transactions to
the user’s home realm. Usually, the home realm appears in the realm
portion of the NAI, but in some cases a different realm can be used.
This may be useful, for instance, when the home realm is reachable
only via another mediating realm.
Such usage may prevent interoperability unless the parties involved
have a mutual agreement that the usage is allowed. 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 such usage. The sender
may determine the fulfillment of these conditions through a database,
dynamic discovery, or other means not specified here. Note that the
first condition is affected by roaming, as the availability of the
other realm may depend on the user’s location or the desired
application.
The use of the home realm MUST be the default unless otherwise
configured.
Where these conditions are fulfilled, an NAI such as
user@homerealm.example.net
MAY be represented as in
homerealm.example.net!user@otherrealm.example.net
In this case, the part before the (non-escaped) ’!’ MUST be a realm
name as defined in the ABNF in Section 2.1. This realm name is an
"IDN-unaware domain name slot", just like the realm name after the
"@" character; see Section 2.4 for details. When receiving such an
NAI, the other realm MUST convert the format back to
"user@homerealm.example.net" when passing the NAI forward, as well as
applying appropriate AAA routing for the transaction.
The conversion process may apply also recursively. That is, after
the conversion, the result may still have one or more ’!’ characters
in the username. For instance, the NAI
other2.example.net!home.example.net!user@other1.example.net
would first be converted in other1.example.net to
home.example.net!user@other2.example.net
and then at other2.example.net finally to
user@homerealm.example.net
Note that the syntax described in this section is optional and is not
a part of the ABNF. The ’!’ character may appear in the username
portion of an NAI for other purposes as well, and in those cases, the
rules outlined here do not apply; the interpretation of the username
is up to an agreement between the identified user and the realm given
after the ’@’ character.
2.8. Examples
Examples of valid Network Access Identifiers include the following:
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.net
alice@xn--tmonesimerkki-bfbb.example.net
The last example uses an IDN converted into an ASCII representation.
Examples of invalid Network Access Identifiers include the following:
fred@example
fred@example_9.com
fred@example.net@example.net
fred.@example.net
eng:nancy@example.net
eng;nancy@example.net