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

Versions: 00 01 02 03 04 05 07 rfc2809                                  
     RADIUS Working Group                                     Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-ietf-radius-tunnel-imp-00.txt>                        Glen Zorn
     28 February 1997                                 Microsoft Corporation
     
     
                Implementation of Mandatory 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-00.txt> and  expires September 1, 1997.  Please
     send comments to the authors.
     
     
     2.  Abstract
     
     This  document  discusses  implementation issues arising in the provi-
     sioning of mandatory tunneling in dial-up networks using the PPTP  and
     L2TP  protocols.   This provisioning may be accomplished via the inte-
     gration of RADIUS and tunneling protocols.
     
     
     3.  Terminology
     
     
     Roaming   "Roaming capability" may 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 roam-
               ing capability might be  required  include  ISP  "confedera-
               tions" 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
     
     
     
     Aboba & Zorn                                                  [Page 1]


     INTERNET-DRAFT                                        28 February 1997
     
     
               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 may 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
               dial in order to get access to the network. In  PPTP  termi-
               nology  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 may 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
               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
     
     
     
     Aboba & Zorn                                                  [Page 2]


     INTERNET-DRAFT                                        28 February 1997
     
     
               specification.
     
     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 "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  of the most  interesting  applications  of  tunneling  protocols
     involve  dial-up  network  access.  Some, such  as the provisioning of
     secure access to corporate intranets via the Internet, are  character-
     ized  by  voluntary tunneling: the tunnel is created at the request of
     the user for a specific purpose. Other applications involve compulsory
     
     
     
     Aboba & Zorn                                                  [Page 3]


     INTERNET-DRAFT                                        28 February 1997
     
     
     tunneling:  the  tunnel  is  created automatically, without any action
     from the user and more importantly,  without  allowing  the  user  any
     choice in the  matter.
     
     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
     mandatory 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 mandatory tunneling,
     however, these types of services could be accessed via  virtually  any
     Internet  service provider (ISP).  The most popular means of authoriz-
     ing dial-up network users today is through the RADIUS   protocol.  The
     use  of RADIUS allows the dial-up users' authorization and authentica-
     tion data to be maintained in a central location,  rather  than  being
     subject to manual configuration.  It makes sense to use RADIUS to cen-
     trally  administer  compulsory  tunneling,  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 server; those attributes are defined in [7].
     
     This document focuses on implementation issues arising in  the  provi-
     sioning  of  mandatory tunneling in dialup networks. The use of RADIUS
     in provisioning of mandatory tunneling has several  advantages.  These
     include:
     
     User-based tunneling
     Auditing capabilities
     Telephone-number based authentication and accounting
     
     
     5.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
     wish to provide Janet with an account that allows access to  both  the
     
     
     
     Aboba & Zorn                                                  [Page 4]


     INTERNET-DRAFT                                        28 February 1997
     
     
     Internet  and the intranet, with Janet's intranet access provided by a
     tunnel server located in the engineering department. However BIGCO may
     wish  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.
     
     As  described  in [7], provisioning of mandatory tunneling requires no
     new  RADIUS  messages,  and  implementation  of   three   new   RADIUS
     attributes. During authentication, the new attributes allow the RADIUS
     server to indicate the tunnel protocol (PPTP, L2F,  L2TP,  etc.),  the
     tunnel  medium  (X.25,  ATM,  Frame  Relay, IP) and the address of the
     remote tunnel endpoint. During accounting, the  new  attributes  allow
     the  NAS  to  provide the RADIUS server with these same attributes, as
     well as the tunnel client address and Connection Identifier.  Together
     the  Connection  Identifier  and  tunnel client and endpoint addresses
     uniquely identify the call, linking together the NAS and tunnel server
     accounting records for a given call.
     
     
     5.2.  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. This capabil-
     ity  is  particularly  important  when the user is taking advantage of
     roaming capabilities in order to connect  to  the  corporate  intranet
     from a remote location.
     
     As described in [7], auditing requires implementation of number of new
     RADIUS attributes. These new attributes allow  the  RADIUS  server  to
     provide  information  within  the  Accounting-Request packet that will
     allow matching with the corresponding tunnel server Accounting-Request
     packet.  This information includes the Connection-Identifier, the tun-
     nel protocol (PPTP, L2F, or  L2TP),  tunnel-media  (X.25,  ATM,  Frame
     Relay,  IP)  the address of the remote tunnel endpoint, and the tunnel
     client address.
     
     
     5.2.1.  Connection-Identifier
     
     In L2TP the Call-Serial-Number is used as the RADIUS Connection  Iden-
     tifier, and the tuple (userID, tunnel-client-endpoint address, tunnel-
     server-endpoint address, Call-Serial-Number) is used to uniquely iden-
     tify  the call. In order to protect against wrapping due to reboots or
     call volume, it is recommended that a 64-bit NTP timestamp be used  as
     
     
     
     Aboba & Zorn                                                  [Page 5]


     INTERNET-DRAFT                                        28 February 1997
     
     
     the Call-Serial Number.
     
     While the PPTP specification states that the Call-Serial-Number SHOULD
     be unique, it does not mandate this. In addition, no method for deter-
     mining the Call-Serial-Number is specified, which leaves open the pos-
     sibility of wrapping after a reboot. Finally  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 average call is of 20
     minutes duration,  then  the  Call  Serial  Number  will  wrap  within
     65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 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  a
     unique  Connection  Identifier.  It  is  recommended that a 64-bit NTP
     timestamp be used for this purpose. This is not an issue in L2TP since
     the Call-Serial-Number string may be of variable length.
     
     
     5.3.  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, or tunnel endpoint  address  based  on
     the  calling  or called phone number. Similarly, the tunnel server may
     choose to reject or accept the call based on  the  Dialed  Number  and
     Dialing  Number  included  in the 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/or Called-Station-ID.
     
     
     6.  Alternatives for implementation of mandatory tunneling
     
     There are several alternatives for integration of RADIUS  and  tunnel-
     ing:
     
          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.
     
     
     
     
     
     
     
     Aboba & Zorn                                                  [Page 6]


     INTERNET-DRAFT                                        28 February 1997
     
     
     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.
     
     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's the only way that the tunnel network server  could  check
     the  RADIUS  reply. Also, the tunnel network server must share secrets
     with all the NASes and associated RADIUS servers. Other  disadvantages
     include  lack of provision for LCP renegotiation by the tunnel network
     server; and the tunnel network server must know how to handle and ver-
     ify RADIUS Access-Accept messages.
     
     While  this  scheme may 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.
     
     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 a RADIUS request, manual configura-
     tion, etc.). Since the RADIUS specification [3] requires that either a
     CHAP or PAP password be present  in  an  Access-Request  message,  but
     doesn't  require  that  it be non-empty, this scheme probably requires
     either attribute-specific processing on the RADIUS server, or addition
     of a new "Authorize-Only" RADIUS 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 his NAI with some special character ('*') if he wanted to
     be tunneled. This particular solution does not support compulsory tun-
     neling. Another solution involves keying on the domain portion of  the
     NAI;  all  users in domain 'X' would be tunneled to address 'Y'.  This
     proposal supports compulsory tunneling, but does not provide for user-
     
     
     
     Aboba & Zorn                                                  [Page 7]


     INTERNET-DRAFT                                        28 February 1997
     
     
     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  authorization-
     only  messages are used, the tunnel network server would need to rene-
     gotiate 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
     verify  the  identity  via RADIUS. However, in order for that to be of
     any use in accounting, the tunnel endpoint needs to  have  an  account
     relationship  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  nulli-
     fies many of the benefits of roaming.
     
     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 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.  Disadvantages  are  that  LCP must be renegotiated, and that
     dual authentications are required.
     
     Considering all  the  advantages  and  disadvantages  of  the  various
     schemes,  we  believe  that  this  scheme is the best choice, and as a
     result, the rest of this document focuses on the  dual  authentication
     scheme.
     
     
     
     
     
     
     
     
     Aboba & Zorn                                                  [Page 8]


     INTERNET-DRAFT                                        28 February 1997
     
     
     7.  Initiation Sequence
     
     The provisioning of a mandatory tunnel involves an interaction between
     the client, NAS, Tunnel  Server,  and  RADIUS  server.  The  following
     events occur in initiation of the connection:
     
          Client and NAS: PPP LCP negotiation
          Client and NAS: PPP authentication
          NAS to RADIUS Server: RADIUS Access-request
          RADIUS server to NAS: RADIUS Access-reply/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
          Client and Tunnel Server: PPP re-authentication
          Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
          RADIUS server to Tunnel Server: RADIUS Access-reply/Access-Reject
          Client and Tunnel Server: IPCP negotiation
          NAS to RADIUS Server: RADIUS Accounting-Request/START
          RADIUS Server to NAS: RADIUS Accounting-Reply
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request/START (Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Reply
     
     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 including the Tunnel-Type (L2F,
     PPTP, L2TP), Tunnel-Medium-Type (X.25, ATM, Frame Relay, IP), and Tun-
     nel-Server-Endpoint attributes.
     
     It  is possible that RADIUS proxies may be used to forward the Access-
     Reply message from the RADIUS server to the NAS. In  order  to  ensure
     that  the  mandatory  tunnel  attributes  arrive without modification,
     RADIUS proxies present in the path MUST NOT modify these attributes.
     
     Since this is a mandatory tunnel, address assignment will  be  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 IPCP negotiation, since this could create a time window
     in  which  the client will be capable of sending packets to the Inter-
     net, which is not permitted under mandatory tunneling.  If the authen-
     tication  is  unsuccessful,  the  RADIUS server sends a RADIUS Access-
     Reject. In this case, the NAS MUST disconnect the user.
     
     The NAS will now bring up a control connection to the tunnel server if
     none  existed  before.  This  is  accomplished  by sending a PPTP/L2TP
     Start-Control-Connection-Request message to the  tunnel  server.   The
     tunnel server replies with a PPTP/L2TP Start-Control-Connection-Reply.
     If this message indicates an error, or if the  control  connection  is
     terminated  at any future time, then the NAS MUST disconnect the user.
     
     
     
     
     
     Aboba & Zorn                                                  [Page 9]


     INTERNET-DRAFT                                        28 February 1997
     
     
     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 IP  addresses  of
     the  NAS and tunnel server, 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 disconnect the
     user. The NAS then replies with an Incoming-Call-Connected message.
     
     At this point, data may begin to flow through the tunnel.  The  client
     and  tunnel  server  must  now  renegotiate LCP and go through another
     round of PPP authentication.  At  the  time  that  this  renegotiation
     begins,  the  NAS should not have sent the final packet confirming the
     success of the initial authentication, and the client and NAS MUST NOT
     have  begun  IPCP negotiation. Rather than sending the final confirma-
     tion packet, the NAS will instead send an LCP down message. The Client
     will then attempt to 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 negotiation has been concluded, the
     IPCP phase will begin, and the tunnel server will assign an IP address
     to the client.
     
     If  L2TP  is  being used as the tunnel protocol, an alternative method
     may be used. This requires the NAS in its initial  setup  notification
     to  include  a  copy  of the LCP CONFACKs sent in each direction which
     completed LCP negotiation.  The tunnel server may then use this infor-
     mation  to avoid an additional LCP negotiation. With L2TP, the initial
     setup notification may also  include  the  authentication  information
     required  to  allow  the  tunnel  server  to authenticate the user and
     decide to accept or decline the  connection.  However,  this  facility
     should be used with caution since it creates a vulnerability to replay
     attacks, and in addition may create problems in the case where the NAS
     and tunnel server authenticate against different RADIUS servers.
     
     In performing the PPP authentication, the tunnel server may 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. There-
     fore having the tunnel server act as a RADIUS client provides for uni-
     fied user administration. Other methods are also  available,  such  as
     use  of LDAP by both the tunnel and RADIUS servers. Note that the tun-
     nel 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/START  packet  to  the  RADIUS  server. The
     Accounting-Request packet MUST include the following attributes:  Tun-
     nel-Type,  Tunnel-Medium-Type,  Tunnel-Client-Endpoint, Tunnel-Server-
     Endpoint, and Connection-Identifier.
     
     The tunnel server may produce its own accounting records,  or  it  may
     send  a  RADIUS  Accounting-Request/START  packet  to  a  local RADIUS
     
     
     
     Aboba & Zorn                                                 [Page 10]


     INTERNET-DRAFT                                        28 February 1997
     
     
     server. In the latter case, the RADIUS Accounting-Request/START packet
     MUST  contain  the  following  attributes: Tunnel-Type, Tunnel-Medium-
     Type, Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and  Connection-
     Identifier.
     
     The interactions involved in initiation of a mandatory tunnel are sum-
     marized below. In order to simplify the diagram that follows, we  have
     left  out the client. However, it should be understood that the client
     participates via PPP negotiation, authentication and  subsequent  data
     interchange with the Tunnel Server.
     
     
                                    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
                                                        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,
     
     
     
     Aboba & Zorn                                                 [Page 11]


     INTERNET-DRAFT                                        28 February 1997
     
     
                                  authenticate user,
                                  bring up IPCP,
                                  start accounting
                                  Send RADIUS
                                  Accounting-Request
                                  (optional)
                                                       Send
                                                       RADIUS
                                                       Accounting-Reply
     Send a RADIUS
     Accounting-Request message
     with Acct-Status-Type
     set to Start, containing
     Tunnel-Type, Tunnel-Medium-Type,
     Tunnel-Client-Endpoint,
     Tunnel-Server-Endpoint, and
     Connection-Identifier.
                                                       Send
                                                       RADIUS
                                                       Accounting-Reply
     
     ENDIF
     
     
     8.  Termination Sequence
     
     As  with  initiation,  the tear down of a mandatory tunnel involves an
     interaction between the client, NAS, Tunnel Server, and RADIUS server.
     The following events occur in termination of the connection:
     
          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/STOP
          RADIUS Server to NAS: RADIUS Accounting-Reply
          Tunnel Server to RADIUS Server: RADIUS Accounting-Request/STOP (Optional)
          RADIUS Server to Tunnel Server: RADIUS Accounting-Reply
     
     Tunnel  termination  may  occur  due to a client request (PPP termina-
     tion), a tunnel server request (Call-Clear-Request), or a telco  issue
     (call disconnect).
     
     In  the case of a client-requested termination, the tunnel server will
     terminate the PPP session. The tunnel server will subsequently send  a
     Call-Clear-Request  to  the NAS. The NAS will then send a Call-Discon-
     nect-Notify message to the tunnel  server,  and  will  disconnect  the
     call.
     
     The  NAS  will  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 telco issue or user hangup, the NAS will send a Call-
     Disconnect-Notify to the tunnel server. Both sides will then tear down
     the call.
     
     
     
     Aboba & Zorn                                                 [Page 12]


     INTERNET-DRAFT                                        28 February 1997
     
     
     After  call  tear down is complete, the NAS and tunnel server may stop
     accounting.  In the case of the NAS, this is done by sending a  RADIUS
     Accounting-Request/STOP  packet  to the RADIUS server. The Accounting-
     Request packet MUST include  the  following  attributes:  Tunnel-Type,
     Tunnel-Medium-Type,   Tunnel-Client-Endpoint,  Tunnel-Server-Endpoint,
     and Connection-Identifier.
     
     The tunnel server may produce its own accounting records,  or  it  may
     send a RADIUS Accounting-Request/STOP packet to a local RADIUS server.
     In the latter case, the  RADIUS  Accounting-Request/STOP  packet  MUST
     contain  the  following  attributes:  Tunnel-Type, Tunnel-Medium-Type,
     Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Connection-Identi-
     fier.
     
     The  interactions  involved  in  termination of a mandatory tunnel are
     summarized below. In order to simplify the diagram  that  follows,  we
     have  left  out  the client. However, it should be understood that the
     client participates 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/STOP
                                    message (optional)
                                                         Send RADIUS
                                                         Accounting-Reply
     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/STOP
                                    message (optional)
                                                         Send RADIUS
                                                         Accounting-Reply
     
      Send a RADIUS
      Accounting-Request message
      with Acct-Status-Type
     
     
     
     Aboba & Zorn                                                 [Page 13]


     INTERNET-DRAFT                                        28 February 1997
     
     
      set to Stop, containing
      Tunnel-Type, Tunnel-Medium-Type,
      Tunnel-Client-Endpoint,
      Tunnel-Server-Endpoint, and
      Connection-Identifier.
                                                         Send RADIUS
                                                         Accounting-Reply
     
     ENDIF
     
     
     9.  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 mandatory tunnels.
     
     
     9.1.  Distinct userIDs
     
     If distinct RADIUS servers are being used, it is likely that two  dis-
     tinct  userID/password  pairs  will be required to complete the RADIUS
     and tunnel authentications. One pair will be used in the  initial  PPP
     authentication,  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 token 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.
     
     
     
     
     
     
     
     Aboba & Zorn                                                 [Page 14]


     INTERNET-DRAFT                                        28 February 1997
     
     
     9.2.  Multilink PPP issues
     
     It is possible for the two RADIUS servers to return distinct MAX CHAN-
     NEL  attributes.  For  example,  it is conceivable that the NAS RADIUS
     server will only grant use of a single channel to the user, while  the
     tunnel  RADIUS  server will grant more than one channel. In this case,
     the correct 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 dual channels, but that the tunnel RADIUS server
     will only allow a single channel. In this case, the client should ter-
     minate use of the second channel.
     
     
     10.  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.
     
     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.
     
     
     10.1.  UserID convergence in user-based tunneling
     
     The use of RADIUS in provisioning of mandatory 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
     response  to that request is in turn used to determine the tunnel end-
     point.
     
     Since the framework described in this document allows  both  ISPs  and
     tunnel  users  to  authenticate users as well as account for resources
     consumed by  them,  and  provides  for  maintenance  of  two  distinct
     userID/password pairs, it is believed that this scheme offers the max-
     imum degree of flexibility.  Where RADIUS proxies  and  tunneling  are
     employed, it is possible to allow the user to authenticate with a sin-
     gle userID/password pair at both the NAS and the tunnel endpoint. This
     is  accomplished  by routing 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@domain, i.e. fred@bigco.com.
     
     
     
     Aboba & Zorn                                                 [Page 15]


     INTERNET-DRAFT                                        28 February 1997
     
     
     11.  Acknowledgements
     
     Thanks  to Gurdeep Singh Pall of Microsoft for many useful discussions
     of this problem space.
     
     
     12.  References
     
     [1]  B. Aboba, J. Lu, J. Alsop, J. Ding.  "Review of Roaming Implemen-
     tations."  draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass
     Alliance, Asiainfo, January, 1997.
     
     [2]  B. Aboba, G. Zorn.  "Dialup  Roaming  Requirements."  draft-ietf-
     roamops-roamreq-02.txt, Microsoft, January, 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." draft-
     ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996.
     
     [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, J.  Taarud,  W.  A.
     Little.   "Point-to-Point  Tunneling  Protocol  --  PPTP." draft-ietf-
     pppext-pptp-00.txt, Ascend Communications, June, 1996.
     
     [7] G. Zorn.  "RADIUS Attributes for Tunnel Protocol Support."  draft-
     ietf-radius-tunnel-auth-00.txt, Microsoft Corporation, November, 1996.
     
     [8] B. Aboba.  "The Network  Access  Identifier."  draft-ietf-roamops-
     nai-01.txt, Microsoft Corporation, February, 1997.
     
     [9]  S.  Bradner.   "Key words for use in RFCs to Indicate Requirement
     Levels." draft-bradner-key-words-02.txt, Harvard  University,  August,
     1996.
     
     [10]  C.  Rigney, W. Willats.  "RADIUS Extensions." draft-ietf-radius-
     ext-00.txt, Livingston, January, 1997.
     
     
     
     13.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-936-6605
     EMail: bernarda@microsoft.com
     
     
     
     Aboba & Zorn                                                 [Page 16]


     INTERNET-DRAFT                                        28 February 1997
     
     
     Glen Zorn
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-703-1559
     EMail: glennz@microsoft.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Zorn                                                 [Page 17]