WDIFF

draft-ietf-roamops-nai-02.txt --> draft-ietf-roamops-nai-03.txt

ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-roamops-nai-02.txt>
Category: Standards Track
<draft-ietf-roamops-nai-03.txt>
May 22, 1997

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
material 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>
ietf-roamops-nai-03.txt> and expires September 15, 1997. January 1, 1998. Please send
comments to the authors.

2. Abstract

This document describes issues relating

In order to user identification in pro-
vision enhance the interoperability of "roaming capability" roaming and tunneling ser-
vices, it is desirable to have a standardized method for dialup Internet identifying
users. This document proposes syntax for the Network Access Identifier
(NAI). It is expected that this will be of interest for support of
roaming as well as tunneling. "Roaming capability" may be loosely
defined as the ability to use any one of multiple Internet service
providers (ISPs), while maintaining a for-
mal, formal, customer-vendor relationship rela-
tionship with only one. Examples of cases where roaming capability
might be required include ISP "confedera-
tions" "confederations" and ISP-provided corporate cor-
porate 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

Aboba [Page 1]

INTERNET-DRAFT May 22, 1997

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

In order to enhance the interoperability of user identification for use in
roaming services. However, since roaming and tunneling are closely
related, ser-
vices, it is believed that desirable to have a standardized method for identifying
users. This document proposes syntax for the considerations described here Network Access Identifier
(NAI). Methods for authentication routing or determination of tunnel
server endpoints will
also be of interest to those working on tunneling. addressed in future documents.

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. 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. 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. authentication.

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], in [1], there are now at least four five 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 Network
Access Identifier (NAI) submitted by the user to the NAS in the initial ini-
tial PPP authentication.

This document proposes syntax and semantics for the NAI. It is also expected that this will be of interest for support of roaming as well
as tunneling. For example, references [5] PACs and [6] refer to LACs will
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 as part 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 process of the NAI that is relevant opening a new tunnel, in order

Aboba [Page 2]

INTERNET-DRAFT May 22, 1997

to both determine the
roaming and tunneling communities. tunnel endpoint.

4. Formal Definition of the NAI

As proposed in this specification, document, 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
nancy@eng.bigco.edu

Examples of invalid Network Access Identifiers include:

Aboba [Page 3]

INTERNET-DRAFT 6 March 1997

bigco
howard.edu
fred@bigco.com@smallco.com
bigco!fred@smallco.com
bigco%fred@smallco.com

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. Ding, W. Wang. "Review of Roaming Implemen-
tations." draft-ietf-roamops-imprev-01.txt,
Implementations." Work in progress, draft-ietf-roamops-imprev-02.txt,
Microsoft, Aimnet, i-Pass Alliance, Asiainfo, January, Merit, May, 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]

[3] 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]

[4] 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.

Aboba [Page 3]

INTERNET-DRAFT May 22, 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] 4]

----