[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-11.txt>            CompuServe Network Services
     22 July 1998
     
     
                         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   ftp.ietf.org   (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-11.txt> and expires January 15,  1999.   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 Identi-
     fier (NAI), the userID submitted by the client during PPP  authentica-
     tion.  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
     
     
     
     Aboba & Beadles                                               [Page 1]
     

     INTERNET-DRAFT                                            22 July 1998
     
     
          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
          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                                            22 July 1998
     
     
     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], the BNF of the realm portion
     allows the realm to begin with a digit, which is not permitted by  the
     BNF  described  in  [4]. This change was made to reflect current prac-
     tice; although not permitted by the BNF described in [4],  FQDNs  such
     as 3com.com are commonly used, and accepted by current software.
     
     While  the realm is typically a Fully Qualified Domain Name (FQDN), it
     is not required that this be the case, and thus the NAI need not be  a
     valid  e-mail  address.  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, described in ABNF as docu-
     mented in [7].  The grammar for the username is taken  from  [5],  and
     the grammar for the realm is an updated version of [4].
     
     nai         = username / ( username "@" realm )
     
     
     
     Aboba & Beadles                                               [Page 3]
     

     INTERNET-DRAFT                                            22 July 1998
     
     
     username    = dot-string
     
     realm       = label / ( realm "." label )
     
     label       = let-dig *(ldh-str)
     
     ldh-str     = *( Alpha / Digit / "-" ) let-dig
     
     dot-string  = string / ( dot-string "." string )
     
     string      = char / ( string char )
     
     char        = c / ( "\" x )
     
     let-dig     = Alpha / Digit
     
     Alpha       = %x41-5A / %x61-7A   ; A-Z / a-z
     
     Digit       = %x30-39  ;0-9
     
     c           = < any one of the 128 ASCII characters, but
                    not any special or SP >
     
     x           = %x00-7F
                   ; all 127 ASCII characters, no exception
     
     SP          = %x20 ; Space character
     
     special     = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."
                    / "," / ";" / ":" / "@" / """ / Ctl
     
     Ctl         = %x00-1F / %x7F
                   ; the control characters (ASCII codes 0 through 31
                   ; inclusive and 127)
     
     Examples of valid Network Access Identifiers include:
     
          fred@foo
          fred@3com.com
          fred@foo-9.com
          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:
     
          fred@foo_9.com
          @howard.edu
          fred@bigco.com@smallco.com
          eng:nancy@bigu.edu
          eng;nancy@bigu.edu
     
     
     
     Aboba & Beadles                                               [Page 4]
     

     INTERNET-DRAFT                                            22 July 1998
     
     
          <nancy>@bigu.edu
     
     
     5.  Security Considerations
     
     Since  an NAI reveals the home affiliation of a user, it may assist an
     attacker in further probing the username space. Typically this problem
     is of most concern in protocols which transmit the user name in clear-
     text across the Internet, such as in RADIUS, described in [2] and [3].
     In  order to prevent snooping of the user name, protocols may use con-
     fidentiality services provided by IPSEC, described in [8].
     
     
     6.  Acknowledgements
     
     Thanks to Glen Zorn of Microsoft for many useful discussions  of  this
     problem space.
     
     
     7.  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] J. 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]  D.  Crocker,  P.  Overrell.  "Augmented BNF for Syntax Specifica-
     tions: ABNF."  RFC 2234,  Internet  Mail  Consortium,  Demon  Internet
     Ltd., November 1997.
     
     [8]  R.  Atkinson.  "Security Architecture for the Internet Protocol."
     RFC 1825, Naval Research Laboratory, August 1995.
     
     
     
     
     
     
     
     
     Aboba & Beadles                                               [Page 5]
     

     INTERNET-DRAFT                                            22 July 1998
     
     
     8.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 425-936-6605
     EMail: bernarda@microsoft.com
     
     Mark A. Beadles
     CompuServe Network Services
     5000 Britton Rd.
     Hilliard, OH 43026
     
     Phone: 614-723-1941
     EMail: mbeadles@web.compuserve.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Beadles                                               [Page 6]
     

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