ROAMOPS Working Group                                    Bernard Aboba
INTERNET-DRAFT                                               Microsoft
Category: Standards Track
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
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  (US   East   Coast),
(Europe), (US West Coast), or (Pacific Rim).

The distribution of this memo is unlimited.  It is  filed  as  <draft-
ietf-roamops-nai-03.txt>  and   expires  January 1, 1998.  Please send
comments to the authors.

2.  Abstract

In order to enhance the interoperability of roaming and tunneling ser-
vices,  it  is desirable to have a standardized method for 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  formal,  customer-vendor  rela-
tionship  with  only  one.  Examples of cases where roaming capability
might be required include ISP "confederations" and  ISP-provided  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
     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.

In order to enhance the interoperability of roaming and tunneling ser-
vices,  it  is desirable to have a standardized method for identifying
users. This document proposes syntax for the Network Access Identifier
(NAI).  Methods  for authentication routing or determination of tunnel
server endpoints will be 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  PPP 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 userID submitted in an applica-
          tion layer 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).

3.2.  Purpose

As described in [1], there are now at least five services implementing
dialup  roaming, 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  require-
ments 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 ini-
tial PPP authentication. It is also expected that PACs and  LACs  will
use  the  NAI as part of the process of opening a new tunnel, in order

Aboba                                                         [Page 2]

INTERNET-DRAFT                                            May 22, 1997

to determine the tunnel endpoint.

4.  Formal Definition of the NAI

As proposed in this document, the Network Access Identifer is  of  the
form  user@domain,  where  the domain is a fully qualified domain name

4.1.  BNF for the NAI

The grammar for the NAI is given below, using the augmented BNF  nota-
tion described in reference [9].

FQDN =    token "."  token *[ "." token ]
USERNAME = token

Examples of valid Network Access Identifiers include:

Examples of invalid Network Access Identifiers include:


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

[2]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
cation  Dial  In  User Service (RADIUS)." RFC 2058, Livingston, Merit,
Daydreamer, January, 1997.

[3]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,

[4]  R. Fielding, et al.  "Hypertext Transfer  Protocol  -  HTTP/1.1."
draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.

Aboba                                                         [Page 3]

INTERNET-DRAFT                                            May 22, 1997

7.  Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 206-936-6605

Aboba                                                         [Page 4]