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-06.txt < prev    next >
Text File  |  1997-07-23  |  11KB  |  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-06.txt>                       CompuServe, Inc.
  6.      22 July 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-06.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                                                         [Page 1]
  60.  
  61.  
  62.  
  63.  
  64.  
  65.      INTERNET-DRAFT                                            22 July 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).
  85.  
  86.  
  87.      3.1.  Terminology
  88.  
  89.      This document frequently uses the following terms:
  90.  
  91.      Network Access Identifier
  92.                The Network Access Identifier (NAI) is the userID  submitted
  93.                by  the  client  during  PPP authentication. In roaming, the
  94.                purpose of the NAI is to identify the user  as  well  as  to
  95.                assist in the routing of the authentication request.  Please
  96.                note that the NAI may not necessarily be  the  same  as  the
  97.                user's e-mail address or the userID submitted in an applica-
  98.                tion layer authentication.
  99.  
  100.      Network Access Server
  101.                The Network Access Server (NAS) is the device  that  clients
  102.                dial  in  order to get access to the network. In PPTP termi-
  103.                nology this is referred to as the PPTP  Access  Concentrator
  104.                (PAC),  and  in  L2TP  terminology, it is referred to as the
  105.                L2TP Access Concentrator (LAC).
  106.  
  107.  
  108.  
  109.      3.2.  Purpose
  110.  
  111.      As described in [1], there are now at least five services implementing
  112.      dialup  roaming, and the number of Internet Service Providers involved
  113.      in roaming consortia is increasing rapidly.
  114.  
  115.      In order to be able to offer roaming capability, one of  the  require-
  116.      ments is to be able to identify the user's home authentication server.
  117.      For use in roaming, this function  is  accomplished  via  the  Network
  118.      Access  Identifier  (NAI) submitted by the user to the NAS in the ini-
  119.      tial PPP authentication. It is also expected that NASes will  use  the
  120.      NAI as part of the process of opening a new tunnel, in order to deter-
  121.      mine the tunnel endpoint.
  122.  
  123.  
  124.  
  125.      Aboba                                                         [Page 2]
  126.  
  127.  
  128.  
  129.  
  130.  
  131.      INTERNET-DRAFT                                            22 July 1997
  132.  
  133.  
  134.      As proposed in this document, the Network Access Identifier is of  the
  135.      form  user@realm.  Please  note that while the user portion of the NAI
  136.      conforms to the BNF described in [5], and the realm  conforms  to  the
  137.      BNF  described  in  [4],  the  NAI need not be a valid e-mail address.
  138.      While the realm is typically a Fully Qualified Domain Name (FQDN),  it
  139.      is  not required that this be the case. As a result, use of an FQDN as
  140.      the realm does not imply use of DNS for location of the RADIUS  server
  141.      or for authentication routing.
  142.  
  143.      Since  to  date  roaming  has  been  implemented on a relatively small
  144.      scale, existing implementations  handle  location  of  RADIUS  servers
  145.      within  a  domain  and  perform  authentication routing based on local
  146.      knowledge expressed in proxy configuration files. To date  implementa-
  147.      tions  have not found a need for use of DNS for location of the RADIUS
  148.      server within a domain, although this can be accomplished via  use  of
  149.      the DNS SRV record, described in [6].  Similarly, existing implementa-
  150.      tions have not found a need for dynamic routing protocols, or propaga-
  151.      tion of global routing information.
  152.  
  153.      Please note that NAS vendors may need to modify their devices so as to
  154.      support the NAI as described in this document. Devices  handling  NAIs
  155.      MUST support an NAI length of at least 72 octets.
  156.  
  157.  
  158.      4.  Formal definition of the NAI
  159.  
  160.      The   grammar for the NAI is given below. The grammar for the username
  161.      is taken from [5], and the grammar for the realm is based on [4].
  162.  
  163.      <nai>         ::= <username> | <username> "@" <realm>
  164.  
  165.      <username>    ::= <dot-string>
  166.  
  167.      <realm>       ::= <label> | <realm> "." <label>
  168.  
  169.      <label>       ::= <letter> [ [ <ldh-str> ] <let-dig> ]
  170.  
  171.      <ldh-str>     ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
  172.  
  173.      <let-dig-hyp> ::= <let-dig> | "-"
  174.  
  175.      <dot-string>  ::= <string> | <string> "." <dot-string>
  176.  
  177.      <string>      ::= <char> | <char> <string>
  178.  
  179.      <char>        ::= <c> | "
  180.  
  181.      <let-dig>     ::= <letter> | <digit>
  182.  
  183.      <letter>      ::= any one of the 52 alphabetic characters A through Z
  184.                        in upper case and a through z in lower case
  185.  
  186.      <digit>       ::= any one of the ten digits 0 through 9
  187.  
  188.  
  189.  
  190.  
  191.      Aboba                                                         [Page 3]
  192.  
  193.  
  194.  
  195.  
  196.  
  197.      INTERNET-DRAFT                                            22 July 1997
  198.  
  199.  
  200.      <c>           ::= any one of the 128 ASCII characters, but not any
  201.                       <special> or <SP>
  202.  
  203.      <x>           ::= any one of the 128 ASCII characters (no exceptions)
  204.  
  205.      <SP>          ::= the space character (ASCII code 32)
  206.  
  207.      <special>     ::= "<" | ">" | "(" | ")" | "[" | "]" | "
  208.                        | "," | ";" | ":" | "@"  """ | the control
  209.                        characters (ASCII codes 0 through 31 inclusive and
  210.                        127)
  211.  
  212.      Examples of valid Network Access Identifiers include:
  213.  
  214.           fred
  215.           fred_smith@big-co.com
  216.           fred=?#$&*+-/^smith@bigco.com
  217.           fred@bigco.com
  218.           nancy@eng.bigu.edu
  219.           eng!nancy@bigu.edu
  220.           eng%nancy@bigu.edu
  221.  
  222.      Examples of invalid Network Access Identifiers include:
  223.  
  224.           howard.edu
  225.           fred@bigco.com@smallco.com
  226.           eng:nancy@bigu.edu
  227.  
  228.  
  229.      5.  Acknowledgements
  230.  
  231.      Thanks to Glen Zorn of Microsoft for many useful discussions  of  this
  232.      problem space.
  233.  
  234.  
  235.      6.  References
  236.  
  237.      [1]   B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of Roaming
  238.      Implementations."  Internet  draft  (work  in  progress),  draft-ietf-
  239.      roamops-imprev-04.txt,  Microsoft,  Aimnet, i-Pass Alliance, Asiainfo,
  240.      Merit, June 1997.
  241.  
  242.      [2]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
  243.      cation  Dial  In  User Service (RADIUS)." RFC 2138, Livingston, Merit,
  244.      Daydreamer, April, 1997.
  245.  
  246.      [3]  C. Rigney.  "RADIUS Accounting."  RFC  2139,  Livingston,  April,
  247.      1997.
  248.  
  249.      [4]  P.  Mockapetris.   "Domain  Names - Implementation and Specifica-
  250.      tion."  RFC 883, Information Sciences Institute, University of  South-
  251.      ern California, November, 1983.
  252.  
  253.      [5]  Jonathan  B.  Postel.  "Simple Mail Transfer Protocol."  RFC 821,
  254.  
  255.  
  256.  
  257.      Aboba                                                         [Page 4]
  258.  
  259.  
  260.  
  261.  
  262.  
  263.      INTERNET-DRAFT                                            22 July 1997
  264.  
  265.  
  266.      Information Sciences Institute,  University  of  Southern  California,
  267.      August, 1982
  268.  
  269.      [6]  A.  Gulbrandsen, P. Vixie.  "A DNS RR for specifying the location
  270.      of services (DNS SRV)." RFC 2052,  Troll  Technologies,  Vixie  Enter-
  271.      prises, October 1996.
  272.  
  273.  
  274.      7.  Authors' Addresses
  275.  
  276.      Bernard Aboba
  277.      Microsoft Corporation
  278.      One Microsoft Way
  279.      Redmond, WA 98052
  280.  
  281.      Phone: 425-936-6605
  282.      EMail: bernarda@microsoft.com
  283.  
  284.      Mark A. Beadles
  285.      CompuServe, Inc.
  286.      5000 Britton Rd.
  287.      Hilliard, OH 43026
  288.  
  289.      Phone: 614-723-1941
  290.      EMail: mbeadles@web.compuserve.com
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.      Aboba                                                         [Page 5]
  324.  
  325.  
  326.