[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 2486

     ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                               Microsoft
     Category: Standards Track                              Mark A. Beadles
     <draft-ietf-roamops-nai-08.txt>                       CompuServe, Inc.
     17 December 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 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-08.txt> and  expires June 1, 1998.  Please send  com-
     ments 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 Identi-
     fier (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 corpo-
     rate 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 & Beadles                                               [Page 1]


     INTERNET-DRAFT                                        17 December 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, L2TP, and IPSEC tunnel mode.
     
     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 Identi-
     fier (NAI).   Examples  of  implementations  that  use  the  NAI,  and
     descriptions of its semantics, can be found in [1].
     
     
     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).
     
     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-pro-
               vided corporate network access support.
     
     Tunneling Service
               A tunneling service is any network service enabled  by  tun-
               neling  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).
     
     
     
     
     Aboba & Beadles                                               [Page 2]


     INTERNET-DRAFT                                        17 December 1997
     
     
     3.2.  Purpose
     
     As described in [1], there are now a number of  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 NASes will use  the
     NAI as part of the process of opening a new tunnel, in order to deter-
     mine the tunnel endpoint.
     
     
     3.3.  Notes for Implementors
     
     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
     conforms to the BNF described in [5], and the realm  conforms  to  the
     BNF  described  in  [4],  the  NAI need not be a valid e-mail address.
     While the realm is typically a Fully Qualified Domain Name (FQDN),  it
     is  not required that this be the case. As a result, use of an FQDN as
     the realm does not imply use of DNS for location of the authentication
     server or for authentication routing.
     
     Since  to  date  roaming  has  been  implemented on a relatively small
     scale, existing  implementations  handle  location  of  authentication
     servers  within  a  domain and perform authentication routing based on
     local knowledge expressed in proxy configuration files. The  implemen-
     tations  described  in  [1]  have  not found a need for use of DNS for
     location of the authentication server within a domain,  although  this
     can  be  accomplished via use of the DNS SRV record, described in [6].
     Similarly, existing implementations have not found a need for  dynamic
     routing protocols, or propagation of global routing information.
     
     Please note that NAS vendors may need to modify their devices so as to
     support the NAI as described in this document. Devices  handling  NAIs
     MUST support an NAI length of at least 72 octets.
     
     
     
     4.  Formal definition of the NAI
     
     The   grammar for the NAI is given below. The grammar for the username
     is taken from [5], and the grammar for the realm is based on [4].
     
     <nai>         ::= <username> | <username> "@" <realm>
     
     <username>    ::= <dot-string>
     
     <realm>       ::= <label> | <realm> "." <label>
     
     <label>       ::= <letter> [ [ <ldh-str> ] <let-dig> ]
     
     
     
     Aboba & Beadles                                               [Page 3]


     INTERNET-DRAFT                                        17 December 1997
     
     
     <ldh-str>     ::= <let-dig-hyp> | <ldh-str> <let-dig-hyp>
     
     <let-dig-hyp> ::= <let-dig> | "-"
     
     <dot-string>  ::= <string> | <dot-string> "." <string>
     
     <string>      ::= <char> | <string> <char>
     
     <char>        ::= <c> | "\" <x>
     
     <let-dig>     ::= <letter> | <digit>
     
     <letter>      ::= any one of the 52 alphabetic characters A through Z
                       in upper case and a through z in lower case
     
     <digit>       ::= any one of the ten digits 0 through 9
     
     <c>           ::= any one of the 128 ASCII characters, but not any
                      <special> or <SP>
     
     <x>           ::= any one of the 128 ASCII characters (no exceptions)
     
     <SP>          ::= the space character (ASCII code 32)
     
     <special>     ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
                       | "," | ";" | ":" | "@" | """ | the control
                       characters (ASCII codes 0 through 31 inclusive and
                       127)
     
     Examples of valid Network Access Identifiers include:
     
          fred
          fred_smith@big-co.com
          fred=?#$&*+-/^smith@bigco.com
          fred@bigco.com
          nancy@eng.bigu.edu
          eng!nancy@bigu.edu
          eng%nancy@bigu.edu
     
     Examples of invalid Network Access Identifiers include:
     
          @howard.edu
          fred@bigco.com@smallco.com
          eng:nancy@bigu.edu
          eng;nancy@bigu.edu
          <nancy>@bigu.edu
     
     
     
     5.  Acknowledgements
     
     Thanks to Glen Zorn of Microsoft for many useful discussions  of  this
     problem space.
     
     
     
     
     Aboba & Beadles                                               [Page 4]


     INTERNET-DRAFT                                        17 December 1997
     
     
     6.  References
     
     [1]   B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of Roaming
     Implementations." RFC 2194, Microsoft, Aimnet, i-Pass  Alliance,  Asi-
     ainfo, Merit, September 1997.
     
     [2]   C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote Authenti-
     cation Dial In User Service (RADIUS)." RFC  2138,  Livingston,  Merit,
     Daydreamer, April, 1997.
     
     [3]   C.  Rigney.   "RADIUS  Accounting." RFC 2139, Livingston, April,
     1997.
     
     [4] P. Mockapetris.  "Domain Names  -  Implementation  and  Specifica-
     tion."  RFC 1035, Information Sciences Institute, University of South-
     ern California, November, 1987.
     
     [5] Jonathan B. Postel. "Simple Mail  Transfer  Protocol."   RFC  821,
     Information  Sciences  Institute,  University  of Southern California,
     August, 1982
     
     [6] A. Gulbrandsen, P. Vixie.  "A DNS RR for specifying  the  location
     of  services  (DNS  SRV)."  RFC 2052, Troll Technologies, Vixie Enter-
     prises, October 1996.
     
     
     7.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 425-936-6605
     EMail: bernarda@microsoft.com
     
     Mark A. Beadles
     CompuServe, Inc.
     5000 Britton Rd.
     Hilliard, OH 43026
     
     Phone: 614-723-1941
     EMail: mbeadles@web.compuserve.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Beadles                                               [Page 5]
     

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/