[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-radius-tunnel-imp

     Network Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-aboba-radius-tunnel-imp-01.txt>                       Glen Zorn
     26 November 1996                                 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-
     aboba-radius-tunnel-imp-01.txt> and  expires  June  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                                        26 November 1996
     
     
               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  authentica-
               tion/authorization via the protocol described  in  [3],  and
               for accounting 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  document  uses  the  same words as RFC 1123 [4] for defining the
     significance of each particular requirement.  These words are:
     
     
     MUST      This word or the adjective "required" means that the item is
               an absolute requirement of the specification.
     
     
     
     Aboba & Zorn                                                  [Page 2]


     INTERNET-DRAFT                                        26 November 1996
     
     
     MUST NOT  This  phrase means that the definition is an absolute prohi-
               bition of the specification.
     
     
     SHOULD    This word or the adjective "recommended"  means  that  there
               may  exist  valid  reasons  in  particular  circumstances to
               ignore this item, but the full implications should be under-
               stood  and the case carefully weighed before choosing a dif-
               ferent course.
     
     
     MAY       This word or the adjective "optional" means that  this  item
               is truly optional. One vendor may choose to include the item
               because a particular marketplace requires it or  because  it
               enhances  the  product, for example; another vendor may omit
               the same item.
     
     
     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 and all the SHOULD requirements for its proto-
               cols is said to be  "unconditionally  compliant";  one  that
               satisfies  all  the MUST requirements but not all the SHOULD
               requirements for its protocols is said to be  "conditionally
               compliant."
     
     
     5.  Introduction
     
     Many  of the most interesting applications of tunneling protocols such
     as PPTP and L2TP 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 purpose. Other applications involve
     compulsory 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.
     
     
     
     
     
     Aboba & Zorn                                                  [Page 3]


     INTERNET-DRAFT                                        26 November 1996
     
     
     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:
     
     Auditing capabilities
     Per-user tunneling
     Telephone-number based authentication and accounting
     
     
     5.1.  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 ability to audit ISP bills. This capa-
     bility 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.1.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
     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
     
     
     
     Aboba & Zorn                                                  [Page 4]


     INTERNET-DRAFT                                        26 November 1996
     
     
     determining the Call-Serial-Number is specified, which leaves open the
     possibility 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.2.  Per-user 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. Per-user tunneling as pro-
     vided by integration of RADIUS and tunnel protocols offers significant
     advantages over both of these approaches.
     
     Static  tunneling  requires dedication of a NAS device to the purpose.
     In the case of an ISP, this is undesirable because it requires them to
     dedicate  a  NAS  to tunneling service for a given corporate customer,
     rather than allowing them to use existing NASes deployed in the field.
     As  a result static tunneling is likely to be costly for deployment of
     a global service.
     
     Realm-based tunneling assumes that all users within a given realm wish
     to be treated the same way. This limits a corporation's flexibility in
     managing the account rights of their users.  For  example,  BIGCO  may
     wish  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
     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,  per-user 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, per-user tunneling offers corporations the ability to provide
     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,  or  L2TP),  the
     
     
     
     Aboba & Zorn                                                  [Page 5]


     INTERNET-DRAFT                                        26 November 1996
     
     
     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, and allow linking of the RADIUS server and
     tunnel server accounting records.
     
     
     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.
     
     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.
     
     
     
     
     
     Aboba & Zorn                                                  [Page 6]


     INTERNET-DRAFT                                        26 November 1996
     
     
     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  per-
     user 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 by adding a field within the Authorization-
     Only message for an MD5 hash over the contents of  the  message  (with
     the authenticator field set to zero) and the shared secret.
     
     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
     
     
     
     Aboba & Zorn                                                  [Page 7]


     INTERNET-DRAFT                                        26 November 1996
     
     
     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.
     
     
     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)
     
     
     
     Aboba & Zorn                                                  [Page 8]


     INTERNET-DRAFT                                        26 November 1996
     
     
          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-Reply indicating a ACK and including the
     following attributes: the tunnel type (L2F, PPTP, L2TP), tunnel medium
     type (X.25, ATM, Frame Relay, IP), and the address of the remote  tun-
     nel endpoint.
     
     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 in
     any way.
     
     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  authentication  is  unsuccessful,  the  RADIUS server sends a
     RADIUS Access-Reply indicating a NAK. In this case, the NAS MUST  dis-
     connect 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.
     
     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 begins to flow through the tunnel, and the client
     and tunnel server must renegotiate LCP and go through another round of
     PPP  authentication.  At  the time that this renegotiation begins, the
     client and NAS should have concluded LCP  negotiation,  but  must  not
     have  begun IPCP negotiation. When LCP negotiation has been concluded,
     
     
     
     Aboba & Zorn                                                  [Page 9]


     INTERNET-DRAFT                                        26 November 1996
     
     
     the IPCP phase will begin, and the tunnel server  will  assign  an  IP
     address to the client.
     
     In performing the PPP authentication, the tunnel server may access its
     own user database, or it may issue a RADIUS Access-Request to a RADIUS
     server.  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  server  and tunnel server 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 a means for unifying user administration. Other  meth-
     ods  are  also  available,  such  as use of LDAP. Note that the tunnel
     server's RADIUS Access-Request is typically sent directly to the local
     RADIUS server rather than being forwarded via the authentication rout-
     ing procedure described in [8].
     
     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
     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,
                                                               and Tunnel-Server-Endpoint
     
     
     
     Aboba & Zorn                                                 [Page 10]


     INTERNET-DRAFT                                        26 November 1996
     
     
                                                              ELSE Send NAK
     IF NAK DISCONNECT
     ELSE
      IF no control
       connection exists
       Send
       Start-Control-Connection-Request
       message 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 (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
     
     
     
     Aboba & Zorn                                                 [Page 11]


     INTERNET-DRAFT                                        26 November 1996
     
     
          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-
     Disconnect-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.
     
     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-
     Identifier.
     
     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)
     
     
     
     Aboba & Zorn                                                 [Page 12]


     INTERNET-DRAFT                                        26 November 1996
     
     
                                                             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
      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.
     
     
     
     
     Aboba & Zorn                                                 [Page 13]


     INTERNET-DRAFT                                        26 November 1996
     
     
     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.
     
     
     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 has emerged.
     
     To head off this conflict, we must come to agreement on the syntax and
     semantics  expected from the userID. This convergence must be achieved
     to allow for use of mandatory tunneling in roaming or  shared  network
     situations.
     
     
     10.1.  UserID convergence in per-user tunneling
     
     Among  other  things,  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  authentica-
     tion/authorization request as well for  determination  of  the  tunnel
     
     
     
     Aboba & Zorn                                                 [Page 14]


     INTERNET-DRAFT                                        26 November 1996
     
     
     endpoint,  the userID is now used solely for routing of RADIUS authen-
     tication/authorization requests. The response to that  request  is  in
     turn used to determine the tunnel endpoint.
     
     In  fact,  in  per-user tunneling the userID and password submitted to
     RADIUS need not even be valid at the tunnel endpoint. In proposals [5]
     and  [6]  after  the  user is granted access to the NAS, an attempt is
     made to bring up a tunnel using the userID and password  submitted  by
     the  user.  However,  if  this userID and password is not valid on the
     tunnel endpoint, the user will then be asked to submit another  userID
     and  password. Thus it is not required that the user maintain the same
     userID and password both for his ISP and tunnel endpoint.
     
     Since the framework provided in [7] 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 maximum degree of
     flexibility.  However, in a great number of situations, it  is  highly
     desirable  for  the  user to only have to remember a single userID and
     password. This is made possible by the joint implementation of  RADIUS
     authentication routing and tunneling.
     
     How  will  this work in practice? Typically the user will login with a
     userID  of  the  form  userID  [@  |  :  |  /  ]   domain.   Examples:
     fred@bigco.com, fred:bigco.com, fred/bigco.com.
     
     Let  us  assume  that  user  Fred logs in to a NAS using his corporate
     account,  fred@bigco.com,  and  wishes  to  access  BIGCO's  Intranet.
     Through  a  process  described  in  [8],  the RADIUS access-request is
     routed to BIGCO's RADIUS server, which then returns tunnel  attributes
     in the RADIUS access-reply.
     
     After  it receives the tunnel attributes, the NAS will attempt to open
     a tunnel to the tunnel server specified in  the  RADIUS  access-reply,
     using  the  specified tunnel-type and tunnel-media. Fred's client will
     then attempt to authenticate  against  the  tunnel  server,  with  the
     userID  fred@bigco.com,  and  the  original  password.  Assuming  that
     BIGCO's RADIUS and tunnel server go against the  same  user  database,
     then  this  authentication  will  succeed. This can be accomplished by
     having the tunnel server act as a  RADIUS client, as described  previ-
     ously.
     
     
     11.  Acknowledgements
     
     Thanks  to Gurdeep Singh Pall of Microsoft for many useful discussions
     of this problem space.
     
     
     12.  References
     
     [1]  B. Aboba, L. Liu, J. Alsop, J. Ding.  "Review of  Roaming  Imple-
     mentations."  draft-ietf-roamops-imprev-00.txt,  Microsoft, Aimnet, i-
     Pass Alliance, Asiainfo, September, 1996.
     
     
     
     Aboba & Zorn                                                 [Page 15]


     INTERNET-DRAFT                                        26 November 1996
     
     
     [2]  B. Aboba, G. Zorn.  "Dialup  Roaming  Requirements."  draft-ietf-
     roamops-roamreq-00.txt, Microsoft, October, 1996.
     
     [3]  C. Rigney, A. Rubens, W. A. Simpson, S. Willens.  "Remote Authen-
     tication  Dial   In   User   Service   (RADIUS)."   draft-ietf-radius-
     radius-05.txt, Livingston, Merit, Daydreamer, July 1996.
     
     [4]     C.    Rigney.     "RADIUS    Accounting."   draft-ietf-radius-
     accounting-05.txt, Livingston, July 1996.
     
     [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-00.txt, Ascend Communications, August, 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-
     zorn-radius-tunnel-auth-00.txt,  Microsoft Corporation, October, 1996.
     
     [8] B. Aboba.  "The Network Access Identifier and Authentication Rout-
     ing."  draft-ietf-roamops-nai-00.txt, Microsoft Corporation, November,
     1996.
     
     
     
     13.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-936-6605
     EMail: bernarda@microsoft.com
     
     Glen Zorn
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-703-1559
     EMail: glennz@microsoft.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Zorn                                                 [Page 16]
     

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/