💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc4282.txt captured on 2023-12-28 at 17:56:46.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Network Working Group B. Aboba
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.
Aboba, et al. Standards Track [Page 1]
RFC 4282 The Network Access Identifier December 2005
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
Aboba, et al. Standards Track [Page 2]
RFC 4282 The Network Access Identifier December 2005
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.
Aboba, et al. Standards Track [Page 3]
RFC 4282 The Network Access Identifier December 2005
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
Aboba, et al. Standards Track [Page 4]
RFC 4282 The Network Access Identifier December 2005
c = %x21 ; '!' allowed
; '"' not allowed
c =/ %x23 ; '#' allowed
c =/ %x24 ; '