home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-roamops-nai-07.txt < prev    next >
Text File  |  1997-09-09  |  12KB  |  326 lines
  1.  
  2.      ROAMOPS Working Group                                    Bernard Aboba
  3.      INTERNET-DRAFT                                               Microsoft
  4.      Category: Standards Track                              Mark A. Beadles
  5.      <draft-ietf-roamops-nai-07.txt>                       CompuServe, Inc.
  6.      28 August 1997
  7.  
  8.  
  9.                          The Network Access Identifier
  10.  
  11.  
  12.      1.  Status of this Memo
  13.  
  14.      This document is an Internet-Draft.  Internet-Drafts are working docu-
  15.      ments of the Internet Engineering Task Force (IETF),  its  areas,  and
  16.      its  working groups.  Note that other groups may also distribute work-
  17.      ing documents as Internet-Drafts.
  18.  
  19.      Internet-Drafts are draft documents valid for a maximum of six  months
  20.      and  may  be updated, replaced, or obsoleted by other documents at any
  21.      time.  It is inappropriate to use Internet-Drafts as  reference  mate-
  22.      rial or to cite them other than as ``work in progress.''
  23.  
  24.      To  learn  the  current status of any Internet-Draft, please check the
  25.      ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
  26.      Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
  27.      (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  28.  
  29.      The  distribution  of  this memo is unlimited.  It is filed as <draft-
  30.      ietf-roamops-nai-07.txt> and  expires February 1, 1998.   Please  send
  31.      comments to the authors.
  32.  
  33.  
  34.      2.  Abstract
  35.  
  36.      In order to enhance the interoperability of roaming and tunneling ser-
  37.      vices, it is desirable to have a standardized method  for  identifying
  38.      users.   This  document proposes syntax for the Network Access Identi-
  39.      fier (NAI). It is expected that this will be of interest  for  support
  40.      of  roaming as well as tunneling.  'Roaming capability' may be loosely
  41.      defined as the ability to use any one  of  multiple  Internet  service
  42.      providers  (ISPs),  while  maintaining a formal, customer-vendor rela-
  43.      tionship with only one.  Examples of cases  where  roaming  capability
  44.      might be required include ISP 'confederations' and ISP-provided corpo-
  45.      rate network access support.
  46.  
  47.  
  48.      3.  Introduction
  49.  
  50.      Considerable interest has arisen recently in a set  of  features  that
  51.      fit  within  the  general  category of "roaming capability" for dialup
  52.      Internet users.  Interested parties have included:
  53.  
  54.           Regional Internet Service Providers  (ISPs)  operating  within  a
  55.           particular  state  or  province, looking to combine their efforts
  56.  
  57.  
  58.  
  59.      Aboba & Beadles                                               [Page 1]
  60.  
  61.  
  62.  
  63.  
  64.  
  65.      INTERNET-DRAFT                                          28 August 1997
  66.  
  67.  
  68.           with those of other regional providers to  offer  dialup  service
  69.           over a wider area.
  70.  
  71.           National  ISPs  wishing to combine their operations with those of
  72.           one or more ISPs in another nation to  offer  more  comprehensive
  73.           dialup service in a group of countries or on a continent.
  74.  
  75.           Businesses  desiring  to  offer  their  employees a comprehensive
  76.           package of dialup services on a global basis.  Those services may
  77.           include  Internet  access  as  well as secure access to corporate
  78.           intranets via a Virtual Private Network (VPN), enabled by tunnel-
  79.           ing protocols such as PPTP, L2F and L2TP.
  80.  
  81.      In order to enhance the interoperability of roaming and tunneling ser-
  82.      vices, it is desirable to have a standardized method  for  identifying
  83.      users.   This  document proposes syntax for the Network Access Identi-
  84.      fier (NAI).   Examples  of  implementations  that  use  the  NAI,  and
  85.      descriptions of its semantics, can be found in [1].
  86.  
  87.  
  88.      3.1.  Terminology
  89.  
  90.      This document frequently uses the following terms:
  91.  
  92.      Network Access Identifier
  93.                The  Network Access Identifier (NAI) is the userID submitted
  94.                by the client during PPP  authentication.  In  roaming,  the
  95.                purpose  of  the  NAI  is to identify the user as well as to
  96.                assist in the routing of the authentication request.  Please
  97.                note  that  the  NAI  may not necessarily be the same as the
  98.                user's e-mail address or the userID submitted in an applica-
  99.                tion layer authentication.
  100.  
  101.      Network Access Server
  102.                The  Network  Access Server (NAS) is the device that clients
  103.                dial in order to get access to the network. In  PPTP  termi-
  104.                nology  this  is referred to as the PPTP Access Concentrator
  105.                (PAC), and in L2TP terminology, it is  referred  to  as  the
  106.                L2TP Access Concentrator (LAC).
  107.  
  108.      Roaming Capability
  109.                Roaming  capability can be loosely defined as the ability to
  110.                use any one of multiple Internet service  providers  (ISPs),
  111.                while  maintaining  a  formal,  customer-vendor relationship
  112.                with only one. Examples of cases  where  roaming  capability
  113.                might  be required include ISP "confederations" and ISP-pro-
  114.                vided corporate network access support.
  115.  
  116.      Tunneling Service
  117.                A tunneling service is any network service enabled  by  tun-
  118.                neling  protocols  such as PPTP, L2F, and L2TP.  One example
  119.                of  a  tunneling  service  is  secure  access  to  corporate
  120.                intranets via a Virtual Private Network (VPN).
  121.  
  122.  
  123.  
  124.  
  125.      Aboba & Beadles                                               [Page 2]
  126.  
  127.  
  128.  
  129.  
  130.  
  131.      INTERNET-DRAFT                                          28 August 1997
  132.  
  133.  
  134.      3.2.  Purpose
  135.  
  136.      As described in [1], there are now at least five services implementing
  137.      dialup roaming, and the number of Internet Service Providers  involved
  138.      in roaming consortia is increasing rapidly.
  139.  
  140.      In  order  to be able to offer roaming capability, one of the require-
  141.      ments is to be able to identify the user's home authentication server.
  142.      For  use  in  roaming,  this  function is accomplished via the Network
  143.      Access Identifier (NAI) submitted by the user to the NAS in  the  ini-
  144.      tial  PPP  authentication. It is also expected that NASes will use the
  145.      NAI as part of the process of opening a new tunnel, in order to deter-
  146.      mine the tunnel endpoint.
  147.  
  148.  
  149.      3.3.  Notes for Implementors
  150.  
  151.      As  proposed in this document, the Network Access Identifier is of the
  152.      form user@realm. Please note that while the user portion  of  the  NAI
  153.      conforms  to  the  BNF described in [5], and the realm conforms to the
  154.      BNF described in [4], the NAI need not  be  a  valid  e-mail  address.
  155.      While  the realm is typically a Fully Qualified Domain Name (FQDN), it
  156.      is not required that this be the case. As a result, use of an FQDN  as
  157.      the realm does not imply use of DNS for location of the authentication
  158.      server or for authentication routing.
  159.  
  160.      Since to date roaming has  been  implemented  on  a  relatively  small
  161.      scale,  existing  implementations  handle  location  of RADIUS servers
  162.      within a domain and perform  authentication  routing  based  on  local
  163.      knowledge  expressed in proxy configuration files. To date implementa-
  164.      tions have not found a need for use of DNS for location of the  RADIUS
  165.      server  within  a domain, although this can be accomplished via use of
  166.      the DNS SRV record, described in [6].  Similarly, existing implementa-
  167.      tions have not found a need for dynamic routing protocols, or propaga-
  168.      tion of global routing information.
  169.  
  170.      Please note that NAS vendors may need to modify their devices so as to
  171.      support  the  NAI as described in this document. Devices handling NAIs
  172.      MUST support an NAI length of at least 72 octets.
  173.  
  174.  
  175.  
  176.      4.  Formal definition of the NAI
  177.  
  178.      The  grammar for the NAI is given below. The grammar for the  username
  179.      is taken from [5], and the grammar for the realm is based on [4].
  180.  
  181.      <nai>         ::= <username> | <username> "@" <realm>
  182.  
  183.      <username>    ::= <dot-string>
  184.  
  185.      <realm>       ::= <label> | <realm> "." <label>
  186.  
  187.      <label>       ::= <letter> [ [ <ldh-str> ] <let-dig> ]
  188.  
  189.  
  190.  
  191.      Aboba & Beadles                                               [Page 3]
  192.  
  193.  
  194.  
  195.  
  196.  
  197.      INTERNET-DRAFT                                          28 August 1997
  198.  
  199.  
  200.      <ldh-str>     ::= <let-dig-hyp> | <ldh-str> <let-dig-hyp>
  201.  
  202.      <let-dig-hyp> ::= <let-dig> | "-"
  203.  
  204.      <dot-string>  ::= <string> | <dot-string> "." <string>
  205.  
  206.      <string>      ::= <char> | <string> <char>
  207.  
  208.      <char>        ::= <c> | "\" <x>
  209.  
  210.      <let-dig>     ::= <letter> | <digit>
  211.  
  212.      <letter>      ::= any one of the 52 alphabetic characters A through Z
  213.                        in upper case and a through z in lower case
  214.  
  215.      <digit>       ::= any one of the ten digits 0 through 9
  216.  
  217.      <c>           ::= any one of the 128 ASCII characters, but not any
  218.                       <special> or <SP>
  219.  
  220.      <x>           ::= any one of the 128 ASCII characters (no exceptions)
  221.  
  222.      <SP>          ::= the space character (ASCII code 32)
  223.  
  224.      <special>     ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
  225.                        | "," | ";" | ":" | "@" | """ | the control
  226.                        characters (ASCII codes 0 through 31 inclusive and
  227.                        127)
  228.  
  229.      Examples of valid Network Access Identifiers include:
  230.  
  231.           fred
  232.           fred_smith@big-co.com
  233.           fred=?#$&*+-/^smith@bigco.com
  234.           fred@bigco.com
  235.           nancy@eng.bigu.edu
  236.           eng!nancy@bigu.edu
  237.           eng%nancy@bigu.edu
  238.  
  239.      Examples of invalid Network Access Identifiers include:
  240.  
  241.           @howard.edu
  242.           fred@bigco.com@smallco.com
  243.           eng:nancy@bigu.edu
  244.  
  245.  
  246.      5.  Acknowledgements
  247.  
  248.      Thanks  to  Glen Zorn of Microsoft for many useful discussions of this
  249.      problem space.
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.      Aboba & Beadles                                               [Page 4]
  258.  
  259.  
  260.  
  261.  
  262.  
  263.      INTERNET-DRAFT                                          28 August 1997
  264.  
  265.  
  266.      6.  References
  267.  
  268.      [1]  B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of  Roaming
  269.      Implementations."  Internet  draft  (work  in  progress),  draft-ietf-
  270.      roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass  Alliance,  Asiainfo,
  271.      Merit, June 1997.
  272.  
  273.      [2]   C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote Authenti-
  274.      cation Dial In User Service (RADIUS)." RFC  2138,  Livingston,  Merit,
  275.      Daydreamer, April, 1997.
  276.  
  277.      [3]   C.  Rigney.   "RADIUS  Accounting." RFC 2139, Livingston, April,
  278.      1997.
  279.  
  280.      [4] P. Mockapetris.  "Domain Names  -  Implementation  and  Specifica-
  281.      tion."  RFC 1035, Information Sciences Institute, University of South-
  282.      ern California, November, 1987.
  283.  
  284.      [5] Jonathan B. Postel. "Simple Mail  Transfer  Protocol."   RFC  821,
  285.      Information  Sciences  Institute,  University  of Southern California,
  286.      August, 1982
  287.  
  288.      [6] A. Gulbrandsen, P. Vixie.  "A DNS RR for specifying  the  location
  289.      of  services  (DNS  SRV)."  RFC 2052, Troll Technologies, Vixie Enter-
  290.      prises, October 1996.
  291.  
  292.  
  293.      7.  Authors' Addresses
  294.  
  295.      Bernard Aboba
  296.      Microsoft Corporation
  297.      One Microsoft Way
  298.      Redmond, WA 98052
  299.  
  300.      Phone: 425-936-6605
  301.      EMail: bernarda@microsoft.com
  302.  
  303.      Mark A. Beadles
  304.      CompuServe, Inc.
  305.      5000 Britton Rd.
  306.      Hilliard, OH 43026
  307.  
  308.      Phone: 614-723-1941
  309.      EMail: mbeadles@web.compuserve.com
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.      Aboba & Beadles                                               [Page 5]
  324.  
  325.  
  326.