ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-roamops-nai-02.txt>
The Network Access Identifier
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-roamops-nai-02.txt> and expires September 15, 1997. Please send
comments to the authors.
2. Abstract
This document describes issues relating to user identification in pro-
vision of "roaming capability" for dialup Internet users. "Roaming
capability" may be loosely defined as the ability to use any one of
multiple Internet service providers (ISPs), while maintaining a for-
mal, customer-vendor relationship with only one. Examples of cases
where roaming capability might be required include ISP "confedera-
tions" and ISP-provided corporate network access support.
3. Introduction
Considerable interest has arisen recently in a set of features that
fit within the general category of "roaming capability" for dialup
Internet users. Interested parties have included:
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.
National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive
Aboba [Page 1]
INTERNET-DRAFT 6 March 1997
dialup service in a group of countries or on a continent.
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 Virtual Private Network (VPN), enabled by tunnel-
ing protocols such as PPTP, L2F and L2TP.
This document focuses on issues of user identification for use in
roaming services. However, since roaming and tunneling are closely
related, it is believed that the considerations described here will
also be of interest to those working on tunneling.
3.1. Terminology
This document frequently uses the following terms:
Network Access Identifier
The Network Access Identifier (NAI) is the userID submitted
by the client during the PPP negotiation. In roaming, the
purpose of the NAI is to identify the user as well as to
assist in the routing of the authentication request. As
such, the NAI may be presented either in the form of an
authentication route, or a pointer to such a route. Please
note that the NAI may not necessarily be the same as the
user's e-mail address or the userID submitted in an applica-
tion layer authentication (i.e. HTTP authentication). In
order to avoid confusion on this point, a new term was
coined.
Network Access Server
The Network Access Server (NAS) is the device that clients
dial in order to get access to the network. In PPTP termi-
nology this is referred to as the PPTP Access Concentrator
(PAC), and in L2TP terminology, it is referred to as the
L2TP Access Concentrator (LAC).
RADIUS server
This is a server which provides for authentication/autho-
rization via the protocol described in [3], and for account-
ing as described in [4].
RADIUS proxy
In order to provide for the routing of RADIUS authentication
and accounting requests, a RADIUS proxy may employed. To the
NAS, the RADIUS proxy acts as a RADIUS server, and to the
RADIUS server, the proxy acts as a RADIUS client.
3.2. Purpose
As described in[1], there are now at least four services implementing
dialup roaming, and the number of Internet Service Providers involved
Aboba [Page 2]
INTERNET-DRAFT 6 March 1997
in roaming consortia is increasing rapidly.
In order to be able to offer roaming capability, one of the require-
ments is to be able to identify the user's home authentication server.
For use in roaming, this function is accomplished via the NAI submit-
ted by the user to the NAS in the initial PPP authentication.
This document proposes syntax and semantics for the NAI. It is
expected that this will be of interest for support of roaming as well
as tunneling. For example, references [5] and [6] refer to use of the
NAI in determining the tunnel endpoint. However, these references do
not provide guidelines for how RADIUS or tunnel routing is to be
accomplished. In order to avoid the possibility of conflicting and
non-interoperable implementations, references [7] and [8] describe how
RADIUS and tunneling protocols may be integrated. This document pro-
vides guidance in the use of the NAI that is relevant to both the
roaming and tunneling communities.
4. Formal Definition of the NAI
As proposed in this specification, the Network Access Identifer is of
the form user@domain, where the domain is a fully qualified domain
name (FQDN). The syntax for the NAI is independent of the method used
to route the authentication.
In order to support the determination of the existence of a roaming
relationship path between the local ISP and the home domain, one of
two methods may be used. If the number of domains to be served is
small, then it is possible to provide roaming relationship information
via the authentication proxy configuration file. If the number of
domains to be served is large, then a more scalable mechanism is rec-
ommended, such as use of the DNS Roaming Relationship (REL) resource
record, as described in [10]. However, even if use of the DNS is
enabled, an authentication proxy will typically consult its configura-
tion file for information on roaming relationships, prior to retriev-
ing information via DNS.
4.1. BNF for the NAI
The grammar for the NAI is given below, using the augmented BNF nota-
tion described in reference [9].
NAI = USERNAME "@" FQDN
FQDN = token "." token *[ "." token ]
USERNAME = token
Examples of valid Network Access Identifiers include:
fred@bigco.com
nancy@howard.edu
Examples of invalid Network Access Identifiers include:
Aboba [Page 3]
INTERNET-DRAFT 6 March 1997
bigco
howard.edu
5. Acknowledgements
Thanks to Glen Zorn of Microsoft for many useful discussions of this
problem space.
6. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen-
tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass
Alliance, Asiainfo, January, 1997.
[2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." draft-ietf-
roamops-roamreq-03.txt, Microsoft, March, 1997.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit,
Daydreamer, January, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January,
1997.
[5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J.
Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft-
ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996.
[6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little.
"Point-to-Point Tunneling Protocol -- PPTP." draft-ietf-pppext-
pptp-00.txt, Ascend Communications, June, 1996.
[7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft-
ietf-radius-tunnel-auth-00.txt, Microsoft Corporation, November, 1996.
[8] B. Aboba. "Implementation of Mandatory Tunneling via RADIUS."
draft-ietf-radius-tunnel-imp-00.txt, Microsoft Corporation, February,
1997.
[9] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1."
draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
[10] B. Aboba. "The Roaming Relationship (REL) Resource Record in the
DNS." draft-ietf-roamops-dnsrr-02.txt, Microsoft Corporation, March,
1997.
7. Authors' Addresses
Bernard Aboba
Microsoft Corporation
Aboba [Page 4]
INTERNET-DRAFT 6 March 1997
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Aboba [Page 5]
