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-03.txt < prev    next >
Text File  |  1997-05-22  |  7KB  |  264 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. ROAMOPS Working Group                                    Bernard Aboba
  7. INTERNET-DRAFT                                               Microsoft
  8. Category: Standards Track
  9. <draft-ietf-roamops-nai-03.txt>
  10. May 22, 1997
  11.  
  12.  
  13.                     The Network Access Identifier
  14.  
  15.  
  16. 1.  Status of this Memo
  17.  
  18. This document is an Internet-Draft.  Internet-Drafts are working docu-
  19. ments  of  the  Internet Engineering Task Force (IETF), its areas, and
  20. its working groups.  Note that other groups may also distribute  work-
  21. ing documents as Internet-Drafts.
  22.  
  23. Internet-Drafts are draft documents valid for a maximum of six  months
  24. and  may  be updated, replaced, or obsoleted by other documents at any
  25. time.   It  is  inappropriate  to  use  Internet-Drafts  as  reference
  26. material or to cite them other than as ``work in progress.''
  27.  
  28. To learn the current status of any Internet-Draft,  please  check  the
  29. ``1id-abstracts.txt''  listing contained in the Internet-Drafts Shadow
  30. Directories  on  ds.internic.net  (US   East   Coast),   nic.nordu.net
  31. (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  32.  
  33. The distribution of this memo is unlimited.  It is  filed  as  <draft-
  34. ietf-roamops-nai-03.txt>  and   expires  January 1, 1998.  Please send
  35. comments to the authors.
  36.  
  37.  
  38. 2.  Abstract
  39.  
  40. In order to enhance the interoperability of roaming and tunneling ser-
  41. vices,  it  is desirable to have a standardized method for identifying
  42. users. This document proposes syntax for the Network Access Identifier
  43. (NAI).  It  is  expected  that this will be of interest for support of
  44. roaming as well as tunneling.  "Roaming  capability"  may  be  loosely
  45. defined  as  the  ability  to use any one of multiple Internet service
  46. providers (ISPs), while maintaining a  formal,  customer-vendor  rela-
  47. tionship  with  only  one.  Examples of cases where roaming capability
  48. might be required include ISP "confederations" and  ISP-provided  cor-
  49. porate network access support.
  50.  
  51.  
  52. 3.  Introduction
  53.  
  54. Considerable interest has arisen recently in a set  of  features  that
  55. fit  within  the  general  category of "roaming capability" for dialup
  56. Internet users.  Interested parties have included:
  57.  
  58.      Regional Internet Service Providers  (ISPs)  operating  within  a
  59.      particular  state  or  province, looking to combine their efforts
  60.  
  61.  
  62.  
  63. Aboba                                                         [Page 1]
  64.  
  65.  
  66.  
  67.  
  68.  
  69. INTERNET-DRAFT                                            May 22, 1997
  70.  
  71.  
  72.      with those of other regional providers to  offer  dialup  service
  73.      over a wider area.
  74.  
  75.      National ISPs wishing to combine their operations with  those  of
  76.      one  or  more  ISPs in another nation to offer more comprehensive
  77.      dialup service in a group of countries or on a continent.
  78.  
  79.      Businesses desiring to  offer  their  employees  a  comprehensive
  80.      package of dialup services on a global basis.  Those services may
  81.      include Internet access as well as  secure  access  to  corporate
  82.      intranets via a Virtual Private Network (VPN), enabled by tunnel-
  83.      ing protocols such as PPTP, L2F and L2TP.
  84.  
  85. In order to enhance the interoperability of roaming and tunneling ser-
  86. vices,  it  is desirable to have a standardized method for identifying
  87. users. This document proposes syntax for the Network Access Identifier
  88. (NAI).  Methods  for authentication routing or determination of tunnel
  89. server endpoints will be addressed in future documents.
  90.  
  91.  
  92. 3.1.  Terminology
  93.  
  94. This document frequently uses the following terms:
  95.  
  96. Network Access Identifier
  97.           The Network Access Identifier (NAI) is the userID  submitted
  98.           by  the  client  during  PPP authentication. In roaming, the
  99.           purpose of the NAI is to identify the user  as  well  as  to
  100.           assist  in the routing of the authentication request. Please
  101.           note that the NAI may not necessarily be  the  same  as  the
  102.           user's e-mail address or the userID submitted in an applica-
  103.           tion layer authentication.
  104.  
  105. Network Access Server
  106.           The Network Access Server (NAS) is the device  that  clients
  107.           dial  in  order to get access to the network. In PPTP termi-
  108.           nology this is referred to as the PPTP  Access  Concentrator
  109.           (PAC),  and  in  L2TP  terminology, it is referred to as the
  110.           L2TP Access Concentrator (LAC).
  111.  
  112.  
  113.  
  114. 3.2.  Purpose
  115.  
  116. As described in [1], there are now at least five services implementing
  117. dialup  roaming, and the number of Internet Service Providers involved
  118. in roaming consortia is increasing rapidly.
  119.  
  120. In order to be able to offer roaming capability, one of  the  require-
  121. ments is to be able to identify the user's home authentication server.
  122. For use in roaming, this function  is  accomplished  via  the  Network
  123. Access  Identifier  (NAI) submitted by the user to the NAS in the ini-
  124. tial PPP authentication. It is also expected that PACs and  LACs  will
  125. use  the  NAI as part of the process of opening a new tunnel, in order
  126.  
  127.  
  128.  
  129. Aboba                                                         [Page 2]
  130.  
  131.  
  132.  
  133.  
  134.  
  135. INTERNET-DRAFT                                            May 22, 1997
  136.  
  137.  
  138. to determine the tunnel endpoint.
  139.  
  140.  
  141. 4.  Formal Definition of the NAI
  142.  
  143. As proposed in this document, the Network Access Identifer is  of  the
  144. form  user@domain,  where  the domain is a fully qualified domain name
  145. (FQDN).
  146.  
  147.  
  148. 4.1.  BNF for the NAI
  149.  
  150. The grammar for the NAI is given below, using the augmented BNF  nota-
  151. tion described in reference [9].
  152.  
  153. NAI = USERNAME "@" FQDN
  154. FQDN =    token "."  token *[ "." token ]
  155. USERNAME = token
  156.  
  157. Examples of valid Network Access Identifiers include:
  158.  
  159.      fred@bigco.com
  160.      nancy@eng.bigco.edu
  161.  
  162. Examples of invalid Network Access Identifiers include:
  163.  
  164.      bigco
  165.      howard.edu
  166.      fred@bigco.com@smallco.com
  167.      bigco!fred@smallco.com
  168.      bigco%fred@smallco.com
  169.  
  170.  
  171. 5.  Acknowledgements
  172.  
  173. Thanks to Glen Zorn of Microsoft for many useful discussions  of  this
  174. problem space.
  175.  
  176.  
  177. 6.  References
  178.  
  179. [1]  B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of  Roaming
  180. Implementations."  Work in progress, draft-ietf-roamops-imprev-02.txt,
  181. Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, May, 1997.
  182.  
  183. [2]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
  184. cation  Dial  In  User Service (RADIUS)." RFC 2058, Livingston, Merit,
  185. Daydreamer, January, 1997.
  186.  
  187. [3]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,
  188. 1997.
  189.  
  190. [4]  R. Fielding, et al.  "Hypertext Transfer  Protocol  -  HTTP/1.1."
  191. draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
  192.  
  193.  
  194.  
  195. Aboba                                                         [Page 3]
  196.  
  197.  
  198.  
  199.  
  200.  
  201. INTERNET-DRAFT                                            May 22, 1997
  202.  
  203.  
  204. 7.  Authors' Addresses
  205.  
  206. Bernard Aboba
  207. Microsoft Corporation
  208. One Microsoft Way
  209. Redmond, WA 98052
  210.  
  211. Phone: 206-936-6605
  212. EMail: bernarda@microsoft.com
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261. Aboba                                                         [Page 4]
  262.  
  263.  
  264.