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-radius-tunnel-imp-02.txt < prev    next >
Text File  |  1997-07-11  |  77KB  |  1,778 lines
  1.  
  2.      RADIUS Working Group                                     Bernard Aboba
  3.      INTERNET-DRAFT                                               Microsoft
  4.      Category: Standards Track                                    Glen Zorn
  5.      <draft-ietf-radius-tunnel-imp-02.txt>                        Microsoft
  6.      11 July 1997
  7.  
  8.  
  9.           Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS
  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-radius-tunnel-imp-02.txt> and  expires January 1,  1998.   Please
  31.      send comments to the authors.
  32.  
  33.  
  34.      2.  Abstract
  35.  
  36.      This  document  discusses  implementation issues arising in the provi-
  37.      sioning of compulsory tunneling in dial-up networks using the PPTP and
  38.      L2TP  protocols.   This provisioning can be accomplished via the inte-
  39.      gration of  RADIUS  and  tunneling  protocols.  Implementation  issues
  40.      encountered  with other tunneling protocols are left to separate docu-
  41.      ments.
  42.  
  43.  
  44.  
  45.      3.  Terminology
  46.  
  47.  
  48.      Voluntary Tunneling
  49.                In compulsory tunneling, a tunnel  is  created  without  any
  50.                action  from  the  user  and  without  allowing the user any
  51.                choice.
  52.  
  53.      Compulsory Tunneling
  54.                In compulsory tunneling, a tunnel  is  created  without  any
  55.                action  from  the  user  and  without  allowing the user any
  56.  
  57.  
  58.  
  59.      Aboba & Zorn                                                  [Page 1]
  60.  
  61.  
  62.  
  63.  
  64.  
  65.      INTERNET-DRAFT                                            11 July 1997
  66.  
  67.  
  68.                choice.
  69.  
  70.      Roaming   "Roaming capability" can be loosely defined  as  the ability
  71.                to  use  any  one  of  multiple  Internet  service providers
  72.                (ISPs), while maintaining a formal,  customer-vendor   rela-
  73.                tionship  with  only one. Examples  of  cases  where roaming
  74.                capaility might be required include ISP "confederations" and
  75.                ISP-provided corporate network access support.
  76.  
  77.      Shared Use Network
  78.                This is an IP dialup network whose use is shared by  two  or
  79.                more organizations.  Shared use networks typically implement
  80.                distributed authentication and accounting in order to facil-
  81.                itate  the relationship  among  the  sharing parties.  Since
  82.                these facilities are also  required  for  implementation  of
  83.                roaming,  implementation of shared use is frequently a first
  84.                step  toward development of roaming  capabilities. In  fact,
  85.                one  of  the ways by which a provider can offer roaming ser-
  86.                vice is to conclude shared use agreements with multiple net-
  87.                works.  However,  to date the ability to accomplish this has
  88.                been hampered by lack of interoperability among  shared  use
  89.                implementations.
  90.  
  91.      Tunnel Network Server
  92.                This is a server which terminates a tunnel. In  PPTP  termi-
  93.                nology,  this  is known as the PPTP Network Server (PNS). In
  94.                L2TP terminology, this is known as the L2TP  Network  Server
  95.                (LNS).
  96.  
  97.      Network Access Server
  98.                The  Network  Access Server (NAS) is the device that clients
  99.                contact in order to get access to the network. In PPTP  ter-
  100.                minology this is referred to as the PPTP Access Concentrator
  101.                (PAC). In L2TP terminology, the NAS is referred  to  as  the
  102.                L2TP Access Concentrator (LAC).
  103.  
  104.      RADIUS server
  105.                This  is  a  server which provides for authentication/autho-
  106.                rization via the protocol described in [3], and for account-
  107.                ing as described in [4].
  108.  
  109.      RADIUS proxy
  110.                In order to provide for the routing of RADIUS authentication
  111.                and accounting requests, a RADIUS proxy can be employed.  To
  112.                the NAS, the RADIUS proxy appears to act as a RADIUS server,
  113.                and to the RADIUS server, the proxy  appears  to  act  as  a
  114.                RADIUS client.
  115.  
  116.      Network Access Identifier
  117.                In order to provide for the routing of RADIUS authentication
  118.                and accounting requests, the userID field used in PPP and in
  119.                the   subsequent   RADIUS   authentication   and  accounting
  120.                requests, known as the Network Access Identifier  (NAI)  MAY
  121.                contain  structure. This structure provides a means by which
  122.  
  123.  
  124.  
  125.      Aboba & Zorn                                                  [Page 2]
  126.  
  127.  
  128.  
  129.  
  130.  
  131.      INTERNET-DRAFT                                            11 July 1997
  132.  
  133.  
  134.                the RADIUS proxy will locate the RADIUS server  that  is  to
  135.                receive the request. This same structure MAY also be used to
  136.                locate the tunnel endpoint when  domain-based  tunneling  is
  137.                used.
  138.  
  139.  
  140.      4.  Requirements language
  141.  
  142.      This specification uses the same words as [9] for defining the signif-
  143.      icance of each particular requirement.  These words are:
  144.  
  145.  
  146.      MUST      This word, or the adjectives "REQUIRED"  or  "SHALL",  means
  147.                that the definition is an absolute requirement of the speci-
  148.                fication.
  149.  
  150.      MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
  151.                nition is an absolute prohibition of the specification.
  152.  
  153.      SHOULD    This  word, or the adjective "RECOMMENDED", means that there
  154.                MAY exist  valid  reasons  in  particular  circumstances  to
  155.                ignore  a particular item, but the full implications must be
  156.                understood and carefully weighed before choosing a different
  157.                course.
  158.  
  159.      SHOULD NOT
  160.                This phrase means that there MAY exist valid reasons in par-
  161.                ticular  circumstances  when  the  particular  behavior   is
  162.                acceptable  or even useful, but the full implications should
  163.                be understood and the case carefully weighed  before  imple-
  164.                menting any behavior described with this label.
  165.  
  166.      MAY       This  word,  or the adjective "OPTIONAL", means that an item
  167.                is truly optional.  One vendor may  choose  to  include  the
  168.                item because a particular marketplace requires it or because
  169.                the vendor feels that it enhances the product while  another
  170.                vendor may omit the same item.  An implementation which does
  171.                not include a particular option MUST be prepared to interop-
  172.                erate  with  another  implementation  which does include the
  173.                option, though perhaps with reduced  functionality.  In  the
  174.                same  vein an implementation which does include a particular
  175.                option MUST be prepared to interoperate with another  imple-
  176.                mentation  which  does  not  include  the option.(except, of
  177.                course, for the feature the option provides)
  178.  
  179.      Silently Discard
  180.                The implementation discards  the  datagram  without  further
  181.                processing,  and  without indicating an error to the sender.
  182.                The implementation SHOULD provide the capability of  logging
  183.                the error, including the contents of the discarded datagram,
  184.                and SHOULD record the event in a statistics counter.
  185.  
  186.      An implementation is not compliant if it fails to satisfy one or  more
  187.      of  the MUST or MUST NOT requirements for the protocols it implements.
  188.  
  189.  
  190.  
  191.      Aboba & Zorn                                                  [Page 3]
  192.  
  193.  
  194.  
  195.  
  196.  
  197.      INTERNET-DRAFT                                            11 July 1997
  198.  
  199.  
  200.      An implementation that satisfies all the MUST, MUST  NOT,  SHOULD  and
  201.      SHOULD  NOT requirements for its protocols is said to be "uncondition-
  202.      ally compliant"; one that satisfies all the MUST and MUST NOT require-
  203.      ments but not all the SHOULD or SHOULD NOT requirements for its proto-
  204.      cols is said to be "conditionally compliant."
  205.  
  206.  
  207.      5.  Introduction
  208.  
  209.      Many applications  of  tunneling  protocols  involve  dial-up  network
  210.      access.  Some, such  as the provisioning of secure access to corporate
  211.      intranets via the Internet, are characterized by voluntary  tunneling:
  212.      the  tunnel  is created at the request of the user for a specific pur-
  213.      pose. Other applications involve compulsory tunneling: the  tunnel  is
  214.      created without any action from the user and without allowing the user
  215.      any choice.
  216.  
  217.      Examples  of  applications  that might be implemented using compulsory
  218.      tunnels  are  Internet software upgrade servers, software registration
  219.      servers  and  banking services.  These are all services which, without
  220.      compulsory  tunneling, would probably be provided using dedicated net-
  221.      works  or  at least dedicated network access servers (NAS), since they
  222.      are characterized by the need to limit user access to specific  hosts.
  223.  
  224.      Given  the  existence  of widespread support for compulsory tunneling,
  225.      however,  these  types  of services could be accessed via any Internet
  226.      service provider (ISP).  The most popular means of authorizing dial-up
  227.      network  users  today  is  through  the  RADIUS  protocol. The use  of
  228.      RADIUS allows the dial-up users' authorization and authentication data
  229.      to be maintained in a central location,  rather  than on each NAS.  It
  230.      makes sense to use RADIUS to centrally  administer   compulsory   tun-
  231.      neling,   since   RADIUS  is   widely deployed  and  was  designed  to
  232.      carry this type of information.  New RADIUS attributes are  needed  to
  233.      carry  the  tunneling  information  from the  RADIUS server to the NAS
  234.      and to transfer accounting data from the NAS to the RADIUS  accounting
  235.      server; those attributes are defined in [7].
  236.  
  237.  
  238.      5.1.  Tunneling attributes
  239.  
  240.      As  described in [7], provisioning of compulsory tunneling with RADIUS
  241.      requires no new RADIUS messages, and implementation of six new  RADIUS
  242.      attributes:  Tunnel-Type,  Tunnel-Medium-Type, Acct-Tunnel-Client-End-
  243.      point, Tunnel-Server-Endpoint, Acct-Tunnel-Connection-Id, and  Tunnel-
  244.      Password.
  245.  
  246.      The  Tunnel-Type  attribute  indicates the tunneling protocol(s) to be
  247.      used (PPTP, L2F, L2TP, ATMP, VTP, IPSEC AH, IP-IP). It MAY be included
  248.      in Access-Request, Access-Accept, and Access-Challenge  packets.
  249.  
  250.      The   Tunnel-Medium-Type Attribute indicates which transport medium to
  251.      use (IP, X.25, ATM, Frame Relay) when creating a tunnel for those pro-
  252.      tocols  (such   as   L2TP) that  can operate over multiple transports.
  253.      It MAY be included in in Access-Request,  Access-Accept,  and  Access-
  254.  
  255.  
  256.  
  257.      Aboba & Zorn                                                  [Page 4]
  258.  
  259.  
  260.  
  261.  
  262.  
  263.      INTERNET-DRAFT                                            11 July 1997
  264.  
  265.  
  266.      Challenge  packets.
  267.  
  268.      Acct-Tunnel-Client-Endpoint contains the address of the NAS end of the
  269.      tunnel.  It  SHOULD be included in  Accounting-Request  packets  which
  270.      contain  Acct-Status-Type  attributes  with values of either Start  or
  271.      Stop.  This  Attribute,  along  with  the  Tunnel-Server-Endpoint  and
  272.      Acct-Tunnel-Connection-ID  attributes,  may be used to provide a glob-
  273.      ally unique means to identify a tunnel for accounting purposes.
  274.  
  275.      Tunnel-Server-Endpoint indicates the address of the server end of  the
  276.      tunnel.   It  SHOULD  be included in  Accounting-Request packets which
  277.      contain Acct-Status-Type attributes with values  of  either  Start  or
  278.      Stop.
  279.  
  280.      Acct-Tunnel-Connection-ID  indicates  the  identifier  assigned to the
  281.      call.  It SHOULD be included in   Accounting-Request   packets   which
  282.      contain  Acct-Status-Type   attributes  with values of either Start or
  283.      Stop.
  284.  
  285.      The Tunnel-Password attribute may contain a key or  password, which is
  286.      to  be  used  with  protocols such as L2TP which support authenticated
  287.      tunnels.  It may  only  be included in  an  Access-Accept  or  Access-
  288.      Challenge packet.
  289.  
  290.      Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS
  291.      server may be processed by one or more proxies prior to being received
  292.      by  the  NAS. In order to ensure that tunnel attributes arrive without
  293.      modification, intermediate RADIUS proxies forwarding the  Access-Reply
  294.      MUST  NOT  modify tunnel attributes. If the RADIUS proxy does not sup-
  295.      port tunnel attributes, then it MUST send an Access-Reject to the NAS.
  296.      This  is  necessary  to ensure that the user is only granted access if
  297.      the services requested by the RADIUS server can be provided.
  298.  
  299.      Since RADIUS tunnel attributes  are  used  for  compulsory  tunneling,
  300.      address  assignment  is  handled  by the tunnel server rather than the
  301.      NAS. As a result, if tunnel  attributes  are  present,  the  NAS  MUST
  302.      ignore any address assignment attributes sent by the RADIUS server. In
  303.      addition, the NAS and client MUST NOT  begin  NCP  negotiation,  since
  304.      this could create a time window in which the client will be capable of
  305.      sending packets to the transport network, which is not permitted under
  306.      compulsory tunneling.
  307.  
  308.  
  309.      5.2.  Advantanges of RADIUS-based compulsory tunneling
  310.  
  311.      The  use  of  RADIUS in provisioning of compulsory tunnels has several
  312.      advantages. These include:
  313.  
  314.           User-based tunneling
  315.           Auditing capabilities
  316.           Telephone-number based authentication and accounting
  317.           Single or dual authentication
  318.  
  319.  
  320.  
  321.  
  322.  
  323.      Aboba & Zorn                                                  [Page 5]
  324.  
  325.  
  326.  
  327.  
  328.  
  329.      INTERNET-DRAFT                                            11 July 1997
  330.  
  331.  
  332.      5.2.1.  User-based Tunneling
  333.  
  334.      Current proposals for routing of tunnel requests include  static  tun-
  335.      neling,  where  all  users  are automatically tunneled to a given end-
  336.      point, and realm-based tunneling, where the tunnel endpoint is  deter-
  337.      mined  from  the  realm portion of the userID. User-based tunneling as
  338.      provided by integration of RADIUS and tunnel protocols offers signifi-
  339.      cant advantages over both of these approaches.
  340.  
  341.      Static  tunneling  requires dedication of a NAS device to the purpose.
  342.      In the case of an ISP, this is undesirable because it requires them to
  343.      dedicate  a  NAS  to tunneling service for a given corporate customer,
  344.      rather than allowing them to use existing NASes deployed in the field.
  345.      As  a result static tunneling is likely to be costly for deployment of
  346.      a global service.
  347.  
  348.      Realm-based tunneling assumes that all users within a given realm wish
  349.      to be treated the same way. This limits a corporation's flexibility in
  350.      managing the account rights of their users.  For  example,  BIGCO  may
  351.      desire to provide Janet with an account that allows access to both the
  352.      Internet and the intranet, with Janet's intranet access provided by  a
  353.      tunnel server located in the engineering department. However BIGCO may
  354.      desire to provide Fred with an account that provides  only  access  to
  355.      the intranet, with Fred's intranet access provided by a tunnel network
  356.      server located in the sales department. Such  a  situation  cannot  be
  357.      accommodated with realm-based tunneling.
  358.  
  359.      On  the  other hand, user-based tunneling as enabled by the attributes
  360.      defined in [7] provides BIGCO with the flexibility to administer  tun-
  361.      neling  behavior  on  a  per-user basis. When deployed in concert with
  362.      roaming, user-based tunneling offers corporations the ability to  pro-
  363.      vide  their  users  with  access to the corporate Intranet on a global
  364.      basis.
  365.  
  366.  
  367.      5.3.  Auditing Capabilities
  368.  
  369.      The integration of RADIUS and tunnel protocols allows the ISP and  the
  370.      corporation  to  synchronize  their accounting activities so that each
  371.      side receives a record of the user's resource consumption.  This  pro-
  372.      vides the corporation with the means to audit ISP bills.
  373.  
  374.      The    Acct-Tunnel-Client-Endpoint    and    Acct-Tunnel-Connection-ID
  375.      attributes were introduced in [7] in order to support auditing.  These
  376.      attributes  are  included  within the RADIUS Accounting-Request packet
  377.      along with other attributes such as the User-Name  and  Tunnel-Server-
  378.      Endpoint.   During  accounting, the User-Name, Acct-Tunnel-Connection-
  379.      ID, Acct-Tunnel-Client-Endpoint and Tunnel-Server-Endpoint  attributes
  380.      uniquely identify the call. This allows the Accounting-Request sent by
  381.      the NAS to be reconciled  with  the  corresponding  Accounting-Request
  382.      sent by the tunnel server.
  383.  
  384.      When  implementing  L2TP compulsory tunneling based on RADIUS, the NAS
  385.      MUST transmit the Call-Serial-Number in the  Acct-Tunnel-Connection-ID
  386.  
  387.  
  388.  
  389.      Aboba & Zorn                                                  [Page 6]
  390.  
  391.  
  392.  
  393.  
  394.  
  395.      INTERNET-DRAFT                                            11 July 1997
  396.  
  397.  
  398.      attribute  in  the  Accounting-Request  packet.  In  order  to protect
  399.      against wrapping due to reboots or call volume, a 64-bit NTP timestamp
  400.      SHOULD  be used as the Call-Serial Number. This feasible in L2TP since
  401.      the Call-Serial-Number string is of variable length.
  402.  
  403.      When implementing PPTP compulsory tunneling based on RADIUS,  the  NAS
  404.      MUST  transmit the Call-Serial-Number in the Acct-Tunnel-Connection-ID
  405.      attribute in the Accounting-Request packet.  While [6] states that the
  406.      Call-Serial-Number  SHOULD  be unique, this is not required.  In addi-
  407.      tion, no method for determining the Call-Serial-Number  is  specified,
  408.      which leaves open the possibility of wrapping after a reboot.
  409.  
  410.      Since the Call-Serial-Number is a 16-bit value, the Call-Serial-Number
  411.      is not sufficient to distinguish a given call  from  all  other  calls
  412.      over an extended time period. For example, let us assume that the Call
  413.      Serial Number is assigned monotonically, and that the NAS in  question
  414.      has 96 ports. If the NAS ports are kept continually busy and the aver-
  415.      age call is of 20 minutes duration, then the Call Serial  Number  will
  416.      wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.5 days.
  417.  
  418.      In  order  to  rectify this, it is recommended that another message be
  419.      added to PPTP so that the NAS could provide the tunnel server with  an
  420.      Acct-Tunnel-Connection-ID  unique over an extended time period.  It is
  421.      recommended that a 64-bit NTP timestamp be used for this purpose.
  422.  
  423.  
  424.      5.4.  Telephone-number based authentication and accounting
  425.  
  426.      Using the Calling-Station-Id and Called-Station-Id RADIUS  attributes,
  427.      authorization  and  subsequent  tunnel  attributes can be based on the
  428.      phone number originating the call, or the number  being  called.  This
  429.      allows the RADIUS server to authorize users based on the calling phone
  430.      number (with or without a userID/password combination), or  to  select
  431.      the  Tunnel-Type,  Tunnel-Medium-Type, Tunnel-Server-Endpoint and Tun-
  432.      nel-Password attributes based on the Calling-Station-Id or Called-Sta-
  433.      tion-Id.   Similarly,  in  PPTP/L2TP  the  tunnel server MAY choose to
  434.      reject or accept the call based on the Dialed Number and Dialing  Num-
  435.      ber included in the PPTP/L2TP Incoming-Call-Request packet sent by the
  436.      NAS.
  437.  
  438.      The use of RADIUS accounting by  the  NAS  and/or  the  tunnel  server
  439.      allows  for  accounting  to take place based on the Calling-Station-Id
  440.      and Called-Station-Id.
  441.  
  442.  
  443.      5.5.  Single or dual authentication
  444.  
  445.      As described below, RADIUS-based compulsory tunneling  can  support  a
  446.      variety of authentication configurations. These include single authen-
  447.      tication, where the user is authenticated at  the  tunnel  server,  or
  448.      dual  authentication,  where the user is authenticated at both the NAS
  449.      and the tunnel server. When  single  authentication  is  supported,  a
  450.      variety  of  modes  are  possible,  including  telephone-number  based
  451.      authentication described  above,  or  EAP-based  authentication.  When
  452.  
  453.  
  454.  
  455.      Aboba & Zorn                                                  [Page 7]
  456.  
  457.  
  458.  
  459.  
  460.  
  461.      INTERNET-DRAFT                                            11 July 1997
  462.  
  463.  
  464.      dual-authentication  is used, a number of modes are available, includ-
  465.      ing    dual    CHAP    authentications;    CHAP/EAP    authentication;
  466.      CHAP/PAP(token)  authentication; and EAP/EAP authentication, using the
  467.      same EAP type for both authentications.
  468.  
  469.      PAP/PAP, CHAP/PAP and EAP/PAP dual authentications SHOULD NOT be used,
  470.      since  these  combinations involve transmission of cleartext passwords
  471.      over the Internet.
  472.  
  473.  
  474.      6.  Authentication alternatives in compulsory tunneling
  475.  
  476.      There are  several  authentication  alternatives  for  integration  of
  477.      RADIUS and tunneling:
  478.  
  479.           Authenticate at the NAS
  480.           Authenticate at the NAS, and forward the RADIUS reply
  481.           Authenticate at the tunnel network server
  482.           Authenticate at both the NAS and the tunnel network server
  483.  
  484.      We discuss each of these alternatives in turn.
  485.  
  486.  
  487.      6.1.  Authenticate at the NAS
  488.  
  489.      With  this  approach, authentication and authorization (including tun-
  490.      neling information) occurs once, at the NAS. The  advantages  of  this
  491.      approach  are  that  it  disallows network access for unauthorized NAS
  492.      users; and allows RADIUS accounting to be used at the  NAS.  Disadvan-
  493.      tages  are  that  it requires that the tunnel network server trust the
  494.      NAS, since no user authentication occurs on the tunnel network  server
  495.      end  of  the  tunnel. Another disadvantage is that this does not allow
  496.      LCP parameters to be re-negotiated by the tunnel network server. Also,
  497.      due  to  the lack of user authentication, accounting cannot take place
  498.      at the tunnel network server with strong assurance  that  the  correct
  499.      party  is  being  billed.  As  a  result, it does not appear that this
  500.      scheme can be practically employed.
  501.  
  502.  
  503.      6.2.  Authenticate at the NAS, and forward the RADIUS reply
  504.  
  505.      With this approach, authentication and authorization occurs  once,  at
  506.      the  NAS  end  of  the tunnel and the RADIUS reply is forwarded to the
  507.      tunnel network server. This  approach  disallows  network  access  for
  508.      unauthorized  NAS  users;  does  not require trust between the NAS and
  509.      tunnel network server ends  of  the  tunnel;  and  allows  for  RADIUS
  510.      accounting  to  be  used  at both ends of the tunnel. However, it also
  511.      requires that both ends share the same secret with the RADIUS  server,
  512.      since  that is the only way that the tunnel network server could check
  513.      the RADIUS reply.
  514.  
  515.      In this approach,  the tunnel network server MUST share  secrets  with
  516.      all the NASes and associated RADIUS servers, and there is no provision
  517.      for LCP renegotiation by the tunnel network server. Also,  the  tunnel
  518.  
  519.  
  520.  
  521.      Aboba & Zorn                                                  [Page 8]
  522.  
  523.  
  524.  
  525.  
  526.  
  527.      INTERNET-DRAFT                                            11 July 1997
  528.  
  529.  
  530.      network server MUST know how to handle and verify RADIUS Access-Accept
  531.      messages.
  532.  
  533.      While this scheme can be workable if the reply comes directly  from  a
  534.      RADIUS  server,  it  would  become  unmanageable  if a RADIUS proxy is
  535.      involved, since the reply would  be  authenticated  using  the  secret
  536.      shared  by  the  client and proxy, rather than the RADIUS server. As a
  537.      result, it does  not  appear  that  this  scheme  can  be  practically
  538.      employed.
  539.  
  540.  
  541.      6.3.  Authenticate at the tunnel network server
  542.  
  543.      In  this  scheme,  authentication and authorization occurs once at the
  544.      tunnel network server. This requires that the NAS determine  that  the
  545.      user needs to be tunneled (through RADIUS or NAS configuration). Where
  546.      RADIUS is used, the determination can be made using one of the follow-
  547.      ing methods:
  548.  
  549.           Telephone-number based authentication
  550.           User-Name
  551.           EAP Identity
  552.  
  553.  
  554.      6.3.1.  Telephone-number based authentication
  555.  
  556.      Where  telephone-number based authentication is used, the Calling-Sta-
  557.      tion-Id or Called-Station-Id attributes included in the RADIUS Access-
  558.      Request  are  used  to  determine whether the call will be accepted or
  559.      rejected, and if accepted, where the user is  to  be  tunneled.  Where
  560.      telephone-number based authentication is used, the User-Name and User-
  561.      Password or CHAP-Password attributes need not be present.
  562.  
  563.      In  cases  where  telephone-number  authentication  may  be  employed,
  564.      accounting  may  be  accomplished on the NAS side via the Calling-Sta-
  565.      tion-Id or Called-Station-Id, and on the tunnel server side,  via  the
  566.      userID.  Thus  this scheme is capable of providing both authentication
  567.      and accounting, and appears practical to implement.
  568.  
  569.  
  570.      6.3.2.  User-Name
  571.  
  572.      Where the User-Name attribute is present, RADIUS  as  defined  in  [3]
  573.      requires  that  either  a  CHAP-Password or User-Password attribute be
  574.      present in an Access-Request message, as well as  requiring  that  the
  575.      password  be  non-empty.  Thus, this scheme either requires attribute-
  576.      specific processing on the RADIUS server, or addition  of  an  "Autho-
  577.      rize-Only" message.
  578.  
  579.      In attribute-specific processing an attribute is used to signal tunnel
  580.      initiation.  For example, tunnel attributes can be sent  back  if  the
  581.      PAP  password  is empty (or "tunnel" or "L2TP"). Alternatively, a user
  582.      could prefix the userID with some special character ('*') if he wanted
  583.      to  be  tunneled. This particular solution does not support compulsory
  584.  
  585.  
  586.  
  587.      Aboba & Zorn                                                  [Page 9]
  588.  
  589.  
  590.  
  591.  
  592.  
  593.      INTERNET-DRAFT                                            11 July 1997
  594.  
  595.  
  596.      tunneling. Another solution involves keying on the domain  portion  of
  597.      the  userID;  all  users  in  domain X would be tunneled to address Y.
  598.      This proposal supports compulsory tunneling, but does not provide  for
  599.      user-based tunneling.
  600.  
  601.      An  Authorize-Only  message  would not include a CHAP or PAP password;
  602.      nevertheless, in response the RADIUS server would return the attribute
  603.      list. In order to prevent password guessing attacks, an Authorize-Only
  604.      message would need to be authenticated via the RADIUS  shared  secret.
  605.      This  could  be  accomplished via the Signature attribute described in
  606.      [10].
  607.  
  608.      Note that when either attribute-specific processing or  an  authorize-
  609.      only  message is used, the tunnel network server would need to renego-
  610.      tiate LCP. Note also that in order for the NAS to start accounting  on
  611.      the  connection, it would need to use the identity claimed by the user
  612.      in authenticating to the tunnel network server, since it did not  ver-
  613.      ify  the  identity via RADIUS. However, in order for that to be of any
  614.      use in accounting, the tunnel endpoint needs to have an account  rela-
  615.      tionship  with  the NAS owner. Thus even if a user has an account with
  616.      the NAS owner, they cannot use this account for tunneling  unless  the
  617.      tunnel  endpoint  also has a business relationship with the NAS owner.
  618.      Without putting in place a public key infrastructure, it is not  clear
  619.      how  the  NAS would be able to verify the existence of such a business
  620.      relationship in a scalable manner. Thus this approach  nullifies  many
  621.      of  the  benefits  of  roaming. Due to these difficulties, it does not
  622.      appear that this scheme can be practically employed.
  623.  
  624.  
  625.  
  626.      6.3.3.  EAP Identity
  627.  
  628.      Where EAP is used as described in [11], the NAS may  include  an  EAP-
  629.      Message/Identity  attribute in the RADIUS Access-Request. Based on the
  630.      Identity included in the Access-Request, the RADIUS  server  may  send
  631.      tunneling  attributes  within  the RADIUS Access-Challenge packet. The
  632.      NAS can then set up the tunnel and  EAP  authentication  may  continue
  633.      between the client and the tunnel server. This method avoids having to
  634.      use attribute-specific processing or an authorize-only message.
  635.  
  636.      However, in this case, the EAP identity is never verified by the  NAS,
  637.      and so either the tunnel server owner must be willing to be billed for
  638.      all incoming calls, or other information such as the  Calling-Station-
  639.      Id must be used to verify the user's identity for accounting purposes.
  640.      Where either of these conditions holds true, this scheme may be  prac-
  641.      tically employed.
  642.  
  643.  
  644.      6.4.  Authenticate at both the NAS and the tunnel network server
  645.  
  646.      In  this  scheme, authentication occurs both at the NAS and the tunnel
  647.      network server. This requires the dial-up  PPP  peer  to  handle  dual
  648.      authentications, with attendant LCP re-negotiations. In order to allow
  649.      the NAS and tunnel network server to  authenticate  against  the  same
  650.  
  651.  
  652.  
  653.      Aboba & Zorn                                                 [Page 10]
  654.  
  655.  
  656.  
  657.  
  658.  
  659.      INTERNET-DRAFT                                            11 July 1997
  660.  
  661.  
  662.      database, this requires RADIUS client capability on the tunnel network
  663.      server, and possibly a RADIUS proxy on the NAS end.
  664.  
  665.      Advantages of this scheme are that it allows secure authentication and
  666.      accounting  at  both  ends  of  the tunnel; allows the use of a single
  667.      userID/password pair via implementation of RADIUS on the  tunnel  net-
  668.      work  server;  and does not require telephone-number based authentica-
  669.      tion, use of EAP, attribute-specific  processing  or  addition  of  an
  670.      Authorize-Only  message  on the RADIUS server.  This scheme allows for
  671.      accounting records to be generated on both the NAS and  tunnel  server
  672.      ends  allowing for auditing. Also, in contrast to the previous scheme,
  673.      the tunnel endpoint does not need to have an account relationship with
  674.      the  NAS owner. Thus this scheme is compatible with roaming. Disadvan-
  675.      tages are that unless LCP forwarding is used,  LCP  will  need  to  be
  676.      renegotiated, and that dual authentications are required.
  677.  
  678.      The  use  of dual authentication can be complex, since some clients do
  679.      not support it at all, and others only support only a  subset  of  the
  680.      dual   authentication   combinations.  Feasible  combinations  include
  681.      PAP/PAP(token),   PAP/CHAP,   PAP/EAP,   CHAP/PAP(token),   CHAP/CHAP,
  682.      CHAP/EAP,  EAP/CHAP,  and  EAP/EAP.  Assuming  that  the required dual
  683.      authentication capabilities are supported, this scheme may be  practi-
  684.      cally employed.
  685.  
  686.  
  687.      7.  Telephone-number based authentication
  688.  
  689.  
  690.  
  691.      7.1.  Initiation sequence
  692.  
  693.      In the case of telephone-number based authentication, a typical initi-
  694.      ation sequence looks like this:
  695.  
  696.           Client and NAS: Call Connected
  697.           NAS to RADIUS Server: RADIUS Access-request
  698.           RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
  699.           NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
  700.           Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
  701.           NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
  702.           Client and Tunnel Server: PPP LCP negotiation
  703.           Client and Tunnel Server: PPP authentication
  704.           Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
  705.           RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
  706.           Client and Tunnel Server: NCP negotiation
  707.           NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
  708.           RADIUS Server to NAS: RADIUS Accounting-Response
  709.           Tunnel Server to RADIUS Server: RADIUS Accounting-Request
  710.              with Acct-Status-Type=Start (Optional)
  711.           RADIUS Server to Tunnel Server: RADIUS Accounting-Response
  712.  
  713.      The process begins with an incoming call to the NAS. If configured for
  714.      telephone-number  based  authentication,  the  NAS  MUST send a RADIUS
  715.      Access-Request  containing  the  Calling-Station-Id  and  the  Called-
  716.  
  717.  
  718.  
  719.      Aboba & Zorn                                                 [Page 11]
  720.  
  721.  
  722.  
  723.  
  724.  
  725.      INTERNET-DRAFT                                            11 July 1997
  726.  
  727.  
  728.      Station-Id  attributes.  The  RADIUS  server  will then respond with a
  729.      RADIUS Access-Accept or Access-Reject.
  730.  
  731.      The NAS MUST NOT begin PPP authentication before bringing up the  tun-
  732.      nel.  If  timing  permits,  the  NAS  MAY bring up the tunnel prior to
  733.      beginning LCP negotiation with the client. If this is done,  then  LCP
  734.      will not need to be renegotiated between the client and tunnel server.
  735.  
  736.      If the initial telephone-number based authentication is  unsuccessful,
  737.      the  RADIUS server sends a RADIUS Access-Reject. In this case, the NAS
  738.      MUST send an LCP-Terminate and disconnect the user.
  739.  
  740.      In the case where tunnel attributes are included in the RADIUS Access-
  741.      Accept, and a PPTP/L2TP tunnel is indicated, the NAS will now bring up
  742.      a control connection if none existed before.  The  control  connection
  743.      will  be  of  the type indicated by Tunnel-Type, over the medium indi-
  744.      cated by Tunnel-Medium-Type, to the tunnel server indicated by Tunnel-
  745.      Server-Endpoint.  This  is  accomplished by sending a PPTP/L2TP Start-
  746.      Control-Connection-Request message to the tunnel server.   The  tunnel
  747.      server  will then with a PPTP/L2TP Start-Control-Connection-Reply.  If
  748.      this message indicates an error, or if the control connection is  ter-
  749.      minated  at  any  future time, then the NAS MUST send an LCP-Terminate
  750.      and disconnect the user.
  751.  
  752.      The NAS will then proceed to send  a  PPTP/L2TP  Incoming-Call-Request
  753.      message  to  the  tunnel server. Among other things, this message will
  754.      contain the Call Serial Number, which along  with  the  NAS-IP-Address
  755.      and  Tunnel-Server-Endpoint is used to uniquely identify the call. The
  756.      tunnel server will reply with a PPTP/L2TP Incoming-Call-Reply message.
  757.      If this message indicates an error, then the NAS MUST send an LCP-Ter-
  758.      minate and disconnect the user. If no error is indicated, the NAS then
  759.      replies with a PPTP/L2TP Incoming-Call-Connected message.
  760.  
  761.      At this point, data MAY begin to flow through the tunnel. If LCP nego-
  762.      tiation had been begun between the NAS and the client, the client  and
  763.      tunnel  server  MAY  now renegotiate LCP and begin PPP authentication;
  764.      otherwise, the client and tunnel server will  negotiate  LCP  for  the
  765.      first time, and then move on to PPP authentication.
  766.  
  767.      If  a  renegotiation  is  required, at the time that the renegotiation
  768.      begins, the NAS SHOULD NOT have sent an  LCP  CONFACK  completing  LCP
  769.      negotiation,  and  the client and NAS MUST NOT have begun NCP negotia-
  770.      tion. Rather than sending an LCP CONFACK, the NAS will instead send an
  771.      LCP  DOWN  message. The Client MAY then renegotiate LCP, and from that
  772.      point forward, all PPP packets originated  from  the  client  will  be
  773.      encapsulated  and  sent to the tunnel server.  When LCP re-negotiation
  774.      has been concluded, the NCP phase will begin, and  the  tunnel  server
  775.      will assign an address to the client.
  776.  
  777.      If L2TP is being used as the tunnel protocol, and LCP renegotiation is
  778.      required, the NAS MAY in its initial setup notification include a copy
  779.      of the LCP CONFACKs sent in each direction which completed LCP negoti-
  780.      ation. The tunnel server MAY then use this  information  to  avoid  an
  781.      additional  LCP negotiation. With L2TP, the initial setup notification
  782.  
  783.  
  784.  
  785.      Aboba & Zorn                                                 [Page 12]
  786.  
  787.  
  788.  
  789.  
  790.  
  791.      INTERNET-DRAFT                                            11 July 1997
  792.  
  793.  
  794.      can also include the authentication information required to allow  the
  795.      tunnel server to authenticate the user and decide to accept or decline
  796.      the connection. However, in telephone-number based authentication, PPP
  797.      authentication MUST NOT occur prior to the NAS bringing up the tunnel.
  798.      As a result, L2TP authentication forwarding MUST NOT be employed.
  799.  
  800.      In performing the PPP authentication, the tunnel server can access its
  801.      own  user database, or it MAY send a RADIUS Access-Request. The latter
  802.      approach  is  useful  in  cases  where  authentication  forwarding  is
  803.      enabled,  such  as  with roaming or shared use networks. In this case,
  804.      the RADIUS and tunnel servers are under the  same  administration  and
  805.      are  typically  located  close  together,  possibly  on  the same LAN.
  806.      Therefore having the tunnel server act as a RADIUS client provides for
  807.      unified user administration. Other methods are also available, such as
  808.      use of LDAP, described in [12], by both the tunnel and RADIUS servers.
  809.      Note  that the tunnel server's RADIUS Access-Request is typically sent
  810.      directly to the local RADIUS server rather than  being  forwarded  via
  811.      proxy.
  812.  
  813.      After  the  tunnel  has been brought up, the NAS and tunnel server MAY
  814.      start accounting.  In the case of the NAS, this is done by  sending  a
  815.      RADIUS  Accounting-Request  packet  with  Acct-Status-Type=Start  to a
  816.      RADIUS server. The Accounting-Request packet MUST include the  follow-
  817.      ing  attributes:  Tunnel-Type, Tunnel-Medium-Type, Acct-Tunnel-Client-
  818.      Endpoint, Tunnel-Server-Endpoint, and  Acct-Tunnel-Connection-Id.  The
  819.      Accounting-Request  packet MAY also include the Calling-Station-Id and
  820.      Called-Station-Id attributes.
  821.  
  822.      The tunnel server can produce its own accounting records,  or  it  MAY
  823.      send a RADIUS Accounting-Request packet with Acct-Status-Type=Start to
  824.      a local RADIUS server. In the  latter  case,  the  RADIUS  Accounting-
  825.      Request  packet  MUST  contain  the following attributes: Tunnel-Type,
  826.      Tunnel-Medium-Type,  Acct-Tunnel-Client-Endpoint,   Tunnel-Server-End-
  827.      point, and Acct-Tunnel-Connection-Id.
  828.  
  829.      The  interactions  involved  in initiation of a compulsory tunnel with
  830.      telephone-number based authentication are summarized below.  In  order
  831.      to  simplify  the  diagram  that follows, we have left out the client.
  832.      However, it is understood that the client participates via PPP negoti-
  833.      ation,  authentication and subsequent data interchange with the Tunnel
  834.      Server.
  835.  
  836.  
  837.                                     INITIATION SEQUENCE
  838.  
  839.      NAS                            Tunnel Server       RADIUS Server
  840.      ---                            -------------       -------------
  841.      Call connected
  842.      Send RADIUS
  843.       Access-Request
  844.       with Called-Station-Id,
  845.       and/or Calling-Station-Id
  846.      LCP starts
  847.                                                         IF authentication
  848.  
  849.  
  850.  
  851.      Aboba & Zorn                                                 [Page 13]
  852.  
  853.  
  854.  
  855.  
  856.  
  857.      INTERNET-DRAFT                                            11 July 1997
  858.  
  859.  
  860.                                                         succeeds
  861.                                                          Send ACK with
  862.                                                          Tunnel-Type,
  863.                                                          Tunnel-Medium-Type,
  864.                                                          Tunnel-Server-Endpoint,
  865.                                                          Tunnel-Password (optional)
  866.                                                         ELSE Send NAK
  867.      IF NAK DISCONNECT
  868.      ELSE
  869.       IF no control
  870.        connection exists
  871.        Send
  872.        Start-Control-Connection-Request
  873.        to Tunnel Server
  874.                                   Send
  875.                                   Start-Control-Connection-Reply
  876.                                   to NAS
  877.       ENDIF
  878.  
  879.      Send
  880.      Incoming-Call-Request
  881.      message to Tunnel Server
  882.                                   Send Incoming-Call-Reply
  883.                                   to NAS
  884.      Send
  885.      Incoming-Call-Connected
  886.      message to Tunnel Server
  887.  
  888.      Send data through the tunnel
  889.                                   Re-negotiate LCP,
  890.                                   authenticate user,
  891.                                   bring up IPCP,
  892.                                   start accounting
  893.                                   Send RADIUS
  894.                                   Accounting-Request with
  895.                                   Acct-Status-Type=Start
  896.                                   (optional)
  897.                                                        Send
  898.                                                        RADIUS
  899.                                                        Accounting-Response
  900.      Send a RADIUS
  901.      Accounting-Request message
  902.      with Acct-Status-Type=Start
  903.      containing
  904.      Tunnel-Type, Tunnel-Medium-Type,
  905.      Acct-Tunnel-Client-Endpoint,
  906.      Tunnel-Server-Endpoint,
  907.      Acct-Tunnel-Connection-Id,
  908.      Calling-Station-Id,
  909.      Called-Station-Id.
  910.                                                        Send
  911.                                                        RADIUS
  912.                                                        Accounting-Response
  913.  
  914.  
  915.  
  916.  
  917.      Aboba & Zorn                                                 [Page 14]
  918.  
  919.  
  920.  
  921.  
  922.  
  923.      INTERNET-DRAFT                                            11 July 1997
  924.  
  925.  
  926.      ENDIF
  927.  
  928.  
  929.      7.2.  EAP support
  930.  
  931.      It is expected  that  the  Extensible  Authentication  Protocol  (EAP)
  932.      described in [13] will frequently be used along with telephone number-
  933.      based authentication and tunneling  in  order  to  provide  additional
  934.      security.  In  this case, EAP authentication may be used in the tunnel
  935.      authentication only, using EAP code present on the NAS, or via support
  936.      of  EAP within RADIUS described in [11].  In this case, the initiation
  937.      sequence will look like this:
  938.  
  939.           Client and NAS: Call Connected
  940.           Client and NAS: PPP LCP negotiation
  941.           NAS to RADIUS Server: RADIUS Access-Request
  942.           RADIUS server to NAS: RADIUS Access-Reply/Tunnel attributes
  943.           NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
  944.           Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
  945.           NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected
  946.           Client and Tunnel Server: PPP LCP re-negotiation (optional)
  947.           Client and Tunnel Server: EAP authentication
  948.           Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start
  949.           RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message
  950.           Tunnel Server to Client: EAP-Request
  951.           Client to Tunnel Server: EAP-Response
  952.           Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message
  953.           RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success
  954.           Client and Tunnel Server: NCP negotiation
  955.           NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
  956.           RADIUS Server to NAS: RADIUS Accounting-Response
  957.           Tunnel Server to RADIUS Server: RADIUS Accounting-Request with
  958.              Acct-Status-Type=Start (Optional)
  959.           RADIUS Server to Tunnel Server: RADIUS Accounting-Response
  960.  
  961.  
  962.  
  963.      8.  Single authentication
  964.  
  965.  
  966.  
  967.      8.1.  Initiation sequence
  968.  
  969.      In the case of a single authentication compulsory  tunnel,  a  typical
  970.      initiation sequence looks like this:
  971.  
  972.           Client and NAS: Call Connected
  973.           Client and NAS: PPP LCP negotiation
  974.           Client and NAS: EAP authentication
  975.           NAS to RADIUS Server: RADIUS Access-request
  976.           RADIUS server to NAS: RADIUS Access-Challenge/Access-Reject
  977.           NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
  978.           Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
  979.           NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
  980.  
  981.  
  982.  
  983.      Aboba & Zorn                                                 [Page 15]
  984.  
  985.  
  986.  
  987.  
  988.  
  989.      INTERNET-DRAFT                                            11 July 1997
  990.  
  991.  
  992.           Client and Tunnel Server: PPP LCP re-negotiation (optional)
  993.           Client and Tunnel Server: EAP authentication
  994.           Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
  995.           RADIUS server to Tunnel Server: RADIUS Access-Challenge/Access-Reject
  996.           Client and Tunnel Server: NCP negotiation
  997.           NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
  998.           RADIUS Server to NAS: RADIUS Accounting-Response
  999.           Tunnel Server to RADIUS Server: RADIUS Accounting-Request
  1000.              with Acct-Status-Type=Start (Optional)
  1001.           RADIUS Server to Tunnel Server: RADIUS Accounting-Response
  1002.  
  1003.      The  process  begins with an incoming call to the NAS, and the PPP LCP
  1004.      negotiation between the Client and NAS. At this point,  the  NAS  must
  1005.      offer  EAP,  and  the Client must accept if the negotiation is to pro-
  1006.      ceed. If the Client is incapable of authenticating via EAP,  then  the
  1007.      NAS MUST send an LCP-Terminate and disconnect the user.
  1008.  
  1009.      The  NAS will now typically send an EAP-Request/Identity packet to the
  1010.      Client, and the client will respond with an EAP-Response/MyId  packet.
  1011.      The  NAS  now  sends  an  Access-Request/EAP-Message/EAP-Response/MyId
  1012.      packet to the RADIUS server, which responds with  an  Access-Challenge
  1013.      or an Access-Reject.
  1014.  
  1015.      If  single-authentication  tunneling is to be carried out, the Access-
  1016.      Challenge packet MUST contain the Tunnel-Type, Tunnel-Medium-Type, and
  1017.      Tunnel-Server-Endpoint  Attributes;  a  Tunnel-Password  attribute  is
  1018.      optional. The presence of tunneling attributes in the Access-Challenge
  1019.      indicates to the NAS that a tunnel MUST be brought up prior to contin-
  1020.      uation of the EAP conversation. As a result, if  the  Access-Challenge
  1021.      contains an EAP-Message attribute, then the NAS MUST NOT send the EAP-
  1022.      Request encapsulated in the EAP-Message prior to bringing up the  tun-
  1023.      nel.  Since  after  the tunnel is brought up LCP will be renegotiated,
  1024.      EAP-Message attributes are effectively ignored  whenever  the  Access-
  1025.      Challenge also contains tunnel attributes.
  1026.  
  1027.      In  the  case  where a PPTP/L2TP tunnel is indicated, the NAS will now
  1028.      bring up a control connection if none existed before, and the NAS  and
  1029.      tunnel server will bring up the call. At this point, data MAY begin to
  1030.      flow through the tunnel. The client and tunnel server MAY now  renego-
  1031.      tiate LCP and will complete PPP authentication.
  1032.  
  1033.      At  the  time  that  the renegotiation begins, the NAS SHOULD NOT have
  1034.      sent an LCP CONFACK completing LCP negotiation, and the client and NAS
  1035.      MUST  NOT  have begun NCP negotiation. Rather than sending an LCP CON-
  1036.      FACK, the NAS will instead send an LCP DOWN message.  The  Client  MAY
  1037.      then  renegotiate  LCP,  and  from that point forward, all PPP packets
  1038.      originated from the client will be encapsulated and sent to the tunnel
  1039.      server.  In single authentication compulsory tunneling, L2TP authenti-
  1040.      cation forwarding MUST NOT be employed.
  1041.  
  1042.      If the tunnel server and NAS both are using the  same  RADIUS  server,
  1043.      the  RADIUS  server will respond to the tunnel server's Access-Request
  1044.      with an Access-Challenge packet containing tunnel  attributes  and  an
  1045.      EAP-Message  attribute,  as  before. On receiving the Access-Challenge
  1046.  
  1047.  
  1048.  
  1049.      Aboba & Zorn                                                 [Page 16]
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.      INTERNET-DRAFT                                            11 July 1997
  1056.  
  1057.  
  1058.      including tunnel attributes, the tunnel server will check whether  the
  1059.      tunnel  matches  the  attributes returned by the RADIUS server; if so,
  1060.      the tunnel attributes will be ignored, and the  EAP-Request  specified
  1061.      in the EAP-Message attribute will be sent to the Client. If the tunnel
  1062.      attributes do not match, then the tunnel server  MUST  disconnect  the
  1063.      call.
  1064.  
  1065.      When  LCP re-negotiation has been concluded, the NCP phase will begin,
  1066.      and the tunnel server will assign an address to the client.
  1067.  
  1068.      In performing the PPP authentication, the tunnel server can access its
  1069.      own  user  database, or it MAY send a RADIUS Access-Request. After the
  1070.      tunnel has been brought up,  the  NAS  and  tunnel  server  MAY  start
  1071.      accounting.
  1072.  
  1073.      The  interactions  involved  in initiation of a compulsory tunnel with
  1074.      single authentication are summarized below.
  1075.  
  1076.  
  1077.  
  1078.                                     INITIATION SEQUENCE
  1079.  
  1080.      NAS                            Tunnel Server       RADIUS Server
  1081.      ---                            -------------       -------------
  1082.      Call accepted
  1083.      LCP starts
  1084.      EAP authentication
  1085.       phase starts
  1086.      Send RADIUS
  1087.       Access-Request
  1088.       with EAP-Message/MyId
  1089.       attribute
  1090.                                                        IF MyId is known,
  1091.                                                        send RADIUS
  1092.                                                        Access-Challenge with
  1093.                                                          Tunnel-Type,
  1094.                                                          Tunnel-Medium-Type,
  1095.                                                          Tunnel-Server-Endpoint,
  1096.                                                          Tunnel-Password (optional)
  1097.                                                          EAP-Message (optional)
  1098.                                                        ELSE Send NAK
  1099.      IF NAK DISCONNECT
  1100.      ELSE
  1101.       IF no control
  1102.        connection exists
  1103.        Send
  1104.        Start-Control-Connection-Request
  1105.        to Tunnel Server
  1106.                                   Send
  1107.                                   Start-Control-Connection-Reply
  1108.                                   to NAS
  1109.       ENDIF
  1110.  
  1111.      Send
  1112.  
  1113.  
  1114.  
  1115.      Aboba & Zorn                                                 [Page 17]
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.      INTERNET-DRAFT                                            11 July 1997
  1122.  
  1123.  
  1124.      Incoming-Call-Request
  1125.      message to Tunnel Server
  1126.                                   Send Incoming-Call-Reply
  1127.                                   to NAS
  1128.      Send
  1129.      Incoming-Call-Connected
  1130.      message to Tunnel Server
  1131.  
  1132.      Send data through the tunnel
  1133.                                   Re-negotiate LCP,
  1134.                                   authenticate user via EAP,
  1135.                                   bring up IPCP,
  1136.                                   start accounting
  1137.                                   Send RADIUS
  1138.                                   Accounting-Request with
  1139.                                   Acct-Status-Type=Start
  1140.                                   (optional)
  1141.                                                        Send
  1142.                                                        RADIUS
  1143.                                                        Accounting-Response
  1144.      Send a RADIUS
  1145.      Accounting-Request message
  1146.      with Acct-Status-Type=Start
  1147.      containing
  1148.      Tunnel-Type, Tunnel-Medium-Type,
  1149.      Acct-Tunnel-Client-Endpoint,
  1150.      Tunnel-Server-Endpoint, and
  1151.      Acct-Tunnel-Connection-Id.
  1152.                                                        Send
  1153.                                                        RADIUS
  1154.                                                        Accounting-Response
  1155.  
  1156.      ENDIF
  1157.  
  1158.  
  1159.  
  1160.      9.  Dual authentication
  1161.  
  1162.  
  1163.  
  1164.      9.1.  Initiation sequence
  1165.  
  1166.      In the case of a dual authentication, a  typical  initiation  sequence
  1167.      looks like this:
  1168.  
  1169.           Client and NAS: PPP LCP negotiation
  1170.           Client and NAS: PPP authentication
  1171.           NAS to RADIUS Server: RADIUS Access-request
  1172.           RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
  1173.           NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
  1174.           Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
  1175.           NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
  1176.           Client and Tunnel Server: PPP LCP re-negotiation (optional)
  1177.           Client and Tunnel Server: PPP authentication
  1178.  
  1179.  
  1180.  
  1181.      Aboba & Zorn                                                 [Page 18]
  1182.  
  1183.  
  1184.  
  1185.  
  1186.  
  1187.      INTERNET-DRAFT                                            11 July 1997
  1188.  
  1189.  
  1190.           Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
  1191.           RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
  1192.           Client and Tunnel Server: NCP negotiation
  1193.           NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
  1194.           RADIUS Server to NAS: RADIUS Accounting-Response
  1195.           Tunnel Server to RADIUS Server: RADIUS Accounting-Request
  1196.              with Acct-Status-Type=Start (Optional)
  1197.           RADIUS Server to Tunnel Server: RADIUS Accounting-Response
  1198.  
  1199.      The  process  begins  with an incoming call to the NAS. The client and
  1200.      NAS then begin LCP negotiation. Subsequently  the  PPP  authentication
  1201.      phase starts, and the NAS sends a RADIUS Access-Request message to the
  1202.      RADIUS server. If the authentication is successful, the RADIUS  server
  1203.      responds  with  a  RADIUS Access-Accept. For users requiring mandatory
  1204.      tunneling, the Access-Accept MUST contain the the Tunnel-Type, Tunnel-
  1205.      Medium-Type,  and Tunnel-Server-Endpoint Attributes; a Tunnel-Password
  1206.      attribute is optional.
  1207.  
  1208.      In the case where a PPTP/L2TP tunnel is indicated, the  NAS  will  now
  1209.      bring  up a control connection if none existed before, and the NAS and
  1210.      tunnel server will bring up the call. At this point, data MAY begin to
  1211.      flow  through the tunnel. The client and tunnel server MAY now renego-
  1212.      tiate LCP and go through another round of PPP authentication.  At  the
  1213.      time  that  this renegotiation begins, the NAS SHOULD NOT have sent an
  1214.      LCP CONFACK completing LCP negotiation, and the client  and  NAS  MUST
  1215.      NOT  have  begun  NCP negotiation. Rather than sending an LCP CONFACK,
  1216.      the NAS will instead send an LCP DOWN message.  The  Client  MAY  then
  1217.      renegotiate  LCP,  and from that point forward, all PPP packets origi-
  1218.      nated from the client will be encapsulated  and  sent  to  the  tunnel
  1219.      server.   When  LCP  re-negotiation  has been concluded, the NCP phase
  1220.      will begin, and the tunnel  server  will  assign  an  address  to  the
  1221.      client.
  1222.  
  1223.      If  L2TP is being used as the tunnel protocol, the NAS MAY in its ini-
  1224.      tial setup notification include a copy of the  LCP  CONFACKs  sent  in
  1225.      each  direction which completed LCP negotiation. The tunnel server MAY
  1226.      then use this information to avoid an additional LCP negotiation. With
  1227.      L2TP,  the initial setup notification can also include the authentica-
  1228.      tion information required to allow the tunnel server  to  authenticate
  1229.      the user and decide to accept or decline the connection. However, this
  1230.      facility creates a vulnerability to replay  attacks,  and  can  create
  1231.      problems  in  the  case  where  the NAS and tunnel server authenticate
  1232.      against different RADIUS servers. As a result, where  user-based  tun-
  1233.      neling  via  RADIUS  is  implemented,  L2TP  authentication forwarding
  1234.      SHOULD NOT be employed.
  1235.  
  1236.      In performing the PPP authentication, the tunnel server can access its
  1237.      own  user database, or it MAY send a RADIUS Access-Request.  After the
  1238.      tunnel has been brought up,  the  NAS  and  tunnel  server  MAY  start
  1239.      accounting.
  1240.  
  1241.      The  interactions  involved  in initiation of a compulsory tunnel with
  1242.      dual authentication are summarized below.
  1243.  
  1244.  
  1245.  
  1246.  
  1247.      Aboba & Zorn                                                 [Page 19]
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.      INTERNET-DRAFT                                            11 July 1997
  1254.  
  1255.  
  1256.                                     INITIATION SEQUENCE
  1257.  
  1258.      NAS                            Tunnel Server       RADIUS Server
  1259.      ---                            -------------       -------------
  1260.      Call accepted
  1261.      LCP starts
  1262.      PPP authentication
  1263.       phase starts
  1264.      Send RADIUS
  1265.       Access-Request
  1266.       with username and
  1267.       authentication data
  1268.                                                         IF authentication
  1269.                                                         succeeds
  1270.                                                          Send ACK with
  1271.                                                          Tunnel-Type,
  1272.                                                          Tunnel-Medium-Type,
  1273.                                                          Tunnel-Server-Endpoint,
  1274.                                                          Tunnel-Password (optional)
  1275.                                                         ELSE Send NAK
  1276.      IF NAK DISCONNECT
  1277.      ELSE
  1278.       IF no control
  1279.        connection exists
  1280.        Send
  1281.        Start-Control-Connection-Request
  1282.        to Tunnel Server
  1283.                                   Send
  1284.                                   Start-Control-Connection-Reply
  1285.                                   to NAS
  1286.       ENDIF
  1287.  
  1288.      Send
  1289.      Incoming-Call-Request
  1290.      message to Tunnel Server
  1291.                                   Send Incoming-Call-Reply
  1292.                                   to NAS
  1293.      Send
  1294.      Incoming-Call-Connected
  1295.      message to Tunnel Server
  1296.  
  1297.      Send data through the tunnel
  1298.                                   Re-negotiate LCP,
  1299.                                   authenticate user,
  1300.                                   bring up IPCP,
  1301.                                   start accounting
  1302.                                   Send RADIUS
  1303.                                   Accounting-Request with
  1304.                                   Acct-Status-Type=Start
  1305.                                   (optional)
  1306.                                                        Send
  1307.                                                        RADIUS
  1308.                                                        Accounting-Response
  1309.      Send a RADIUS
  1310.  
  1311.  
  1312.  
  1313.      Aboba & Zorn                                                 [Page 20]
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.      INTERNET-DRAFT                                            11 July 1997
  1320.  
  1321.  
  1322.      Accounting-Request message
  1323.      with Acct-Status-Type=Start
  1324.      containing
  1325.      Tunnel-Type, Tunnel-Medium-Type,
  1326.      Acct-Tunnel-Client-Endpoint,
  1327.      Tunnel-Server-Endpoint, and
  1328.      Acct-Tunnel-Connection-Id.
  1329.                                                        Send
  1330.                                                        RADIUS
  1331.                                                        Accounting-Response
  1332.  
  1333.      ENDIF
  1334.  
  1335.  
  1336.      9.2.  EAP support
  1337.  
  1338.      It is expected  that  the  Extensible  Authentication  Protocol  (EAP)
  1339.      described  in  [13]  will  frequently  be used along with tunneling in
  1340.      order to provide additional security. EAP authentication may  be  used
  1341.      in  the  initial  NAS authentication, in the tunnel authentication, or
  1342.      both, with support of EAP within RADIUS described  in  [11].   In  the
  1343.      case  where  EAP  authentication  is  carried  out between the NAS and
  1344.      client, the initiation sequence will look like this:
  1345.  
  1346.           Client and NAS: PPP LCP negotiation
  1347.           Client and NAS: EAP Authentication
  1348.           NAS to RADIUS Server: RADIUS Access-Request/EAP-start
  1349.           RADIUS server to NAS: RADIUS Access-Challenge/EAP-Message
  1350.           NAS to Client: EAP-Request
  1351.           Client to NAS: EAP-Response
  1352.           NAS to RADIUS Server: RADIUS Access-Request/EAP-Message
  1353.           RADIUS server to NAS: RADIUS Access-Accept/EAP-Message/EAP-Success
  1354.           NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
  1355.           Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
  1356.           NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected
  1357.           Client and Tunnel Server: PPP LCP re-negotiation (optional)
  1358.           Client and Tunnel Server: PPP authentication
  1359.           Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
  1360.           RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
  1361.           Client and Tunnel Server: NCP negotiation
  1362.           NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
  1363.           RADIUS Server to NAS: RADIUS Accounting-Response
  1364.           Tunnel Server to RADIUS Server: RADIUS Accounting-Request
  1365.              With Acct-Status-Type=Start(Optional)
  1366.           RADIUS Server to Tunnel Server: RADIUS Accounting-Response
  1367.  
  1368.      In the case where EAP authentication is carried out between the client
  1369.      and tunnel server, the initiation sequence will look like this:
  1370.  
  1371.           Client and NAS: PPP LCP negotiation
  1372.           Client and NAS: PPP authentication
  1373.           NAS to RADIUS Server: RADIUS Access-request
  1374.           RADIUS server to NAS: RADIUS Access-Accept
  1375.           NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
  1376.  
  1377.  
  1378.  
  1379.      Aboba & Zorn                                                 [Page 21]
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.      INTERNET-DRAFT                                            11 July 1997
  1386.  
  1387.  
  1388.           Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
  1389.           NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
  1390.           Client and Tunnel Server: PPP LCP re-negotiation (optional)
  1391.           Client and Tunnel Server: EAP authentication
  1392.           Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start
  1393.           RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message
  1394.           Tunnel Server to Client: EAP-Request
  1395.           Client to Tunnel Server: EAP-Response
  1396.           Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message
  1397.           RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success
  1398.           Client and Tunnel Server: NCP negotiation
  1399.           NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
  1400.           RADIUS Server to NAS: RADIUS Accounting-Response
  1401.           Tunnel Server to RADIUS Server: RADIUS Accounting-Request with
  1402.              Acct-Status-Type=Start (Optional)
  1403.           RADIUS Server to Tunnel Server: RADIUS Accounting-Response
  1404.  
  1405.      For  the  negotiations  described above to succeed, the client must be
  1406.      capable of renegotiating EAP with the tunnel server after  an  initial
  1407.      authentication with the NAS.
  1408.  
  1409.  
  1410.      10.  Termination sequence
  1411.  
  1412.      The  tear  down of a compulsory tunnel involves an interaction between
  1413.      the client, NAS, Tunnel Server, and  RADIUS  Accounting  server.  This
  1414.      interaction  is  virtually  identical regardless of whether telephone-
  1415.      number based authentication, single authentication, or dual  authenti-
  1416.      cation is being used. In any of the cases, the following events occur:
  1417.  
  1418.           Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional)
  1419.           NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify
  1420.           NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Stop
  1421.           RADIUS Server to NAS: RADIUS Accounting-Response
  1422.           Tunnel Server to RADIUS Server: RADIUS Accounting-Request
  1423.              with Acct-Status-Type=Stop(Optional)
  1424.           RADIUS Server to Tunnel Server: RADIUS Accounting-Response
  1425.  
  1426.      Tunnel termination can occur due to a  client  request  (PPP  termina-
  1427.      tion), a tunnel server request (Call-Clear-Request), or a line problem
  1428.      (call disconnect).
  1429.  
  1430.      In the case of a client-requested termination, the tunnel server  MUST
  1431.      terminate  the PPP session. The tunnel server MUST subsequently send a
  1432.      Call-Clear-Request to the NAS. The NAS MUST then send  a  Call-Discon-
  1433.      nect-Notify  message  to  the  tunnel  server, and will disconnect the
  1434.      call.
  1435.  
  1436.      The NAS MUST also respond with a  Call-Disconnect-Notify  message  and
  1437.      disconnection  if  it  receives  a  Call-Clear-Request from the tunnel
  1438.      server without a client-requested termination.
  1439.  
  1440.      In the case of a line problem or user hangup,  the  NAS  MUST  send  a
  1441.      Call-Disconnect-Notify to the tunnel server. Both sides will then tear
  1442.  
  1443.  
  1444.  
  1445.      Aboba & Zorn                                                 [Page 22]
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.      INTERNET-DRAFT                                            11 July 1997
  1452.  
  1453.  
  1454.      down the  call.
  1455.  
  1456.      After call tear down is complete, if RADIUS accounting is  being  used
  1457.      then  the  NAS MUST send a RADIUS Accounting-Request with Acct-Status-
  1458.      Type=Stop packet to  a  RADIUS  accounting  server.   The  Accounting-
  1459.      Request  packet  MUST  include  the following attributes: Tunnel-Type,
  1460.      Tunnel-Medium-Type,  Acct-Tunnel-Client-Endpoint,   Tunnel-Server-End-
  1461.      point, and Acct-Tunnel-Connection-Id.
  1462.  
  1463.      The  tunnel  server  MAY produce its own accounting records, or it MAY
  1464.      use RADIUS accounting. If RADIUS accounting is  being  used  then  the
  1465.      tunnel  server MUST send a RADIUS Accounting-Request with Acct-Status-
  1466.      Type=Stop to a RADIUS accounting server. The Accounting-Request packet
  1467.      MUST  contain  the  following  attributes: Tunnel-Type, Tunnel-Medium-
  1468.      Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-Endpoint,  and  Acct-
  1469.      Tunnel-Connection-Id.
  1470.  
  1471.      The  interactions  involved  in termination of a compulsory tunnel are
  1472.      summarized below. In order to simplify the diagram  that  follows,  we
  1473.      have  left  out  the client. However, it is understood that the client
  1474.      MAY participate via PPP termination and disconnection.
  1475.  
  1476.                                     TERMINATION SEQUENCE
  1477.  
  1478.      NAS                            Tunnel Server         RADIUS Server
  1479.      ---                            -------------         -------------
  1480.      IF user disconnected
  1481.       send
  1482.       Call-Disconnect-Notify
  1483.       message to tunnel server
  1484.                                     Tear down the call
  1485.                                     stop accounting
  1486.                                     Send RADIUS
  1487.                                     Accounting-Request with
  1488.                                     Acct-Status-Type=Stop
  1489.                                     (optional)
  1490.                                                          Send RADIUS
  1491.                                                          Accounting-Response
  1492.      ELSE IF client requests
  1493.       termination
  1494.                                     send
  1495.                                     Call-Clear-Request
  1496.                                     to the NAS
  1497.       Send
  1498.       Call-Disconnect-Notify
  1499.       message to tunnel server
  1500.       Disconnect the user
  1501.                                     Tear down the call
  1502.                                     stop accounting
  1503.                                     Send RADIUS
  1504.                                     Accounting-Request with
  1505.                                     Acct-Status-Type=Stop
  1506.                                     (optional)
  1507.                                                          Send RADIUS
  1508.  
  1509.  
  1510.  
  1511.      Aboba & Zorn                                                 [Page 23]
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.      INTERNET-DRAFT                                            11 July 1997
  1518.  
  1519.  
  1520.                                                          Accounting-Response
  1521.  
  1522.       Send a RADIUS
  1523.       Accounting-Request message
  1524.       with Acct-Status-Type=Stop
  1525.       containing
  1526.       Tunnel-Type, Tunnel-Medium-Type,
  1527.       Acct-Tunnel-Client-Endpoint,
  1528.       Tunnel-Server-Endpoint, and
  1529.       Acct-Tunnel-Connection-Id.
  1530.                                                          Send RADIUS
  1531.                                                          Accounting-Response
  1532.  
  1533.      ENDIF
  1534.  
  1535.  
  1536.  
  1537.      11.  Use of distinct RADIUS servers
  1538.  
  1539.      In the case that the NAS and the  tunnel  server  are  using  distinct
  1540.      RADIUS  servers,  some interesting cases can arise in the provisioning
  1541.      of compulsory tunnels.
  1542.  
  1543.  
  1544.      11.1.  Distinct userIDs
  1545.  
  1546.      If distinct RADIUS servers are being used, it is likely that  distinct
  1547.      userID/password pairs will be required to complete the RADIUS and tun-
  1548.      nel authentications. One pair will be used in the initial PPP  authen-
  1549.      tication with the NAS, and the second pair will be used for the tunnel
  1550.      authentication.
  1551.  
  1552.      However, in order to provide maximum ease of use in the case where the
  1553.      userID/password  pairs are identical, tunnel clients typically attempt
  1554.      authentication with the same userID/password pair as was used  in  the
  1555.      initial PPP negotiation. Only after this fails do they prompt the user
  1556.      for the second pair.
  1557.  
  1558.      In this case, tunnel client implementations SHOULD take  care  not  to
  1559.      put  up  error  messages  indicating  a bad password. Instead a dialog
  1560.      SHOULD be presented requesting the tunnel userID/password combination.
  1561.  
  1562.      In the case where smart cards are being used for both authentications,
  1563.      the tunnel client MUST NOT attempt to present the token  used  in  the
  1564.      first  authentication  during  the  second authentication, since these
  1565.      will never be identical. Instead the user SHOULD be prompted to  enter
  1566.      the second token.
  1567.  
  1568.      The same issue arises in L2TP if the NAS attempts to forward authenti-
  1569.      cation information to the tunnel server in the initial setup notifica-
  1570.      tion. Since the userID/password pair used for tunnel authentication is
  1571.      different from that used to authenticate against the  NAS,  forwarding
  1572.      authentication  information  in  this  manner  will  cause  the tunnel
  1573.      authentication to fail. As a result, where  user-based  tunneling  via
  1574.  
  1575.  
  1576.  
  1577.      Aboba & Zorn                                                 [Page 24]
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.      INTERNET-DRAFT                                            11 July 1997
  1584.  
  1585.  
  1586.      RADIUS  is  implemented,  L2TP authentication forwarding SHOULD NOT be
  1587.      employed.
  1588.  
  1589.  
  1590.      11.2.  Multilink PPP issues
  1591.  
  1592.      It is possible for the two RADIUS servers to  return  different  Port-
  1593.      Limit  attributes.  For example, it is conceivable that the NAS RADIUS
  1594.      server will only grant use of  a  single  channel,  while  the  tunnel
  1595.      RADIUS server will grant more than one channel. In this case, the cor-
  1596.      rect behavior is for the tunnel client to open a connection to another
  1597.      NAS  in order to bring up a multilink bundle on the tunnel server. The
  1598.      client MUST NOT indicate to the NAS that this additional link is being
  1599.      brought  up as part of a multilink bundle; this will only be indicated
  1600.      in the subsequent negotiation with the tunnel server.
  1601.  
  1602.      It is also conceivable that the  NAS  RADIUS  server  will  allow  the
  1603.      client  to  bring  up  multiple  channels,  but that the tunnel RADIUS
  1604.      server will allow fewer channels than the NAS RADIUS server.  In  this
  1605.      case, the client should terminate use of the excess channels.
  1606.  
  1607.  
  1608.      12.  UserID Issues
  1609.  
  1610.      In  the  provisioning  of  roaming and shared use networks, one of the
  1611.      requirements is to be able to route the authentication request to  the
  1612.      user's home RADIUS server. This authentication routing is accomplished
  1613.      based on the userID submitted by the user to the NAS  in  the  initial
  1614.      PPP  authentication.  The userID is subsequently relayed by the NAS to
  1615.      the RADIUS server in the User-Name attribute, as part  of  the  RADIUS
  1616.      Access-Request.
  1617.  
  1618.      Similarly, references [5] and [6] refer to use of the userID in deter-
  1619.      mining the tunnel endpoint. However, since none  of  these  references
  1620.      provide  guidelines  for  how RADIUS or tunnel routing is to be accom-
  1621.      plished, the possibility of conflicting interpretations exists.
  1622.  
  1623.  
  1624.      12.1.  UserID convergence in user-based tunneling
  1625.  
  1626.      The use of RADIUS in provisioning of compulsory tunneling relieves the
  1627.      userID  from having to do double duty. Rather than being used both for
  1628.      routing of the RADIUS authentication/authorization request as well for
  1629.      determination  of  the  tunnel endpoint, the userID is now used solely
  1630.      for routing of RADIUS authentication/authorization requests. The  Tun-
  1631.      nel-Server-Endpoint  attribute  returned in the RADIUS Access-Response
  1632.      Is then used to determine the tunnel endpoint.
  1633.  
  1634.      Since the framework described in this document allows  both  ISPs  and
  1635.      tunnel users to authenticate users as well as to account for resources
  1636.      consumed by  them,  and  provides  for  maintenance  of  two  distinct
  1637.      userID/password pairs, this scheme provides a high degree of flexibil-
  1638.      ity.  Where RADIUS proxies and tunneling are employed, it is  possible
  1639.      to  allow  the user to authenticate with a single userID/password pair
  1640.  
  1641.  
  1642.  
  1643.      Aboba & Zorn                                                 [Page 25]
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.      INTERNET-DRAFT                                            11 July 1997
  1650.  
  1651.  
  1652.      at both the NAS and the tunnel endpoint. This is accomplished by rout-
  1653.      ing  the  NAS  RADIUS Access-Request to the same RADIUS server used by
  1654.      the tunnel server.
  1655.  
  1656.      As described  in  [8],  the  recommended  form  for  the  user  ID  is
  1657.      userID@realm, i.e. fred@bigco.com.
  1658.  
  1659.  
  1660.      13.  Acknowledgements
  1661.  
  1662.      Thanks  to Gurdeep Singh Pall of Microsoft for many useful discussions
  1663.      of this problem space, and to Allan  Rubens  of  Ascend  and  Bertrand
  1664.      Buclin of AT&T Labs Europe for his comments on this document.
  1665.  
  1666.  
  1667.      14.  References
  1668.  
  1669.      [1]   B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of Roaming
  1670.      Implementations."  Work in progress, draft-ietf-roamops-imprev-04.txt,
  1671.      Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, June, 1997.
  1672.  
  1673.      [2]  B. Aboba, G. Zorn.  "Dialup Roaming Requirements." Internet draft
  1674.      (work  in  progress),  draft-ietf-roamops-roamreq-05.txt,   Microsoft,
  1675.      July, 1997.
  1676.  
  1677.      [3]   C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote Authenti-
  1678.      cation Dial In User Service (RADIUS)." RFC  2058,  Livingston,  Merit,
  1679.      Daydreamer, January, 1997.
  1680.  
  1681.      [4]   C.  Rigney.  "RADIUS Accounting." RFC 2059, Livingston, January,
  1682.      1997.
  1683.  
  1684.      [5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud,  A.  J.
  1685.      Valencia,  W.  Verthein.   "Layer  Two Tunneling Protocol -- L2TP." ."
  1686.      Internet  draft  (work  in  progress),  draft-ietf-pppext-l2tp-04.txt,
  1687.      Ascend  Communications,  Microsoft,  Copper  Mountain  Networks,  U.S.
  1688.      Robotics, June, 1997.
  1689.  
  1690.      [6] K. Hamzeh, G. S. Pall, J.  Taarud,  W.  Verthein,  W.  A.  Little.
  1691.      "Point-to-Point  Tunneling  Protocol -- PPTP." ." Internet draft (work
  1692.      in progress),  draft-ietf-pppext-pptp-01.txt,  Ascend  Communications,
  1693.      Microsoft, Copper Mountain Networks, U.S. Robotics, December, 1996.
  1694.  
  1695.      [7]  G. Zorn.  "RADIUS Attributes for Tunnel Protocol Support." Inter-
  1696.      net draft (work  in  progress),  draft-ietf-radius-tunnel-auth-02.txt,
  1697.      Microsoft, July, 1997.
  1698.  
  1699.      [8]  B. Aboba, M. A. Beadles.  "The Network Access Identifier." Inter-
  1700.      net   draft   (work   in   progress),   draft-ietf-roamops-nai-06.txt,
  1701.      Microsoft, CompuServe, July, 1997.
  1702.  
  1703.      [9]  S.  Bradner.   "Key words for use in RFCs to Indicate Requirement
  1704.      Levels." RFC 2119, Harvard University, March, 1997.
  1705.  
  1706.  
  1707.  
  1708.  
  1709.      Aboba & Zorn                                                 [Page 26]
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.      INTERNET-DRAFT                                            11 July 1997
  1716.  
  1717.  
  1718.      [10] C. Rigney, W. Willats.  "RADIUS Extensions."  Work  in  progress,
  1719.      draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
  1720.  
  1721.      [11]  P.  Calhoun,  A.C. Rubens, B. Aboba.  "Extensible Authentication
  1722.      Protocol Support in RADIUS." Internet draft (work in progress), draft-
  1723.      ietf-radius-eap-02.txt,  US  Robotics  Access  Corp.,  Merit  Network,
  1724.      Microsoft, May, 1997.
  1725.  
  1726.      [12] M. Wahl, T. Howes, S. Kille.  "Lightweight Directory Access  Pro-
  1727.      tocol  (v3)."  ."  Internet draft (work in progress), draft-ietf-asid-
  1728.      ldapv3-protocol-04.txt, Critical Angle Inc., Netscape, Isode  Limited,
  1729.      March, 1997.
  1730.  
  1731.      [13]  L.  J.  Blunk, J. R. Vollbrecht.  "PPP Extensible Authentication
  1732.      Protocol (EAP)." ." Internet draft  (work  in  progress),  draft-ietf-
  1733.      pppext-eap-auth-02.txt, Merit Network, Inc., June, 1996.
  1734.  
  1735.  
  1736.  
  1737.  
  1738.  
  1739.      15.  Authors' Addresses
  1740.  
  1741.      Bernard Aboba
  1742.      Microsoft Corporation
  1743.      One Microsoft Way
  1744.      Redmond, WA 98052
  1745.  
  1746.      Phone: 425-936-6605
  1747.      EMail: bernarda@microsoft.com
  1748.  
  1749.      Glen Zorn
  1750.      Microsoft Corporation
  1751.      One Microsoft Way
  1752.      Redmond, WA 98052
  1753.  
  1754.      Phone: 425-703-1559
  1755.      EMail: glennz@microsoft.com
  1756.  
  1757.  
  1758.  
  1759.  
  1760.  
  1761.  
  1762.  
  1763.  
  1764.  
  1765.  
  1766.  
  1767.  
  1768.  
  1769.  
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775.      Aboba & Zorn                                                 [Page 27]
  1776.  
  1777.  
  1778.