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

Versions: 00 01 02 03 04 05 07 rfc2809                                  
     RADIUS Working Group                                     Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-ietf-radius-tunnel-imp-01.txt>                        Glen Zorn
     7 March 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-01.txt>  and   expires  September   15,   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 can be accomplished via the inte-
     gration of RADIUS and tunneling protocols.
     
     
     3.  Terminology
     
     
     Roaming   "Roaming capability" can be loosely defined  as  the ability
               to  use  any  one  of  multiple  Internet  service providers
               (ISPs), while maintaining a formal,  customer-vendor   rela-
               tionship  with  only one. Examples  of  cases  where roaming
               capability might be required  include  ISP  "confederations"
               and ISP-provided corporate network access support.
     
     Shared Use Network
               This is an IP dialup network whose use is shared by  two  or
               more organizations.  Shared use networks typically implement
               distributed authentication and accounting in order to facil-
               itate  the  relationship  among  the  sharing parties. Since
     
     
     
     Aboba & Zorn                                                  [Page 1]


     INTERNET-DRAFT                                            7 March 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 can offer roaming ser-
               vice is to conclude shared use agreements with multiple net-
               works.  However,  to date the ability to accomplish this has
               been hampered by lack of interoperability among  shared  use
               implementations.
     
     Tunnel Network Server
               This is a server which terminates a tunnel. In  PPTP  termi-
               nology,  this  is known as the PPTP Network Server (PNS). In
               L2TP terminology, this is known as the L2TP  Network  Server
               (LNS).
     
     Network Access Server
               The  Network  Access Server (NAS) is the device that clients
               contact in order to get access to the network. In PPTP  ter-
               minology this is referred to as the PPTP Access Concentrator
               (PAC). In L2TP terminology, the NAS is referred  to  as  the
               L2TP Access Concentrator (LAC).
     
     RADIUS server
               This  is  a  server which provides for authentication/autho-
               rization via the protocol described in [3], and for account-
               ing as described in [4].
     
     RADIUS proxy
               In order to provide for the routing of RADIUS authentication
               and accounting requests, a RADIUS proxy can be employed.  To
               the NAS, the RADIUS proxy appears to act as a RADIUS server,
               and to the RADIUS server, the proxy  appears  to  act  as  a
               RADIUS client.
     
     Network Access Identifier
               In order to provide for the routing of RADIUS authentication
               and accounting requests, the userID field used in PPP and in
               the   subsequent   RADIUS   authentication   and  accounting
               requests, known as the Network Access Identifier  (NAI)  MAY
               contain  structure. This structure provides a means by which
               the RADIUS proxy will locate the RADIUS server  that  is  to
               receive the request. This same structure MAY also be used to
               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                                            7 March 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                                            7 March 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
     desire to provide Janet with an account that allows access to both the
     
     
     
     Aboba & Zorn                                                  [Page 4]


     INTERNET-DRAFT                                            7 March 1997
     
     
     Internet  and the intranet, with Janet's intranet access provided by a
     tunnel server located in the engineering department. However BIGCO may
     desire  to  provide  Fred with an account that provides only access to
     the intranet, with Fred's intranet access provided by a tunnel network
     server  located  in  the  sales department. Such a situation cannot be
     accommodated with realm-based tunneling.
     
     On the other hand, user-based tunneling as enabled by  the  attributes
     defined  in [7] provides BIGCO with the flexibility to administer tun-
     neling behavior on a per-user basis. When  deployed  in  concert  with
     roaming,  user-based tunneling offers corporations the ability to pro-
     vide their users with access to the corporate  Intranet  on  a  global
     basis.
     
     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, L2TP, etc.), 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  Connection  Identifier,
     and  the tuple (userID, tunnel-client-endpoint address, tunnel-server-
     endpoint address, Call-Serial-Number) is used to uniquely identify the
     call. In order to protect against wrapping due to reboots or call vol-
     ume, it is recommended that a 64-bit NTP  timestamp  be  used  as  the
     
     
     
     Aboba & Zorn                                                  [Page 5]


     INTERNET-DRAFT                                            7 March 1997
     
     
     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                                            7 March 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 can be workable if the reply comes directly from a
     RADIUS server, it would become  unmanageable  if  a  RADIUS  proxy  is
     involved,  since  the  reply  would  be authenticated using the secret
     shared by the client and proxy, rather than the RADIUS server.
     
     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                                            7 March 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  unless LCP forwarding is used, LCP
     will need to  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                                            7 March 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 (optional)
          Client and Tunnel Server: PPP authentication
          Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
          RADIUS server to Tunnel Server: RADIUS Access-reply/Access-Reject
          Client and Tunnel Server: NCP 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,  etc.),  Tunnel-Medium-Type (X.25, ATM, Frame Relay, IP),
     and Tunnel-Server-Endpoint attributes.
     
     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. If the tunnel attributes
     received from the RADIUS server are not acceptable to the proxy,  then
     the proxy MUST send an Access-Reject to the NAS.
     
     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 NCP negotiation, since this could create a time window
     in which the client will be capable of sending packets to  the  trans-
     port  network,  which  is not permitted under mandatory tunneling.  If
     the authentication 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                                            7 March 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 MAY 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
     NCP negotiation. Rather than sending the  final  confirmation  packet,
     the  NAS  will  instead  send an LCP down message. The Client MAY then
     renegotiate LCP, and from that point forward, all PPP  packets  origi-
     nated  from  the  client  will  be encapsulated and sent to the tunnel
     server.  When LCP re-negotiation has been  concluded,  the  NCP  phase
     will  begin,  and  the  tunnel  server  will  assign an address to the
     client.
     
     If L2TP is being used as the tunnel protocol, the NAS MAY in its  ini-
     tial  setup  notification  include  a copy of the LCP CONFACKs sent in
     each direction which completed LCP negotiation. The tunnel server  MAY
     then use this information to avoid an additional LCP negotiation. With
     L2TP, the initial setup notification can also include the  authentica-
     tion  information  required to allow the tunnel server to authenticate
     the user and decide to accept or decline the connection. However, this
     facility  creates  a  vulnerability  to replay attacks, and can create
     problems in the case where the  NAS  and  tunnel  server  authenticate
     against  different  RADIUS servers. As a result, where user-based tun-
     neling via  RADIUS  is  implemented,  L2TP  authentication  forwarding
     SHOULD NOT be employed.
     
     In performing the PPP authentication, the tunnel server can access its
     own user database, or it MAY send a RADIUS Access-Request. 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.
     
     
     
     
     
     Aboba & Zorn                                                 [Page 10]


     INTERNET-DRAFT                                            7 March 1997
     
     
     The tunnel server can 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 is understood that the client partic-
     ipates via PPP negotiation, authentication and subsequent data  inter-
     change 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
     
     
     
     
     Aboba & Zorn                                                 [Page 11]


     INTERNET-DRAFT                                            7 March 1997
     
     
     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
          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  can  occur  due to a client request (PPP termina-
     tion), a tunnel server request (Call-Clear-Request), or a line problem
     (call disconnect).
     
     In  the case of a client-requested termination, the tunnel server MUST
     terminate the PPP session. The tunnel server MUST subsequently send  a
     Call-Clear-Request  to  the NAS. The NAS MUST then send a Call-Discon-
     nect-Notify message to the tunnel  server,  and  will  disconnect  the
     call.
     
     The  NAS  MUST  also respond with a Call-Disconnect-Notify message and
     disconnection if it receives  a  Call-Clear-Request  from  the  tunnel
     server without a client-requested termination.
     
     
     
     
     
     Aboba & Zorn                                                 [Page 12]


     INTERNET-DRAFT                                            7 March 1997
     
     
     In  the  case  of  a  line problem or user hangup, the NAS MUST send a
     Call-Disconnect-Notify to the tunnel server. Both sides will then tear
     down the  call.
     
     After  call  tear down is complete, if RADIUS accounting is being used
     then the NAS MUST send a RADIUS Accounting-Request/STOP packet to  the
     RADIUS  server.  The  Accounting-Request/STOP  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
     use RADIUS accounting. If RADIUS accounting is  being  used  then  the
     tunnel  server  MUST send a RADIUS Accounting-Request/STOP packet to a
     local RADIUS server. The 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 is understood  that  the  client
     MAY participate via PPP termination and disconnection.
     
                                    TERMINATION SEQUENCE
     
     NAS                            Tunnel Server         RADIUS Server
     ---                            -------------         -------------
     IF user disconnected
      send
      Call-Disconnect-Notify
      message to tunnel server
                                    Tear down the call
                                    stop accounting
                                    Send RADIUS
                                    Accounting-Request/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
     
     
     
     
     Aboba & Zorn                                                 [Page 13]


     INTERNET-DRAFT                                            7 March 1997
     
     
      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 with the NAS, and the second pair will be used for  the
     tunnel authentication.
     
     However, in order to provide maximum ease of use in the case where the
     userID/password pairs are identical, tunnel clients typically  attempt
     authentication  with  the same userID/password pair as was used in the
     initial PPP negotiation. Only after this fails do they prompt the user
     for the second pair.
     
     In  this  case,  tunnel client implementations SHOULD take care not to
     put up error messages indicating a  bad  password.  Instead  a  dialog
     SHOULD be presented requesting the tunnel userID/password combination.
     
     In the case where 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                                            7 March 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 multiple  channels,  but  that  the  tunnel  RADIUS
     server  will  allow fewer channels than the NAS RADIUS server. In this
     case, the client should terminate use of the excess channels.
     
     
     
     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.
     
     
     
     
     
     Aboba & Zorn                                                 [Page 15]


     INTERNET-DRAFT                                            7 March 1997
     
     
     As  described  in  [8],  the  recommended  form  for  the  user  ID is
     userID@domain, i.e. fred@bigco.com.
     
     
     11.  Acknowledgements
     
     Thanks to Gurdeep Singh Pall of Microsoft for many useful  discussions
     of  this problem space, and to Bertrand Buclin of AT&T Labs Europe for
     his comments on this document.
     
     
     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-02.txt, Microsoft Corporation, March, 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
     
     
     
     Aboba & Zorn                                                 [Page 16]


     INTERNET-DRAFT                                            7 March 1997
     
     
     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 17]