[Search] [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-02.txt>                        Microsoft
     11 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-02.txt> and  expires January 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 compulsory tunneling, a tunnel  is  created  without  any
               action  from  the  user  and  without  allowing the user any
               choice.
     
     Compulsory Tunneling
               In compulsory tunneling, a tunnel  is  created  without  any
               action  from  the  user  and  without  allowing the user any
     
     
     
     Aboba & Zorn                                                  [Page 1]


     INTERNET-DRAFT                                            11 July 1997
     
     
               choice.
     
     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
     
     
     
     Aboba & Zorn                                                  [Page 2]


     INTERNET-DRAFT                                            11 July 1997
     
     
               the RADIUS proxy will locate the RADIUS server  that  is  to
               receive the request. This same structure MAY also be used to
               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.
     
     
     
     Aboba & Zorn                                                  [Page 3]


     INTERNET-DRAFT                                            11 July 1997
     
     
     An implementation that satisfies all the MUST, MUST  NOT,  SHOULD  and
     SHOULD  NOT requirements for its protocols is said to be "uncondition-
     ally compliant"; one that satisfies all the MUST and MUST NOT require-
     ments but not all the SHOULD or SHOULD NOT requirements for its proto-
     cols 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 six new  RADIUS
     attributes:  Tunnel-Type,  Tunnel-Medium-Type, Acct-Tunnel-Client-End-
     point, Tunnel-Server-Endpoint, Acct-Tunnel-Connection-Id, and  Tunnel-
     Password.
     
     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-
     
     
     
     Aboba & Zorn                                                  [Page 4]


     INTERNET-DRAFT                                            11 July 1997
     
     
     Challenge  packets.
     
     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.
     
     The Tunnel-Password attribute may contain a key or  password, which is
     to  be  used  with  protocols such as L2TP which support authenticated
     tunnels.  It may  only  be included in  an  Access-Accept  or  Access-
     Challenge packet.
     
     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
     
     
     
     
     
     Aboba & Zorn                                                  [Page 5]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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 signifi-
     cant 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
     
     
     
     Aboba & Zorn                                                  [Page 6]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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
     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, Tunnel-Server-Endpoint and Tun-
     nel-Password attributes based on the Calling-Station-Id or Called-Sta-
     tion-Id.   Similarly,  in  PPTP/L2TP  the  tunnel server MAY choose to
     reject or accept the call based on the Dialed Number and Dialing  Num-
     ber 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
     
     
     
     Aboba & Zorn                                                  [Page 7]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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.
     
     
     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
     
     
     
     Aboba & Zorn                                                  [Page 8]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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.
     
     
     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
     
     
     
     Aboba & Zorn                                                  [Page 9]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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].
     
     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
     
     
     
     Aboba & Zorn                                                 [Page 10]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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
     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-
     
     
     
     Aboba & Zorn                                                 [Page 11]


     INTERNET-DRAFT                                            11 July 1997
     
     
     Station-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.
     
     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
     
     
     
     Aboba & Zorn                                                 [Page 12]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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.
     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
     
     
     
     Aboba & Zorn                                                 [Page 13]


     INTERNET-DRAFT                                            11 July 1997
     
     
                                                        succeeds
                                                         Send ACK with
                                                         Tunnel-Type,
                                                         Tunnel-Medium-Type,
                                                         Tunnel-Server-Endpoint,
                                                         Tunnel-Password (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,
                                  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
     
     
     
     
     Aboba & Zorn                                                 [Page 14]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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:
     
          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
     
     
     
     Aboba & Zorn                                                 [Page 15]


     INTERNET-DRAFT                                            11 July 1997
     
     
          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
     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;  a  Tunnel-Password  attribute  is
     optional. The presence of tunneling attributes in the Access-Challenge
     indicates to the NAS that a tunnel MUST be brought up prior to contin-
     uation 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  tun-
     nel.  Since  after  the tunnel is brought up LCP will be renegotiated,
     EAP-Message attributes are effectively 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
     
     
     
     Aboba & Zorn                                                 [Page 16]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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
     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,
                                                         Tunnel-Password (optional)
                                                         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
     
     
     
     Aboba & Zorn                                                 [Page 17]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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
                                  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
     
     
     
     Aboba & Zorn                                                 [Page 18]


     INTERNET-DRAFT                                            11 July 1997
     
     
          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
     tunneling, the Access-Accept MUST contain the the Tunnel-Type, Tunnel-
     Medium-Type,  and Tunnel-Server-Endpoint Attributes; a Tunnel-Password
     attribute is optional.
     
     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.
     
     
     
     
     Aboba & Zorn                                                 [Page 19]


     INTERNET-DRAFT                                            11 July 1997
     
     
                                    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
                                                         Send ACK with
                                                         Tunnel-Type,
                                                         Tunnel-Medium-Type,
                                                         Tunnel-Server-Endpoint,
                                                         Tunnel-Password (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,
                                  bring up IPCP,
                                  start accounting
                                  Send RADIUS
                                  Accounting-Request with
                                  Acct-Status-Type=Start
                                  (optional)
                                                       Send
                                                       RADIUS
                                                       Accounting-Response
     Send a RADIUS
     
     
     
     Aboba & Zorn                                                 [Page 20]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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.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
     
     
     
     Aboba & Zorn                                                 [Page 21]


     INTERNET-DRAFT                                            11 July 1997
     
     
          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
     
     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
     
     
     
     Aboba & Zorn                                                 [Page 22]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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-
     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
     
     
     
     Aboba & Zorn                                                 [Page 23]


     INTERNET-DRAFT                                            11 July 1997
     
     
                                                         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
     
     
     
     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
     
     
     
     Aboba & Zorn                                                 [Page 24]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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.
     
     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
     
     
     
     Aboba & Zorn                                                 [Page 25]


     INTERNET-DRAFT                                            11 July 1997
     
     
     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.
     
     
     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  2058,  Livingston,  Merit,
     Daydreamer, January, 1997.
     
     [4]   C.  Rigney.  "RADIUS Accounting." RFC 2059, Livingston, January,
     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-01.txt,  Ascend  Communications,
     Microsoft, Copper Mountain Networks, U.S. Robotics, December, 1996.
     
     [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.
     
     
     
     
     Aboba & Zorn                                                 [Page 26]


     INTERNET-DRAFT                                            11 July 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-
     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]