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-01.txt < prev    next >
Text File  |  1997-02-27  |  11KB  |  329 lines
  1.  
  2.  
  3.  
  4.  
  5.      ROAMOPS Working Group                                    Bernard Aboba
  6.      INTERNET-DRAFT                                   Microsoft Corporation
  7.      <draft-ietf-roamops-nai-01.txt>
  8.  
  9.  
  10.                          The Network Access Identifier
  11.  
  12.  
  13.      1.  Status of this Memo
  14.  
  15.      This document is an Internet-Draft.  Internet-Drafts are working docu-
  16.      ments of the Internet Engineering Task Force (IETF),  its  areas,  and
  17.      its  working groups.  Note that other groups may also distribute work-
  18.      ing documents as Internet-Drafts.
  19.  
  20.      Internet-Drafts are draft documents valid for a maximum of six  months
  21.      and  may  be updated, replaced, or obsoleted by other documents at any
  22.      time.  It is inappropriate to use Internet-Drafts as  reference  mate-
  23.      rial or to cite them other than as ``work in progress.''
  24.  
  25.      To  learn  the  current status of any Internet-Draft, please check the
  26.      ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
  27.      Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
  28.      (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  29.  
  30.      The  distribution  of  this memo is unlimited.  It is filed as <draft-
  31.      ietf-roamops-nai-01.txt> and  expires September 1, 1997.  Please  send
  32.      comments to the authors.
  33.  
  34.  
  35.      2.  Abstract
  36.  
  37.      This document describes issues relating to user identification in pro-
  38.      vision of "roaming capability" for dialup  Internet  users.   "Roaming
  39.      capability"  may  be  loosely defined as the ability to use any one of
  40.      multiple Internet service providers (ISPs), while maintaining  a  for-
  41.      mal,  customer-vendor  relationship  with only one.  Examples of cases
  42.      where roaming capability might be  required  include  ISP  "confedera-
  43.      tions" and ISP-provided corporate network access support.
  44.  
  45.  
  46.      3.  Introduction
  47.  
  48.      Considerable  interest  has  arisen recently in a set of features that
  49.      fit within the general category of  "roaming  capability"  for  dialup
  50.      Internet users.  Interested parties have included:
  51.  
  52.           Regional  Internet  Service  Providers  (ISPs) operating within a
  53.           particular state or province, looking to  combine  their  efforts
  54.           with  those  of  other regional providers to offer dialup service
  55.           over a wider area.
  56.  
  57.           National ISPs wishing to combine their operations with  those  of
  58.           one  or  more  ISPs in another nation to offer more comprehensive
  59.  
  60.  
  61.  
  62.      Aboba                                                         [Page 1]
  63.  
  64.  
  65.  
  66.  
  67.  
  68.      INTERNET-DRAFT                                        25 February 1997
  69.  
  70.  
  71.           dialup service in a group of countries or on a continent.
  72.  
  73.           Businesses desiring to  offer  their  employees  a  comprehensive
  74.           package of dialup services on a global basis.  Those services may
  75.           include Internet access as well as  secure  access  to  corporate
  76.           intranets via a Virtual Private Network (VPN), enabled by tunnel-
  77.           ing protocols such as PPTP, L2F and L2TP.
  78.  
  79.      This document focuses on issues of  user  identification  for  use  in
  80.      roaming  services.   However,  since roaming and tunneling are closely
  81.      related, it is believed that the considerations  described  here  will
  82.      also be of interest to those working on tunneling.
  83.  
  84.  
  85.      3.1.  Terminology
  86.  
  87.      This document frequently uses the following terms:
  88.  
  89.      Network Access Identifier
  90.                The  Network Access Identifier (NAI) is the userID submitted
  91.                by the client during the PPP negotiation.  In  roaming,  the
  92.                purpose  of  the  NAI  is to identify the user as well as to
  93.                assist in the routing  of  the  authentication  request.  As
  94.                such,  the  NAI  may  be  presented either in the form of an
  95.                authentication route, or a pointer to such a  route.  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  (i.e.  HTTP authentication). In
  99.                order to avoid confusion on  this  point,  a  new  term  was
  100.                coined.
  101.  
  102.      Network Access Server
  103.                The  Network  Access Server (NAS) is the device that clients
  104.                dial in order to get access to the network. In  PPTP  termi-
  105.                nology  this  is referred to as the PPTP Access Concentrator
  106.                (PAC), and in L2TP terminology, it is  referred  to  as  the
  107.                L2TP Access Concentrator (LAC).
  108.  
  109.      RADIUS server
  110.                This  is  a  server which provides for authentication/autho-
  111.                rization via the protocol described in [3], and for account-
  112.                ing as described in [4].
  113.  
  114.      RADIUS proxy
  115.                In order to provide for the routing of RADIUS authentication
  116.                and accounting requests, a RADIUS proxy may employed. To the
  117.                NAS,  the  RADIUS  proxy acts as a RADIUS server, and to the
  118.                RADIUS server, the proxy acts as a RADIUS client.
  119.  
  120.  
  121.      3.2.  Purpose
  122.  
  123.      As described in[1], there are now at least four services  implementing
  124.      dialup  roaming, and the number of Internet Service Providers involved
  125.  
  126.  
  127.  
  128.      Aboba                                                         [Page 2]
  129.  
  130.  
  131.  
  132.  
  133.  
  134.      INTERNET-DRAFT                                        25 February 1997
  135.  
  136.  
  137.      in roaming consortia is increasing rapidly.
  138.  
  139.      In order to be able to offer roaming capability, one of  the  require-
  140.      ments is to be able to identify the user's home authentication server.
  141.      For use in roaming, this function is accomplished via the NAI  submit-
  142.      ted by the user to the NAS in the initial PPP authentication.
  143.  
  144.      This  document  proposes  syntax  and  semantics  for  the  NAI. It is
  145.      expected that this will be of interest for support of roaming as  well
  146.      as tunneling.  For example, references [5] and [6] refer to use of the
  147.      NAI in determining the tunnel endpoint. However, these  references  do
  148.      not  provide  guidelines  for  how  RADIUS  or tunnel routing is to be
  149.      accomplished. In order to avoid the  possibility  of  conflicting  and
  150.      non-interoperable implementations, references [7] and [8] describe how
  151.      RADIUS and tunneling protocols may be integrated. This  document  pro-
  152.      vides  guidance  in  the  use  of the NAI that is relevant to both the
  153.      roaming and tunneling communities.
  154.  
  155.  
  156.      4.  Formal Definition of the NAI
  157.  
  158.      As proposed in this specification, the Network Access Identifer is  of
  159.      the  form  user@domain,  where  the domain is a fully qualified domain
  160.      name (FQDN). The syntax for the NAI is independent of the method  used
  161.      to route the authentication.
  162.  
  163.      In  order  to support the determination of the existence of a business
  164.      relationship between the local ISP and the home  domain,  one  of  two
  165.      methods  may  be used. If the number of domains to be served is small,
  166.      then it is possible to provide business relationship  information  via
  167.      the  authentication proxy configuration file. If the number of domains
  168.      to be served is large, then a more scalable mechanism is  recommended,
  169.      such  as  use  of  the  DNS  Roaming  Relationship resource record, as
  170.      described in [10]. However, even if use of  the  DNS  is  enabled,  an
  171.      authentication proxy will typically consult its configuration file for
  172.      information on business relationships, prior to retrieving information
  173.      via DNS.
  174.  
  175.  
  176.      4.1.  BNF for the NAI
  177.  
  178.      The  grammar for the NAI is given below, using the augmented BNF nota-
  179.      tion described in reference [9].
  180.  
  181.      NAI = USERNAME "@" FQDN
  182.      FQDN =    token "."  token *[ "." token ]
  183.      USERNAME = token
  184.  
  185.      Examples of valid Network Access Identifiers include:
  186.  
  187.           fred@bigco.com
  188.           nancy@howard.edu
  189.  
  190.      Examples of invalid Network Access Identifiers include:
  191.  
  192.  
  193.  
  194.      Aboba                                                         [Page 3]
  195.  
  196.  
  197.  
  198.  
  199.  
  200.      INTERNET-DRAFT                                        25 February 1997
  201.  
  202.  
  203.           bigco
  204.           howard.edu
  205.  
  206.  
  207.      5.  Acknowledgements
  208.  
  209.      Thanks to Glen Zorn of Microsoft for many useful discussions  of  this
  210.      problem space.
  211.  
  212.  
  213.      6.  References
  214.  
  215.      [1]  B. Aboba, J. Lu, J. Alsop, J. Ding.  "Review of Roaming Implemen-
  216.      tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet,  i-Pass
  217.      Alliance, Asiainfo, January, 1997.
  218.  
  219.      [2]   B.  Aboba,  G. Zorn.  "Dialup Roaming Requirements." draft-ietf-
  220.      roamops-roamreq-02.txt, Microsoft, January, 1997.
  221.  
  222.      [3]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
  223.      cation  Dial  In  User Service (RADIUS)." RFC 2058, Livingston, Merit,
  224.      Daydreamer, January, 1997.
  225.  
  226.      [4]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,
  227.      1997.
  228.  
  229.      [5]  K.  Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J.
  230.      Valencia, W. Verthein.  "Layer Two Tunneling Protocol -- L2TP." draft-
  231.      ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996.
  232.  
  233.      [6]  K.  Hamzeh,  G.  S.  Pall,  J. Taarud, W. Verthein, W. A. Little.
  234.      "Point-to-Point  Tunneling  Protocol  --   PPTP."   draft-ietf-pppext-
  235.      pptp-00.txt, Ascend Communications, June, 1996.
  236.  
  237.      [7]  G. Zorn.  "RADIUS Attributes for Tunnel Protocol Support." draft-
  238.      ietf-radius-tunnel-auth-00.txt, Microsoft Corporation, November, 1996.
  239.  
  240.      [8]  B.  Aboba.   "Implementation  of Mandatory Tunneling via RADIUS."
  241.      draft-ietf-radius-tunnel-imp-00.txt, Microsoft Corporation,  February,
  242.      1997.
  243.  
  244.      [9]   R.  Fielding,  et al.  "Hypertext Transfer Protocol - HTTP/1.1."
  245.      draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
  246.  
  247.      [10] B. Aboba.  "The Roaming Relationship (RR)  Record  in  the  DNS."
  248.      draft-ietf-roamops-dnsrr-00.txt,   Microsoft   Corporation,  February,
  249.      1997.
  250.  
  251.  
  252.  
  253.      7.  Authors' Addresses
  254.  
  255.      Bernard Aboba
  256.      Microsoft Corporation
  257.  
  258.  
  259.  
  260.      Aboba                                                         [Page 4]
  261.  
  262.  
  263.  
  264.  
  265.  
  266.      INTERNET-DRAFT                                        25 February 1997
  267.  
  268.  
  269.      One Microsoft Way
  270.      Redmond, WA 98052
  271.  
  272.      Phone: 206-936-6605
  273.      EMail: bernarda@microsoft.com
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  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.  
  324.  
  325.  
  326.      Aboba                                                         [Page 5]
  327.  
  328.  
  329.