[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 07 rfc2809                                  
     RADIUS Working Group                                     Bernard Aboba
     INTERNET-DRAFT                                               Microsoft
     Category: Standards Track                                    Glen Zorn
     <draft-ietf-radius-tunnel-imp-03.txt>                        Microsoft
     26 July 1997
     
     
          Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing documents as Internet-Drafts.
     
     Internet-Drafts are draft documents valid for a maximum of six  months
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as ``work in progress.''
     
     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
     
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-radius-tunnel-imp-03.txt> and  expires February 1, 1998.   Please
     send comments to the authors.
     
     
     2.  Abstract
     
     This  document  discusses  implementation issues arising in the provi-
     sioning of compulsory tunneling in dial-up networks using the PPTP and
     L2TP  protocols.   This provisioning can be accomplished via the inte-
     gration of  RADIUS  and  tunneling  protocols.  Implementation  issues
     encountered  with other tunneling protocols are left to separate docu-
     ments.
     
     
     
     3.  Terminology
     
     
     Voluntary Tunneling
               In voluntary tunneling, a tunnel is  created  by  the  user,
               typically via use of a tunneling client.
     
     Compulsory Tunneling
               In  compulsory  tunneling,  a  tunnel is created without any
               action from the user  and  without  allowing  the  user  any
               choice.
     
     
     
     Aboba & Zorn                                                  [Page 1]


     INTERNET-DRAFT                                            26 July 1997
     
     
     Roaming   "Roaming capability" can be loosely defined  as  the ability
               to use  any  one  of  multiple  Internet  service  providers
               (ISPs),  while maintaining a formal,  customer-vendor  rela-
               tionship  with  only one. Examples  of  cases  where roaming
               capaility might be required include ISP "confederations" and
               ISP-provided corporate network access support.
     
     Shared Use Network
               This is an IP dialup network whose use is shared by  two  or
               more organizations.  Shared use networks typically implement
               distributed authentication and accounting in order to facil-
               itate   the relationship  among  the  sharing parties. Since
               these facilities are also  required  for  implementation  of
               roaming,  implementation of shared use is frequently a first
               step toward development of roaming  capabilities. In   fact,
               one  of  the ways by which a provider can offer roaming ser-
               vice is to conclude shared use agreements with multiple net-
               works.  However,  to date the ability to accomplish this has
               been hampered by lack of interoperability among  shared  use
               implementations.
     
     Tunnel Network Server
               This  is  a server which terminates a tunnel. In PPTP termi-
               nology, this is known as the PPTP Network Server  (PNS).  In
               L2TP  terminology,  this is known as the L2TP Network Server
               (LNS).
     
     Network Access Server
               The Network Access Server (NAS) is the device  that  clients
               contact  in order to get access to the network. In PPTP ter-
               minology this is referred to as the PPTP Access Concentrator
               (PAC).  In  L2TP  terminology, the NAS is referred to as the
               L2TP Access Concentrator (LAC).
     
     RADIUS server
               This is a server which  provides  for  authentication/autho-
               rization via the protocol described in [3], and for account-
               ing as described in [4].
     
     RADIUS proxy
               In order to provide for the routing of RADIUS authentication
               and  accounting requests, a RADIUS proxy can be employed. To
               the NAS, the RADIUS proxy appears to act as a RADIUS server,
               and  to  the  RADIUS  server,  the proxy appears to act as a
               RADIUS client.
     
     Network Access Identifier
               In order to provide for the routing of RADIUS authentication
               and accounting requests, the userID field used in PPP and in
               the  subsequent   RADIUS   authentication   and   accounting
               requests,  known  as the Network Access Identifier (NAI) MAY
               contain structure. This structure provides a means by  which
               the  RADIUS  proxy  will locate the RADIUS server that is to
               receive the request. This same structure MAY also be used to
     
     
     
     Aboba & Zorn                                                  [Page 2]


     INTERNET-DRAFT                                            26 July 1997
     
     
               locate  the  tunnel  endpoint when domain-based tunneling is
               used.
     
     
     4.  Requirements language
     
     This specification uses the same words as [9] for defining the signif-
     icance of each particular requirement.  These words are:
     
     
     MUST      This  word,  or  the adjectives "REQUIRED" or "SHALL", means
               that the definition is an absolute requirement of the speci-
               fication.
     
     MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
               nition is an absolute prohibition of the specification.
     
     SHOULD    This word, or the adjective "RECOMMENDED", means that  there
               MAY  exist  valid  reasons  in  particular  circumstances to
               ignore a particular item, but the full implications must  be
               understood and carefully weighed before choosing a different
               course.
     
     SHOULD NOT
               This phrase means that there MAY exist valid reasons in par-
               ticular   circumstances  when  the  particular  behavior  is
               acceptable or even useful, but the full implications  should
               be  understood  and the case carefully weighed before imple-
               menting any behavior described with this label.
     
     MAY       This word, or the adjective "OPTIONAL", means that  an  item
               is  truly  optional.   One  vendor may choose to include the
               item because a particular marketplace requires it or because
               the  vendor feels that it enhances the product while another
               vendor may omit the same item.  An implementation which does
               not include a particular option MUST be prepared to interop-
               erate with another implementation  which  does  include  the
               option,  though  perhaps  with reduced functionality. In the
               same vein an implementation which does include a  particular
               option  MUST be prepared to interoperate with another imple-
               mentation which does  not  include  the  option.(except,  of
               course, for the feature the option provides)
     
     Silently Discard
               The  implementation  discards  the  datagram without further
               processing, and without indicating an error to  the  sender.
               The  implementation SHOULD provide the capability of logging
               the error, including the contents of the discarded datagram,
               and SHOULD record the event in a statistics counter.
     
     An  implementation is not compliant if it fails to satisfy one or more
     of the MUST or MUST NOT requirements for the protocols it  implements.
     An  implementation  that  satisfies all the MUST, MUST NOT, SHOULD and
     SHOULD  NOT  requirements  for   its   protocols   is   said   to   be
     
     
     
     Aboba & Zorn                                                  [Page 3]


     INTERNET-DRAFT                                            26 July 1997
     
     
     "unconditionally  compliant"; one that satisfies all the MUST and MUST
     NOT requirements but not all the SHOULD or SHOULD NOT requirements for
     its protocols is said to be "conditionally compliant."
     
     
     5.  Introduction
     
     Many  applications  of  tunneling  protocols  involve  dial-up network
     access. Some, such  as the provisioning of secure access to  corporate
     intranets  via the Internet, are characterized by voluntary tunneling:
     the tunnel is created at the request of the user for a  specific  pur-
     pose.  Other  applications involve compulsory tunneling: the tunnel is
     created without any action from the user and without allowing the user
     any choice.
     
     Examples  of  applications  that might be implemented using compulsory
     tunnels are Internet software upgrade servers,  software  registration
     servers  and  banking services.  These are all services which, without
     compulsory tunneling, would probably be provided using dedicated  net-
     works  or  at least dedicated network access servers (NAS), since they
     are characterized by the need to limit user access to specific  hosts.
     
     Given  the  existence  of widespread support for compulsory tunneling,
     however, these types of services could be accessed  via  any  Internet
     service provider (ISP).  The most popular means of authorizing dial-up
     network users today is through  the  RADIUS   protocol.  The  use   of
     RADIUS allows the dial-up users' authorization and authentication data
     to be maintained in a central location,  rather  than on each NAS.  It
     makes  sense  to use RADIUS to centrally  administer  compulsory  tun-
     neling,  since  RADIUS  is   widely deployed  and  was   designed   to
     carry  this  type of information.  New RADIUS attributes are needed to
     carry the tunneling  information  from the  RADIUS server to  the  NAS
     and  to transfer accounting data from the NAS to the RADIUS accounting
     server; those attributes are defined in [7].
     
     
     5.1.  Tunneling attributes
     
     As described in [7], provisioning of compulsory tunneling with  RADIUS
     requires no new RADIUS messages, and implementation of five new RADIUS
     attributes: Tunnel-Type,  Tunnel-Medium-Type,  Acct-Tunnel-Client-End-
     point, Tunnel-Server-Endpoint, and Acct-Tunnel-Connection-Id.
     
     The  Tunnel-Type  attribute  indicates the tunneling protocol(s) to be
     used (PPTP, L2F, L2TP, ATMP, VTP, IPSEC AH, IP-IP). It MAY be included
     in Access-Request, Access-Accept, and Access-Challenge  packets.
     
     The   Tunnel-Medium-Type Attribute indicates which transport medium to
     use (IP, X.25, ATM, Frame Relay) when creating a tunnel for those pro-
     tocols  (such   as   L2TP) that  can operate over multiple transports.
     It MAY be included in in Access-Request,  Access-Accept,  and  Access-
     Challenge  packets.
     
     
     
     
     
     Aboba & Zorn                                                  [Page 4]


     INTERNET-DRAFT                                            26 July 1997
     
     
     Acct-Tunnel-Client-Endpoint contains the address of the NAS end of the
     tunnel.  It  SHOULD be included in  Accounting-Request  packets  which
     contain  Acct-Status-Type  attributes  with values of either Start  or
     Stop.  This  Attribute,  along  with  the  Tunnel-Server-Endpoint  and
     Acct-Tunnel-Connection-ID  attributes,  may be used to provide a glob-
     ally unique means to identify a tunnel for accounting purposes.
     
     Tunnel-Server-Endpoint indicates the address of the server end of  the
     tunnel.   It  SHOULD  be included in  Accounting-Request packets which
     contain Acct-Status-Type attributes with values  of  either  Start  or
     Stop.
     
     Acct-Tunnel-Connection-ID  indicates  the  identifier  assigned to the
     call.  It SHOULD be included in   Accounting-Request   packets   which
     contain  Acct-Status-Type   attributes  with values of either Start or
     Stop.
     
     Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS
     server may be processed by one or more proxies prior to being received
     by the NAS. In order to ensure that tunnel attributes  arrive  without
     modification,  intermediate RADIUS proxies forwarding the Access-Reply
     MUST NOT modify tunnel attributes. If the RADIUS proxy does  not  sup-
     port tunnel attributes, then it MUST send an Access-Reject to the NAS.
     This is necessary to ensure that the user is only  granted  access  if
     the services requested by the RADIUS server can be provided.
     
     Since  RADIUS  tunnel  attributes  are  used for compulsory tunneling,
     address assignment is handled by the tunnel  server  rather  than  the
     NAS.  As  a  result,  if  tunnel  attributes are present, the NAS MUST
     ignore any address assignment attributes sent by the RADIUS server. In
     addition,  the  NAS  and  client MUST NOT begin NCP negotiation, since
     this could create a time window in which the client will be capable of
     sending packets to the transport network, which is not permitted under
     compulsory tunneling.
     
     
     5.2.  Advantanges of RADIUS-based compulsory tunneling
     
     The use of RADIUS in provisioning of compulsory  tunnels  has  several
     advantages. These include:
     
          User-based tunneling
          Auditing capabilities
          Telephone-number based authentication and accounting
          Single or dual authentication
     
     
     5.2.1.  User-based Tunneling
     
     Current  proposals  for routing of tunnel requests include static tun-
     neling, where all users are automatically tunneled  to  a  given  end-
     point,  and realm-based tunneling, where the tunnel endpoint is deter-
     mined from the realm portion of the userID.  User-based  tunneling  as
     provided   by  integration  of  RADIUS  and  tunnel  protocols  offers
     
     
     
     Aboba & Zorn                                                  [Page 5]


     INTERNET-DRAFT                                            26 July 1997
     
     
     significant advantages over both of these approaches.
     
     Static tunneling requires dedication of a NAS device to  the  purpose.
     In the case of an ISP, this is undesirable because it requires them to
     dedicate a NAS to tunneling service for a  given  corporate  customer,
     rather than allowing them to use existing NASes deployed in the field.
     As a result static tunneling is likely to be costly for deployment  of
     a global service.
     
     Realm-based tunneling assumes that all users within a given realm wish
     to be treated the same way. This limits a corporation's flexibility in
     managing  the  account  rights  of their users. For example, BIGCO may
     desire to provide Janet with an account that allows access to both the
     Internet  and the intranet, with Janet's intranet access provided by a
     tunnel server located in the engineering department. However BIGCO may
     desire  to  provide  Fred with an account that provides only access to
     the intranet, with Fred's intranet access provided by a tunnel network
     server  located  in  the  sales department. Such a situation cannot be
     accommodated with realm-based tunneling.
     
     On the other hand, user-based tunneling as enabled by  the  attributes
     defined  in [7] provides BIGCO with the flexibility to administer tun-
     neling behavior on a per-user basis. When  deployed  in  concert  with
     roaming,  user-based tunneling offers corporations the ability to pro-
     vide their users with access to the corporate  Intranet  on  a  global
     basis.
     
     
     5.3.  Auditing Capabilities
     
     The  integration of RADIUS and tunnel protocols allows the ISP and the
     corporation to synchronize their accounting activities  so  that  each
     side  receives  a record of the user's resource consumption. This pro-
     vides the corporation with the means to audit ISP bills.
     
     The    Acct-Tunnel-Client-Endpoint    and    Acct-Tunnel-Connection-ID
     attributes  were introduced in [7] in order to support auditing. These
     attributes are included within the  RADIUS  Accounting-Request  packet
     along  with  other attributes such as the User-Name and Tunnel-Server-
     Endpoint.  During accounting, the  User-Name,  Acct-Tunnel-Connection-
     ID,  Acct-Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes
     uniquely identify the call. This allows the Accounting-Request sent by
     the  NAS  to  be  reconciled with the corresponding Accounting-Request
     sent by the tunnel server.
     
     When implementing L2TP compulsory tunneling based on RADIUS,  the  NAS
     MUST  transmit the Call-Serial-Number in the Acct-Tunnel-Connection-ID
     attribute in  the  Accounting-Request  packet.  In  order  to  protect
     against wrapping due to reboots or call volume, a 64-bit NTP timestamp
     SHOULD be used as the Call-Serial Number. This feasible in L2TP  since
     the Call-Serial-Number string is of variable length.
     
     When  implementing  PPTP compulsory tunneling based on RADIUS, the NAS
     MUST transmit the Call-Serial-Number in the  Acct-Tunnel-Connection-ID
     
     
     
     Aboba & Zorn                                                  [Page 6]


     INTERNET-DRAFT                                            26 July 1997
     
     
     attribute in the Accounting-Request packet.  While [6] states that the
     Call-Serial-Number SHOULD be unique, this is not required.   In  addi-
     tion,  no  method for determining the Call-Serial-Number is specified,
     which leaves open the possibility of wrapping after a reboot.
     
     Since the Call-Serial-Number is a 16-bit value, the Call-Serial-Number
     is  not  sufficient  to  distinguish a given call from all other calls
     over an extended time period. For example, let us assume that the Call
     Serial  Number is assigned monotonically, and that the NAS in question
     has 96 ports. If the NAS ports are kept continually busy and the aver-
     age  call  is of 20 minutes duration, then the Call Serial Number will
     wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.5 days.
     
     In order to rectify this, it is recommended that  another  message  be
     added  to PPTP so that the NAS could provide the tunnel server with an
     Acct-Tunnel-Connection-ID unique over an extended time period.  It  is
     recommended that a 64-bit NTP timestamp be used for this purpose.
     
     
     5.4.  Telephone-number based authentication and accounting
     
     Using  the Calling-Station-Id and Called-Station-Id RADIUS attributes,
     authorization and subsequent tunnel attributes can  be  based  on  the
     phone  number  originating  the call, or the number being called. This
     allows the RADIUS server to authorize users based on the calling phone
     number  (with  or without a userID/password combination), or to select
     the  Tunnel-Type,   Tunnel-Medium-Type,   and   Tunnel-Server-Endpoint
     attributes based on the Calling-Station-Id or Called-Station-Id.  Sim-
     ilarly, in PPTP/L2TP the tunnel server MAY choose to reject or  accept
     the call based on the Dialed Number and Dialing Number included in the
     PPTP/L2TP Incoming-Call-Request packet sent by the NAS.
     
     The use of RADIUS accounting by  the  NAS  and/or  the  tunnel  server
     allows  for  accounting  to take place based on the Calling-Station-Id
     and Called-Station-Id.
     
     
     5.5.  Single or dual authentication
     
     As described below, RADIUS-based compulsory tunneling  can  support  a
     variety of authentication configurations. These include single authen-
     tication, where the user is authenticated at  the  tunnel  server,  or
     dual  authentication,  where the user is authenticated at both the NAS
     and the tunnel server. When  single  authentication  is  supported,  a
     variety  of  modes  are  possible,  including  telephone-number  based
     authentication described  above,  or  EAP-based  authentication.  When
     dual-authentication  is used, a number of modes are available, includ-
     ing    dual    CHAP    authentications;    CHAP/EAP    authentication;
     CHAP/PAP(token)  authentication; and EAP/EAP authentication, using the
     same EAP type for both authentications.
     
     PAP/PAP, CHAP/PAP and EAP/PAP dual authentications SHOULD NOT be used,
     since  these  combinations involve transmission of cleartext passwords
     over the Internet.
     
     
     
     Aboba & Zorn                                                  [Page 7]


     INTERNET-DRAFT                                            26 July 1997
     
     
     6.  Authentication alternatives in compulsory tunneling
     
     There are  several  authentication  alternatives  for  integration  of
     RADIUS and tunneling:
     
          Authenticate at the NAS
          Authenticate at the NAS, and forward the RADIUS reply
          Authenticate at the tunnel network server
          Authenticate at both the NAS and the tunnel network server
     
     We discuss each of these alternatives in turn.
     
     
     6.1.  Authenticate at the NAS
     
     With  this  approach, authentication and authorization (including tun-
     neling information) occurs once, at the NAS. The  advantages  of  this
     approach  are  that  it  disallows network access for unauthorized NAS
     users; and allows RADIUS accounting to be used at the  NAS.  Disadvan-
     tages  are  that  it requires that the tunnel network server trust the
     NAS, since no user authentication occurs on the tunnel network  server
     end  of  the  tunnel. Another disadvantage is that this does not allow
     LCP parameters to be re-negotiated by the tunnel network server. Also,
     due  to  the lack of user authentication, accounting cannot take place
     at the tunnel network server with strong assurance  that  the  correct
     party  is  being  billed.  As  a  result, it does not appear that this
     scheme can be practically employed.
     
     
     6.2.  Authenticate at the NAS, and forward the RADIUS reply
     
     With this approach, authentication and authorization occurs  once,  at
     the  NAS  end  of  the tunnel and the RADIUS reply is forwarded to the
     tunnel network server. This  approach  disallows  network  access  for
     unauthorized  NAS  users;  does  not require trust between the NAS and
     tunnel network server ends  of  the  tunnel;  and  allows  for  RADIUS
     accounting  to  be  used  at both ends of the tunnel. However, it also
     requires that both ends share the same secret with the RADIUS  server,
     since  that is the only way that the tunnel network server could check
     the RADIUS reply.
     
     In this approach,  the tunnel network server MUST share  secrets  with
     all the NASes and associated RADIUS servers, and there is no provision
     for LCP renegotiation by the tunnel network server. Also,  the  tunnel
     network server MUST know how to handle and verify RADIUS Access-Accept
     messages.
     
     While this scheme can be workable if the reply comes directly  from  a
     RADIUS  server,  it  would  become  unmanageable  if a RADIUS proxy is
     involved, since the reply would  be  authenticated  using  the  secret
     shared  by  the  client and proxy, rather than the RADIUS server. As a
     result, it does  not  appear  that  this  scheme  can  be  practically
     employed.
     
     
     
     
     Aboba & Zorn                                                  [Page 8]


     INTERNET-DRAFT                                            26 July 1997
     
     
     6.3.  Authenticate at the tunnel network server
     
     In  this  scheme,  authentication and authorization occurs once at the
     tunnel network server. This requires that the NAS determine  that  the
     user needs to be tunneled (through RADIUS or NAS configuration). Where
     RADIUS is used, the determination can be made using one of the follow-
     ing methods:
     
          Telephone-number based authentication
          User-Name
          EAP Identity
     
     
     6.3.1.  Telephone-number based authentication
     
     Where  telephone-number based authentication is used, the Calling-Sta-
     tion-Id or Called-Station-Id attributes included in the RADIUS Access-
     Request  are  used  to  determine whether the call will be accepted or
     rejected, and if accepted, where the user is  to  be  tunneled.  Where
     telephone-number based authentication is used, the User-Name and User-
     Password or CHAP-Password attributes need not be present.
     
     In  cases  where  telephone-number  authentication  may  be  employed,
     accounting  may  be  accomplished on the NAS side via the Calling-Sta-
     tion-Id or Called-Station-Id, and on the tunnel server side,  via  the
     userID.  Thus  this scheme is capable of providing both authentication
     and accounting, and appears practical to implement.
     
     
     6.3.2.  User-Name
     
     Where the User-Name attribute is present, RADIUS  as  defined  in  [3]
     requires  that  either  a  CHAP-Password or User-Password attribute be
     present in an Access-Request message, as well as  requiring  that  the
     password  be  non-empty.  Thus, this scheme either requires attribute-
     specific processing on the RADIUS server, or addition  of  an  "Autho-
     rize-Only" message.
     
     In attribute-specific processing an attribute is used to signal tunnel
     initiation.  For example, tunnel attributes can be sent  back  if  the
     PAP  password  is empty (or "tunnel" or "L2TP"). Alternatively, a user
     could prefix the userID with some special character ('*') if he wanted
     to  be  tunneled. This particular solution does not support compulsory
     tunneling. Another solution involves keying on the domain  portion  of
     the  userID;  all  users  in  domain X would be tunneled to address Y.
     This proposal supports compulsory tunneling, but does not provide  for
     user-based tunneling.
     
     An  Authorize-Only  message  would not include a CHAP or PAP password;
     nevertheless, in response the RADIUS server would return the attribute
     list. In order to prevent password guessing attacks, an Authorize-Only
     message would need to be authenticated via the RADIUS  shared  secret.
     This  could  be  accomplished via the Signature attribute described in
     [10].
     
     
     
     Aboba & Zorn                                                  [Page 9]


     INTERNET-DRAFT                                            26 July 1997
     
     
     Note that when either attribute-specific processing or  an  authorize-
     only  message is used, the tunnel network server would need to renego-
     tiate LCP. Note also that in order for the NAS to start accounting  on
     the  connection, it would need to use the identity claimed by the user
     in authenticating to the tunnel network server, since it did not  ver-
     ify  the  identity via RADIUS. However, in order for that to be of any
     use in accounting, the tunnel endpoint needs to have an account  rela-
     tionship  with  the NAS owner. Thus even if a user has an account with
     the NAS owner, they cannot use this account for tunneling  unless  the
     tunnel  endpoint  also has a business relationship with the NAS owner.
     Without putting in place a public key infrastructure, it is not  clear
     how  the  NAS would be able to verify the existence of such a business
     relationship in a scalable manner. Thus this approach  nullifies  many
     of  the  benefits  of  roaming. Due to these difficulties, it does not
     appear that this scheme can be practically employed.
     
     
     
     6.3.3.  EAP Identity
     
     Where EAP is used as described in [11], the NAS may  include  an  EAP-
     Message/Identity  attribute in the RADIUS Access-Request. Based on the
     Identity included in the Access-Request, the RADIUS  server  may  send
     tunneling  attributes  within  the RADIUS Access-Challenge packet. The
     NAS can then set up the tunnel and  EAP  authentication  may  continue
     between the client and the tunnel server. This method avoids having to
     use attribute-specific processing or an authorize-only message.
     
     However, in this case, the EAP identity is never verified by the  NAS,
     and so either the tunnel server owner must be willing to be billed for
     all incoming calls, or other information such as the  Calling-Station-
     Id must be used to verify the user's identity for accounting purposes.
     Where either of these conditions holds true, this scheme may be  prac-
     tically employed.
     
     
     6.4.  Authenticate at both the NAS and the tunnel network server
     
     In  this  scheme, authentication occurs both at the NAS and the tunnel
     network server. This requires the dial-up  PPP  peer  to  handle  dual
     authentications, with attendant LCP re-negotiations. In order to allow
     the NAS and tunnel network server to  authenticate  against  the  same
     database, this requires RADIUS client capability on the tunnel network
     server, and possibly a RADIUS proxy on the NAS end.
     
     Advantages of this scheme are that it allows secure authentication and
     accounting  at  both  ends  of  the tunnel; allows the use of a single
     userID/password pair via implementation of RADIUS on the  tunnel  net-
     work  server;  and does not require telephone-number based authentica-
     tion, use of EAP, attribute-specific  processing  or  addition  of  an
     Authorize-Only  message  on the RADIUS server.  This scheme allows for
     accounting records to be generated on both the NAS and  tunnel  server
     ends  allowing for auditing. Also, in contrast to the previous scheme,
     the tunnel endpoint does not need to have an account relationship with
     
     
     
     Aboba & Zorn                                                 [Page 10]


     INTERNET-DRAFT                                            26 July 1997
     
     
     the  NAS owner. Thus this scheme is compatible with roaming. Disadvan-
     tages are that unless LCP forwarding is used,  LCP  will  need  to  be
     renegotiated, and that dual authentications are required.
     
     The  use  of dual authentication can be complex, since some clients do
     not support it at all, and others only support only a  subset  of  the
     dual   authentication   combinations.  Feasible  combinations  include
     PAP/PAP(token),   PAP/CHAP,   PAP/EAP,   CHAP/PAP(token),   CHAP/CHAP,
     CHAP/EAP,  EAP/CHAP,  and  EAP/EAP.  Assuming  that  the required dual
     authentication capabilities are supported, this scheme may be  practi-
     cally employed.
     
     
     7.  Telephone-number based authentication
     
     
     
     7.1.  Initiation sequence
     
     In the case of telephone-number based authentication, a typical initi-
     ation sequence looks like this:
     
          Client and NAS: Call Connected
          NAS to RADIUS Server: RADIUS Access-request
          RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
          NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
          Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
          NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
          Client and Tunnel Server: PPP LCP negotiation
          Client and Tunnel Server: PPP authentication
          Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
          RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
          Client and Tunnel Server: NCP negotiation
          NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
          RADIUS Server to NAS: RADIUS Accounting-Response
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request
             with Acct-Status-Type=Start (Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Response
     
     The process begins with an incoming call to the NAS. If configured for
     telephone-number  based  authentication,  the  NAS  MUST send a RADIUS
     Access-Request containing the Calling-Station-Id and  the  Called-Sta-
     tion-Id  attributes. The RADIUS server will then respond with a RADIUS
     Access-Accept or Access-Reject.
     
     The NAS MUST NOT begin PPP authentication before bringing up the  tun-
     nel.  If  timing  permits,  the  NAS  MAY bring up the tunnel prior to
     beginning LCP negotiation with the client. If this is done,  then  LCP
     will not need to be renegotiated between the client and tunnel server.
     
     If the initial telephone-number based authentication is  unsuccessful,
     the  RADIUS server sends a RADIUS Access-Reject. In this case, the NAS
     MUST send an LCP-Terminate and disconnect the user.
     
     
     
     
     Aboba & Zorn                                                 [Page 11]


     INTERNET-DRAFT                                            26 July 1997
     
     
     In the case where tunnel attributes are included in the RADIUS Access-
     Accept, and a PPTP/L2TP tunnel is indicated, the NAS will now bring up
     a control connection if none existed before.  The  control  connection
     will  be  of  the type indicated by Tunnel-Type, over the medium indi-
     cated by Tunnel-Medium-Type, to the tunnel server indicated by Tunnel-
     Server-Endpoint.  This  is  accomplished by sending a PPTP/L2TP Start-
     Control-Connection-Request message to the tunnel server.   The  tunnel
     server  will then with a PPTP/L2TP Start-Control-Connection-Reply.  If
     this message indicates an error, or if the control connection is  ter-
     minated  at  any  future time, then the NAS MUST send an LCP-Terminate
     and disconnect the user.
     
     The NAS will then proceed to send  a  PPTP/L2TP  Incoming-Call-Request
     message  to  the  tunnel server. Among other things, this message will
     contain the Call Serial Number, which along  with  the  NAS-IP-Address
     and  Tunnel-Server-Endpoint is used to uniquely identify the call. The
     tunnel server will reply with a PPTP/L2TP Incoming-Call-Reply message.
     If this message indicates an error, then the NAS MUST send an LCP-Ter-
     minate and disconnect the user. If no error is indicated, the NAS then
     replies with a PPTP/L2TP Incoming-Call-Connected message.
     
     At this point, data MAY begin to flow through the tunnel. If LCP nego-
     tiation had been begun between the NAS and the client, the client  and
     tunnel  server  MAY  now renegotiate LCP and begin PPP authentication;
     otherwise, the client and tunnel server will  negotiate  LCP  for  the
     first time, and then move on to PPP authentication.
     
     If  a  renegotiation  is  required, at the time that the renegotiation
     begins, the NAS SHOULD NOT have sent an  LCP  CONFACK  completing  LCP
     negotiation,  and  the client and NAS MUST NOT have begun NCP negotia-
     tion. Rather than sending an LCP CONFACK, the NAS will instead send an
     LCP  DOWN  message. The Client MAY then renegotiate LCP, and from that
     point forward, all PPP packets originated  from  the  client  will  be
     encapsulated  and  sent to the tunnel server.  When LCP re-negotiation
     has been concluded, the NCP phase will begin, and  the  tunnel  server
     will assign an address to the client.
     
     If L2TP is being used as the tunnel protocol, and LCP renegotiation is
     required, the NAS MAY in its initial setup notification include a copy
     of the LCP CONFACKs sent in each direction which completed LCP negoti-
     ation. The tunnel server MAY then use this  information  to  avoid  an
     additional  LCP negotiation. With L2TP, the initial setup notification
     can also include the authentication information required to allow  the
     tunnel server to authenticate the user and decide to accept or decline
     the connection. However, in telephone-number based authentication, PPP
     authentication MUST NOT occur prior to the NAS bringing up the tunnel.
     As a result, L2TP authentication forwarding MUST NOT be employed.
     
     In performing the PPP authentication, the tunnel server can access its
     own  user database, or it MAY send a RADIUS Access-Request. The latter
     approach  is  useful  in  cases  where  authentication  forwarding  is
     enabled,  such  as  with roaming or shared use networks. In this case,
     the RADIUS and tunnel servers are under the  same  administration  and
     are  typically  located  close  together,  possibly  on  the same LAN.
     
     
     
     Aboba & Zorn                                                 [Page 12]


     INTERNET-DRAFT                                            26 July 1997
     
     
     Therefore having the tunnel server act as a RADIUS client provides for
     unified user administration. Other methods are also available, such as
     use of LDAP, described in [12], by both the tunnel and RADIUS servers.
     Note  that the tunnel server's RADIUS Access-Request is typically sent
     directly to the local RADIUS server rather than  being  forwarded  via
     proxy.
     
     After  the  tunnel  has been brought up, the NAS and tunnel server MAY
     start accounting.  In the case of the NAS, this is done by  sending  a
     RADIUS  Accounting-Request  packet  with  Acct-Status-Type=Start  to a
     RADIUS server. The Accounting-Request packet MUST include the  follow-
     ing  attributes:  Tunnel-Type, Tunnel-Medium-Type, Acct-Tunnel-Client-
     Endpoint, Tunnel-Server-Endpoint, and  Acct-Tunnel-Connection-Id.  The
     Accounting-Request  packet MAY also include the Calling-Station-Id and
     Called-Station-Id attributes.
     
     The tunnel server can produce its own accounting records,  or  it  MAY
     send a RADIUS Accounting-Request packet with Acct-Status-Type=Start to
     a local RADIUS server. In the  latter  case,  the  RADIUS  Accounting-
     Request  packet  MUST  contain  the following attributes: Tunnel-Type,
     Tunnel-Medium-Type,  Acct-Tunnel-Client-Endpoint,   Tunnel-Server-End-
     point, and Acct-Tunnel-Connection-Id.
     
     The  interactions  involved  in initiation of a compulsory tunnel with
     telephone-number based authentication are summarized below.  In  order
     to  simplify  the  diagram  that follows, we have left out the client.
     However, it is understood that the client participates via PPP negoti-
     ation,  authentication and subsequent data interchange with the Tunnel
     Server.
     
     
                                    INITIATION SEQUENCE
     
     NAS                            Tunnel Server       RADIUS Server
     ---                            -------------       -------------
     Call connected
     Send RADIUS
      Access-Request
      with Called-Station-Id,
      and/or Calling-Station-Id
     LCP starts
                                                        IF authentication
                                                        succeeds
                                                         Send ACK with
                                                         Tunnel-Type,
                                                         Tunnel-Medium-Type,
                                                         Tunnel-Server-Endpoint,
                                                        ELSE Send NAK
     IF NAK DISCONNECT
     ELSE
      IF no control
       connection exists
       Send
       Start-Control-Connection-Request
     
     
     
     Aboba & Zorn                                                 [Page 13]


     INTERNET-DRAFT                                            26 July 1997
     
     
       to Tunnel Server
                                  Send
                                  Start-Control-Connection-Reply
                                  to NAS
      ENDIF
     
     Send
     Incoming-Call-Request
     message to Tunnel Server
                                  Send Incoming-Call-Reply
                                  to NAS
     Send
     Incoming-Call-Connected
     message to Tunnel Server
     
     Send data through the tunnel
                                  Re-negotiate LCP,
                                  authenticate user,
                                  bring up IPCP,
                                  start accounting
                                  Send RADIUS
                                  Accounting-Request with
                                  Acct-Status-Type=Start
                                  (optional)
                                                       Send
                                                       RADIUS
                                                       Accounting-Response
     Send a RADIUS
     Accounting-Request message
     with Acct-Status-Type=Start
     containing
     Tunnel-Type, Tunnel-Medium-Type,
     Acct-Tunnel-Client-Endpoint,
     Tunnel-Server-Endpoint,
     Acct-Tunnel-Connection-Id,
     Calling-Station-Id,
     Called-Station-Id.
                                                       Send
                                                       RADIUS
                                                       Accounting-Response
     
     ENDIF
     
     
     7.2.  EAP support
     
     It is expected  that  the  Extensible  Authentication  Protocol  (EAP)
     described in [13] will frequently be used along with telephone number-
     based authentication and tunneling  in  order  to  provide  additional
     security.  In  this case, EAP authentication may be used in the tunnel
     authentication only, using EAP code present on the NAS, or via support
     of  EAP within RADIUS described in [11].  In this case, the initiation
     sequence will look like this:
     
     
     
     
     Aboba & Zorn                                                 [Page 14]


     INTERNET-DRAFT                                            26 July 1997
     
     
          Client and NAS: Call Connected
          Client and NAS: PPP LCP negotiation
          NAS to RADIUS Server: RADIUS Access-Request
          RADIUS server to NAS: RADIUS Access-Reply/Tunnel attributes
          NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
          Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
          NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected
          Client and Tunnel Server: PPP LCP re-negotiation (optional)
          Client and Tunnel Server: EAP authentication
          Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start
          RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message
          Tunnel Server to Client: EAP-Request
          Client to Tunnel Server: EAP-Response
          Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message
          RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success
          Client and Tunnel Server: NCP negotiation
          NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
          RADIUS Server to NAS: RADIUS Accounting-Response
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request with
             Acct-Status-Type=Start (Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Response
     
     
     
     8.  Single authentication
     
     
     
     8.1.  Initiation sequence
     
     In the case of a single authentication compulsory  tunnel,  a  typical
     initiation sequence looks like this:
     
          Client and NAS: Call Connected
          Client and NAS: PPP LCP negotiation
          Client and NAS: EAP authentication
          NAS to RADIUS Server: RADIUS Access-request
          RADIUS server to NAS: RADIUS Access-Challenge/Access-Reject
          NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
          Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
          NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
          Client and Tunnel Server: PPP LCP re-negotiation (optional)
          Client and Tunnel Server: EAP authentication
          Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
          RADIUS server to Tunnel Server: RADIUS Access-Challenge/Access-Reject
          Client and Tunnel Server: NCP negotiation
          NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
          RADIUS Server to NAS: RADIUS Accounting-Response
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request
             with Acct-Status-Type=Start (Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Response
     
     The  process  begins with an incoming call to the NAS, and the PPP LCP
     negotiation between the Client and NAS. At this point,  the  NAS  must
     
     
     
     Aboba & Zorn                                                 [Page 15]


     INTERNET-DRAFT                                            26 July 1997
     
     
     offer  EAP,  and  the Client must accept if the negotiation is to pro-
     ceed. If the Client is incapable of authenticating via EAP,  then  the
     NAS MUST send an LCP-Terminate and disconnect the user.
     
     The  NAS will now typically send an EAP-Request/Identity packet to the
     Client, and the client will respond with an EAP-Response/MyId  packet.
     The  NAS  now  sends  an  Access-Request/EAP-Message/EAP-Response/MyId
     packet to the RADIUS server, which responds with  an  Access-Challenge
     or an Access-Reject.
     
     If  single-authentication  tunneling is to be carried out, the Access-
     Challenge packet MUST contain the Tunnel-Type, Tunnel-Medium-Type, and
     Tunnel-Server-Endpoint   Attributes.   The   presence   of   tunneling
     attributes in the Access-Challenge indicates to the NAS that a  tunnel
     MUST be brought up prior to continuation of the EAP conversation. As a
     result, if the Access-Challenge  contains  an  EAP-Message  attribute,
     then  the  NAS  MUST NOT send the EAP-Request encapsulated in the EAP-
     Message prior to bringing up the tunnel. Since  after  the  tunnel  is
     brought up LCP will be renegotiated, EAP-Message attributes are effec-
     tively ignored whenever  the  Access-Challenge  also  contains  tunnel
     attributes.
     
     In  the  case  where a PPTP/L2TP tunnel is indicated, the NAS will now
     bring up a control connection if none existed before, and the NAS  and
     tunnel server will bring up the call. At this point, data MAY begin to
     flow through the tunnel. The client and tunnel server MAY now  renego-
     tiate LCP and will complete PPP authentication.
     
     At  the  time  that  the renegotiation begins, the NAS SHOULD NOT have
     sent an LCP CONFACK completing LCP negotiation, and the client and NAS
     MUST  NOT  have begun NCP negotiation. Rather than sending an LCP CON-
     FACK, the NAS will instead send an LCP DOWN message.  The  Client  MAY
     then  renegotiate  LCP,  and  from that point forward, all PPP packets
     originated from the client will be encapsulated and sent to the tunnel
     server.  In single authentication compulsory tunneling, L2TP authenti-
     cation forwarding MUST NOT be employed.
     
     If the tunnel server and NAS both are using the  same  RADIUS  server,
     the  RADIUS  server will respond to the tunnel server's Access-Request
     with an Access-Challenge packet containing tunnel  attributes  and  an
     EAP-Message  attribute,  as  before. On receiving the Access-Challenge
     including tunnel attributes, the tunnel server will check whether  the
     tunnel  matches  the  attributes returned by the RADIUS server; if so,
     the tunnel attributes will be ignored, and the  EAP-Request  specified
     in the EAP-Message attribute will be sent to the Client. If the tunnel
     attributes do not match, then the tunnel server  MUST  disconnect  the
     call.
     
     When  LCP re-negotiation has been concluded, the NCP phase will begin,
     and the tunnel server will assign an address to the client.
     
     In performing the PPP authentication, the tunnel server can access its
     own  user  database, or it MAY send a RADIUS Access-Request. After the
     tunnel has been brought up,  the  NAS  and  tunnel  server  MAY  start
     
     
     
     Aboba & Zorn                                                 [Page 16]


     INTERNET-DRAFT                                            26 July 1997
     
     
     accounting.
     
     The  interactions  involved  in initiation of a compulsory tunnel with
     single authentication are summarized below.
     
     
     
                                    INITIATION SEQUENCE
     
     NAS                            Tunnel Server       RADIUS Server
     ---                            -------------       -------------
     Call accepted
     LCP starts
     EAP authentication
      phase starts
     Send RADIUS
      Access-Request
      with EAP-Message/MyId
      attribute
                                                       IF MyId is known,
                                                       send RADIUS
                                                       Access-Challenge with
                                                         Tunnel-Type,
                                                         Tunnel-Medium-Type,
                                                         Tunnel-Server-Endpoint,
                                                         EAP-Message (optional)
                                                       ELSE Send NAK
     IF NAK DISCONNECT
     ELSE
      IF no control
       connection exists
       Send
       Start-Control-Connection-Request
       to Tunnel Server
                                  Send
                                  Start-Control-Connection-Reply
                                  to NAS
      ENDIF
     
     Send
     Incoming-Call-Request
     message to Tunnel Server
                                  Send Incoming-Call-Reply
                                  to NAS
     Send
     Incoming-Call-Connected
     message to Tunnel Server
     
     Send data through the tunnel
                                  Re-negotiate LCP,
                                  authenticate user via EAP,
                                  bring up IPCP,
                                  start accounting
                                  Send RADIUS
     
     
     
     Aboba & Zorn                                                 [Page 17]


     INTERNET-DRAFT                                            26 July 1997
     
     
                                  Accounting-Request with
                                  Acct-Status-Type=Start
                                  (optional)
                                                       Send
                                                       RADIUS
                                                       Accounting-Response
     Send a RADIUS
     Accounting-Request message
     with Acct-Status-Type=Start
     containing
     Tunnel-Type, Tunnel-Medium-Type,
     Acct-Tunnel-Client-Endpoint,
     Tunnel-Server-Endpoint, and
     Acct-Tunnel-Connection-Id.
                                                       Send
                                                       RADIUS
                                                       Accounting-Response
     
     ENDIF
     
     
     
     9.  Dual authentication
     
     
     
     9.1.  Initiation sequence
     
     In the case of a dual authentication, a  typical  initiation  sequence
     looks like this:
     
          Client and NAS: PPP LCP negotiation
          Client and NAS: PPP authentication
          NAS to RADIUS Server: RADIUS Access-request
          RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
          NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
          Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
          NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
          Client and Tunnel Server: PPP LCP re-negotiation (optional)
          Client and Tunnel Server: PPP authentication
          Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
          RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
          Client and Tunnel Server: NCP negotiation
          NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
          RADIUS Server to NAS: RADIUS Accounting-Response
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request
             with Acct-Status-Type=Start (Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Response
     
     The  process  begins  with an incoming call to the NAS. The client and
     NAS then begin LCP negotiation. Subsequently  the  PPP  authentication
     phase starts, and the NAS sends a RADIUS Access-Request message to the
     RADIUS server. If the authentication is successful, the RADIUS  server
     responds  with  a  RADIUS Access-Accept. For users requiring mandatory
     
     
     
     Aboba & Zorn                                                 [Page 18]


     INTERNET-DRAFT                                            26 July 1997
     
     
     tunneling, the Access-Accept MUST contain the the Tunnel-Type, Tunnel-
     Medium-Type, and Tunnel-Server-Endpoint Attributes.
     
     In  the  case  where a PPTP/L2TP tunnel is indicated, the NAS will now
     bring up a control connection if none existed before, and the NAS  and
     tunnel server will bring up the call. At this point, data MAY begin to
     flow through the tunnel. The client and tunnel server MAY now  renego-
     tiate  LCP  and go through another round of PPP authentication. At the
     time that this renegotiation begins, the NAS SHOULD NOT have  sent  an
     LCP  CONFACK  completing  LCP negotiation, and the client and NAS MUST
     NOT have begun NCP negotiation. Rather than sending  an  LCP  CONFACK,
     the  NAS  will  instead  send an LCP DOWN message. The Client MAY then
     renegotiate LCP, and from that point forward, all PPP  packets  origi-
     nated  from  the  client  will  be encapsulated and sent to the tunnel
     server.  When LCP re-negotiation has been  concluded,  the  NCP  phase
     will  begin,  and  the  tunnel  server  will  assign an address to the
     client.
     
     If L2TP is being used as the tunnel protocol, the NAS MAY in its  ini-
     tial  setup  notification  include  a copy of the LCP CONFACKs sent in
     each direction which completed LCP negotiation. The tunnel server  MAY
     then use this information to avoid an additional LCP negotiation. With
     L2TP, the initial setup notification can also include the  authentica-
     tion  information  required to allow the tunnel server to authenticate
     the user and decide to accept or decline the connection. However, this
     facility  creates  a  vulnerability  to replay attacks, and can create
     problems in the case where the  NAS  and  tunnel  server  authenticate
     against  different  RADIUS servers. As a result, where user-based tun-
     neling via  RADIUS  is  implemented,  L2TP  authentication  forwarding
     SHOULD NOT be employed.
     
     In performing the PPP authentication, the tunnel server can access its
     own user database, or it MAY send a RADIUS Access-Request.  After  the
     tunnel  has  been  brought  up,  the  NAS  and tunnel server MAY start
     accounting.
     
     The interactions involved in initiation of a  compulsory  tunnel  with
     dual authentication are summarized below.
     
     
                                    INITIATION SEQUENCE
     
     NAS                            Tunnel Server       RADIUS Server
     ---                            -------------       -------------
     Call accepted
     LCP starts
     PPP authentication
      phase starts
     Send RADIUS
      Access-Request
      with username and
      authentication data
                                                        IF authentication
                                                        succeeds
     
     
     
     Aboba & Zorn                                                 [Page 19]


     INTERNET-DRAFT                                            26 July 1997
     
     
                                                         Send ACK with
                                                         Tunnel-Type,
                                                         Tunnel-Medium-Type,
                                                         Tunnel-Server-Endpoint,
                                                        ELSE Send NAK
     IF NAK DISCONNECT
     ELSE
      IF no control
       connection exists
       Send
       Start-Control-Connection-Request
       to Tunnel Server
                                  Send
                                  Start-Control-Connection-Reply
                                  to NAS
      ENDIF
     
     Send
     Incoming-Call-Request
     message to Tunnel Server
                                  Send Incoming-Call-Reply
                                  to NAS
     Send
     Incoming-Call-Connected
     message to Tunnel Server
     
     Send data through the tunnel
                                  Re-negotiate LCP,
                                  authenticate user,
                                  bring up IPCP,
                                  start accounting
                                  Send RADIUS
                                  Accounting-Request with
                                  Acct-Status-Type=Start
                                  (optional)
                                                       Send
                                                       RADIUS
                                                       Accounting-Response
     Send a RADIUS
     Accounting-Request message
     with Acct-Status-Type=Start
     containing
     Tunnel-Type, Tunnel-Medium-Type,
     Acct-Tunnel-Client-Endpoint,
     Tunnel-Server-Endpoint, and
     Acct-Tunnel-Connection-Id.
                                                       Send
                                                       RADIUS
                                                       Accounting-Response
     
     ENDIF
     
     
     
     
     
     
     Aboba & Zorn                                                 [Page 20]


     INTERNET-DRAFT                                            26 July 1997
     
     
     9.2.  EAP support
     
     It  is  expected  that  the  Extensible  Authentication Protocol (EAP)
     described in [13] will frequently be  used  along  with  tunneling  in
     order  to  provide additional security. EAP authentication may be used
     in the initial NAS authentication, in the  tunnel  authentication,  or
     both,  with  support  of  EAP within RADIUS described in [11].  In the
     case where EAP authentication is  carried  out  between  the  NAS  and
     client, the initiation sequence will look like this:
     
          Client and NAS: PPP LCP negotiation
          Client and NAS: EAP Authentication
          NAS to RADIUS Server: RADIUS Access-Request/EAP-start
          RADIUS server to NAS: RADIUS Access-Challenge/EAP-Message
          NAS to Client: EAP-Request
          Client to NAS: EAP-Response
          NAS to RADIUS Server: RADIUS Access-Request/EAP-Message
          RADIUS server to NAS: RADIUS Access-Accept/EAP-Message/EAP-Success
          NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
          Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
          NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Connected
          Client and Tunnel Server: PPP LCP re-negotiation (optional)
          Client and Tunnel Server: PPP authentication
          Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
          RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
          Client and Tunnel Server: NCP negotiation
          NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
          RADIUS Server to NAS: RADIUS Accounting-Response
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request
             With Acct-Status-Type=Start(Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Response
     
     In the case where EAP authentication is carried out between the client
     and tunnel server, the initiation sequence will look like this:
     
          Client and NAS: PPP LCP negotiation
          Client and NAS: PPP authentication
          NAS to RADIUS Server: RADIUS Access-request
          RADIUS server to NAS: RADIUS Access-Accept
          NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
          Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
          NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
          Client and Tunnel Server: PPP LCP re-negotiation (optional)
          Client and Tunnel Server: EAP authentication
          Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start
          RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message
          Tunnel Server to Client: EAP-Request
          Client to Tunnel Server: EAP-Response
          Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message
          RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success
          Client and Tunnel Server: NCP negotiation
          NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
          RADIUS Server to NAS: RADIUS Accounting-Response
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request with
     
     
     
     Aboba & Zorn                                                 [Page 21]


     INTERNET-DRAFT                                            26 July 1997
     
     
             Acct-Status-Type=Start (Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Response
     
     For the negotiations described above to succeed, the  client  must  be
     capable  of  renegotiating EAP with the tunnel server after an initial
     authentication with the NAS.
     
     
     10.  Termination sequence
     
     The tear down of a compulsory tunnel involves an  interaction  between
     the  client,  NAS,  Tunnel  Server, and RADIUS Accounting server. This
     interaction is virtually identical regardless  of  whether  telephone-
     number  based authentication, single authentication, or dual authenti-
     cation is being used. In any of the cases, the following events occur:
     
          Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional)
          NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify
          NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Stop
          RADIUS Server to NAS: RADIUS Accounting-Response
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request
             with Acct-Status-Type=Stop(Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Response
     
     Tunnel  termination  can  occur  due to a client request (PPP termina-
     tion), a tunnel server request (Call-Clear-Request), or a line problem
     (call disconnect).
     
     In  the case of a client-requested termination, the tunnel server MUST
     terminate the PPP session. The tunnel server MUST subsequently send  a
     Call-Clear-Request  to  the NAS. The NAS MUST then send a Call-Discon-
     nect-Notify message to the tunnel  server,  and  will  disconnect  the
     call.
     
     The  NAS  MUST  also respond with a Call-Disconnect-Notify message and
     disconnection if it receives  a  Call-Clear-Request  from  the  tunnel
     server without a client-requested termination.
     
     In  the  case  of  a  line problem or user hangup, the NAS MUST send a
     Call-Disconnect-Notify to the tunnel server. Both sides will then tear
     down the  call.
     
     After  call  tear down is complete, if RADIUS accounting is being used
     then the NAS MUST send a RADIUS Accounting-Request  with  Acct-Status-
     Type=Stop  packet  to  a  RADIUS  accounting  server.  The Accounting-
     Request packet MUST include  the  following  attributes:  Tunnel-Type,
     Tunnel-Medium-Type,   Acct-Tunnel-Client-Endpoint,  Tunnel-Server-End-
     point, and Acct-Tunnel-Connection-Id.
     
     The tunnel server MAY produce its own accounting records,  or  it  MAY
     use  RADIUS  accounting.  If  RADIUS accounting is being used then the
     tunnel server MUST send a RADIUS Accounting-Request with  Acct-Status-
     Type=Stop to a RADIUS accounting server. The Accounting-Request packet
     MUST contain the  following  attributes:  Tunnel-Type,  Tunnel-Medium-
     
     
     
     Aboba & Zorn                                                 [Page 22]


     INTERNET-DRAFT                                            26 July 1997
     
     
     Type,  Acct-Tunnel-Client-Endpoint,  Tunnel-Server-Endpoint, and Acct-
     Tunnel-Connection-Id.
     
     The interactions involved in termination of a  compulsory  tunnel  are
     summarized  below.  In  order to simplify the diagram that follows, we
     have left out the client. However, it is understood  that  the  client
     MAY participate via PPP termination and disconnection.
     
                                    TERMINATION SEQUENCE
     
     NAS                            Tunnel Server         RADIUS Server
     ---                            -------------         -------------
     IF user disconnected
      send
      Call-Disconnect-Notify
      message to tunnel server
                                    Tear down the call
                                    stop accounting
                                    Send RADIUS
                                    Accounting-Request with
                                    Acct-Status-Type=Stop
                                    (optional)
                                                         Send RADIUS
                                                         Accounting-Response
     ELSE IF client requests
      termination
                                    send
                                    Call-Clear-Request
                                    to the NAS
      Send
      Call-Disconnect-Notify
      message to tunnel server
      Disconnect the user
                                    Tear down the call
                                    stop accounting
                                    Send RADIUS
                                    Accounting-Request with
                                    Acct-Status-Type=Stop
                                    (optional)
                                                         Send RADIUS
                                                         Accounting-Response
     
      Send a RADIUS
      Accounting-Request message
      with Acct-Status-Type=Stop
      containing
      Tunnel-Type, Tunnel-Medium-Type,
      Acct-Tunnel-Client-Endpoint,
      Tunnel-Server-Endpoint, and
      Acct-Tunnel-Connection-Id.
                                                         Send RADIUS
                                                         Accounting-Response
     
     ENDIF
     
     
     
     Aboba & Zorn                                                 [Page 23]


     INTERNET-DRAFT                                            26 July 1997
     
     
     11.  Use of distinct RADIUS servers
     
     In  the  case  that  the  NAS and the tunnel server are using distinct
     RADIUS servers, some interesting cases can arise in  the  provisioning
     of compulsory tunnels.
     
     
     11.1.  Distinct userIDs
     
     If  distinct RADIUS servers are being used, it is likely that distinct
     userID/password pairs will be required to complete the RADIUS and tun-
     nel  authentications. One pair will be used in the initial PPP authen-
     tication with the NAS, and the second pair will be used for the tunnel
     authentication.
     
     However, in order to provide maximum ease of use in the case where the
     userID/password pairs are identical, tunnel clients typically  attempt
     authentication  with  the same userID/password pair as was used in the
     initial PPP negotiation. Only after this fails do they prompt the user
     for the second pair.
     
     In  this  case,  tunnel client implementations SHOULD take care not to
     put up error messages indicating a  bad  password.  Instead  a  dialog
     SHOULD be presented requesting the tunnel userID/password combination.
     
     In the case where smart cards are being used for both authentications,
     the  tunnel  client  MUST NOT attempt to present the token used in the
     first authentication during the  second  authentication,  since  these
     will  never be identical. Instead the user SHOULD be prompted to enter
     the second token.
     
     The same issue arises in L2TP if the NAS attempts to forward authenti-
     cation information to the tunnel server in the initial setup notifica-
     tion. Since the userID/password pair used for tunnel authentication is
     different  from  that used to authenticate against the NAS, forwarding
     authentication information  in  this  manner  will  cause  the  tunnel
     authentication  to  fail.  As a result, where user-based tunneling via
     RADIUS is implemented, L2TP authentication forwarding  SHOULD  NOT  be
     employed.
     
     
     11.2.  Multilink PPP issues
     
     It  is  possible  for the two RADIUS servers to return different Port-
     Limit attributes. For example, it is conceivable that the  NAS  RADIUS
     server  will  only  grant  use  of  a single channel, while the tunnel
     RADIUS server will grant more than one channel. In this case, the cor-
     rect behavior is for the tunnel client to open a connection to another
     NAS in order to bring up a multilink bundle on the tunnel server.  The
     client MUST NOT indicate to the NAS that this additional link is being
     brought up as part of a multilink bundle; this will only be  indicated
     in the subsequent negotiation with the tunnel server.
     
     
     
     
     
     Aboba & Zorn                                                 [Page 24]


     INTERNET-DRAFT                                            26 July 1997
     
     
     It  is  also  conceivable  that  the  NAS RADIUS server will allow the
     client to bring up multiple  channels,  but  that  the  tunnel  RADIUS
     server  will  allow fewer channels than the NAS RADIUS server. In this
     case, the client should terminate use of the excess channels.
     
     
     12.  UserID Issues
     
     In the provisioning of roaming and shared use  networks,  one  of  the
     requirements  is to be able to route the authentication request to the
     user's home RADIUS server. This authentication routing is accomplished
     based  on  the  userID submitted by the user to the NAS in the initial
     PPP authentication. The userID is subsequently relayed by the  NAS  to
     the  RADIUS  server  in the User-Name attribute, as part of the RADIUS
     Access-Request.
     
     Similarly, references [5] and [6] refer to use of the userID in deter-
     mining  the  tunnel  endpoint. However, since none of these references
     provide guidelines for how RADIUS or tunnel routing is  to  be  accom-
     plished, the possibility of conflicting interpretations exists.
     
     
     12.1.  UserID convergence in user-based tunneling
     
     The use of RADIUS in provisioning of compulsory tunneling relieves the
     userID from having to do double duty. Rather than being used both  for
     routing of the RADIUS authentication/authorization request as well for
     determination of the tunnel endpoint, the userID is  now  used  solely
     for  routing of RADIUS authentication/authorization requests. The Tun-
     nel-Server-Endpoint attribute returned in the  RADIUS  Access-Response
     Is then used to determine the tunnel endpoint.
     
     Since  the  framework  described in this document allows both ISPs and
     tunnel users to authenticate users as well as to account for resources
     consumed  by  them,  and  provides  for  maintenance  of  two distinct
     userID/password pairs, this scheme provides a high degree of flexibil-
     ity.   Where RADIUS proxies and tunneling are employed, it is possible
     to allow the user to authenticate with a single  userID/password  pair
     at both the NAS and the tunnel endpoint. This is accomplished by rout-
     ing the NAS RADIUS Access-Request to the same RADIUS  server  used  by
     the tunnel server.
     
     As  described  in  [8],  the  recommended  form  for  the  user  ID is
     userID@realm, i.e. fred@bigco.com.
     
     
     13.  Acknowledgements
     
     Thanks to Gurdeep Singh Pall of Microsoft for many useful  discussions
     of  this  problem  space,  and  to Allan Rubens of Ascend and Bertrand
     Buclin of AT&T Labs Europe for his comments on this document.
     
     
     
     
     
     
     Aboba & Zorn                                                 [Page 25]


     INTERNET-DRAFT                                            26 July 1997
     
     
     14.  References
     
     [1]  B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of  Roaming
     Implementations."  Work in progress, draft-ietf-roamops-imprev-04.txt,
     Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, June, 1997.
     
     [2]  B. Aboba, G. Zorn.  "Dialup Roaming Requirements." Internet draft
     (work   in  progress),  draft-ietf-roamops-roamreq-05.txt,  Microsoft,
     July, 1997.
     
     [3]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
     cation  Dial  In  User Service (RADIUS)." RFC 2138, Livingston, Merit,
     Daydreamer, April, 1997.
     
     [4]  C. Rigney.  "RADIUS Accounting."  RFC  2139,  Livingston,  April,
     1997.
     
     [5]  K.  Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J.
     Valencia, W. Verthein.  "Layer Two Tunneling  Protocol  --  L2TP."  ."
     Internet  draft  (work  in  progress),  draft-ietf-pppext-l2tp-04.txt,
     Ascend  Communications,  Microsoft,  Copper  Mountain  Networks,  U.S.
     Robotics, June, 1997.
     
     [6]  K.  Hamzeh,  G.  S.  Pall,  J. Taarud, W. Verthein, W. A. Little.
     "Point-to-Point Tunneling Protocol -- PPTP." ." Internet  draft  (work
     in  progress),  draft-ietf-pppext-pptp-02.txt,  Ascend Communications,
     Microsoft, Copper Mountain Networks, U.S. Robotics, July, 1997.
     
     [7] G. Zorn.  "RADIUS Attributes for Tunnel Protocol Support."  Inter-
     net  draft  (work  in progress), draft-ietf-radius-tunnel-auth-02.txt,
     Microsoft, July, 1997.
     
     [8] B. Aboba, M. A. Beadles.  "The Network Access Identifier."  Inter-
     net   draft   (work   in   progress),   draft-ietf-roamops-nai-06.txt,
     Microsoft, CompuServe, July, 1997.
     
     [9] S. Bradner.  "Key words for use in RFCs  to  Indicate  Requirement
     Levels." RFC 2119, Harvard University, March, 1997.
     
     [10]  C.  Rigney, W. Willats.  "RADIUS Extensions."  Work in progress,
     draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
     
     [11] P. Calhoun, A.C. Rubens, B.  Aboba.   "Extensible  Authentication
     Protocol Support in RADIUS." Internet draft (work in progress), draft-
     ietf-radius-eap-02.txt,  US  Robotics  Access  Corp.,  Merit  Network,
     Microsoft, May, 1997.
     
     [12]  M. Wahl, T. Howes, S. Kille.  "Lightweight Directory Access Pro-
     tocol (v3)." ." Internet draft (work  in  progress),  draft-ietf-asid-
     ldapv3-protocol-04.txt,  Critical Angle Inc., Netscape, Isode Limited,
     March, 1997.
     
     [13] L. J. Blunk, J. R. Vollbrecht.   "PPP  Extensible  Authentication
     Protocol  (EAP)."  ."  Internet  draft (work in progress), draft-ietf-
     
     
     
     Aboba & Zorn                                                 [Page 26]


     INTERNET-DRAFT                                            26 July 1997
     
     
     pppext-eap-auth-02.txt, Merit Network, Inc., June, 1996.
     
     
     
     
     
     15.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 425-936-6605
     EMail: bernarda@microsoft.com
     
     Glen Zorn
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 425-703-1559
     EMail: glennz@microsoft.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Zorn                                                 [Page 27]