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

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

Network Working Group                                    Bernard Aboba
INTERNET-DRAFT                                   Microsoft Corporation
<draft-aboba-radius-tunnel-imp-00.txt>                       Glen Zorn
November 20, 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
material 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-00.txt>  and   expires  May  25, 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 integra-
tion 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                                       November 20, 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
          authentication/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.

RADIUS realm
          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,  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  realm-
          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                                       November 20, 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.

Given  the  existence  of widespread support for mandatory  tunneling,



Aboba & Zorn                                                  [Page 3]


INTERNET-DRAFT                                       November 20, 1996


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  identify  the call. In order to protect against wrapping due
to reboots or call volume, it is recommended that a 64-bit NTP  times-
tamp 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 deter-
mining the Call-Serial-Number is  specified,  which  leaves  open  the



Aboba & Zorn                                                  [Page 4]


INTERNET-DRAFT                                       November 20, 1996


possibility  of  wrapping  after  a  reboot.  Finally  since the Call-
Serial-Number is a 16-bit value, the Call-Serial-Number is not  suffi-
cient  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  32-bit  NTP
timestamp be used for this purpose.


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 server
located in the sales department. Such a situation cannot  be  accommo-
dated 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
implementation  of  several  new RADIUS attributes. During authentica-
tion, the new attributes allow the RADIUS server to indicate the  tun-
nel protocol (PPTP, L2F, or L2TP), 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



Aboba & Zorn                                                  [Page 5]


INTERNET-DRAFT                                       November 20, 1996


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.  Initiation Sequence

The provisioning of a mandatory tunnel involves an interaction between
the  client,  NAS,  Tunnel  Server,  and  RADIUS server. The following
events occur in initiation of the connection:

     Client and NAS: PPP LCP negotiation
     Client and NAS: PPP authentication
     NAS to RADIUS Server: RADIUS Access-request
     RADIUS server to NAS: RADIUS Access-reply/Access-Reject
     NAS to Tunnel Server: PPTP/L2TP Incoming-Call-Request
     Tunnel Server to NAS: PPTP/L2TP Incoming-Call-Reply
     NAS to Tunnel Server: PPTP/L2TP  Incoming-Call-Connected
     Client and Tunnel Server: PPP LCP re-negotiation
     Client and Tunnel Server: PPP re-authentication
     Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
     RADIUS server to Tunnel Server: RADIUS Access-reply/Access-Reject
     Client and Tunnel Server: IPCP negotiation
     NAS to RADIUS Server: RADIUS Accounting-Request/START
     RADIUS Server to NAS: RADIUS Accounting-Reply
     Tunnel Server to RADIUS Server: RADIUS Accounting-Request/START (Optional)
     RADIUS Server to Tunnel Server: RADIUS Accounting-Reply

The process begins with an incoming call to the NAS.  The  client  and
NAS  then  begin  LCP negotiation. Subsequently the PPP authentication
phase starts, and the NAS sends a RADIUS Access-Request message to the
RADIUS  server. If the authentication is successful, the RADIUS server
responds with a RADIUS Access-Reply indicating a ACK and including the
following attributes: the tunnel type (L2F, PPTP, L2TP), tunnel medium



Aboba & Zorn                                                  [Page 6]


INTERNET-DRAFT                                       November 20, 1996


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
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.

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,
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
methods are also available, such as use of LDAP. Note that the  tunnel
server's RADIUS Access-Request is typically sent directly to the local



Aboba & Zorn                                                  [Page 7]


INTERNET-DRAFT                                       November 20, 1996


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:
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/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
                                                         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




Aboba & Zorn                                                  [Page 8]


INTERNET-DRAFT                                       November 20, 1996


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


7.  Termination Sequence

As with initiation, the tear down of a mandatory  tunnel  involves  an
interaction between the client, NAS, Tunnel Server, and RADIUS server.
The following events occur in termination of the connection:

     Tunnel Server to NAS: PPTP/L2TP Call-Clear-Request (optional)
     NAS to Tunnel Server: PPTP/L2TP Call-Disconnect-Notify
     NAS to RADIUS Server: RADIUS Accounting-Request/STOP
     RADIUS Server to NAS: RADIUS Accounting-Reply
     Tunnel Server to RADIUS Server: RADIUS Accounting-Request/STOP (Optional)
     RADIUS Server to Tunnel Server: RADIUS Accounting-Reply

Tunnel termination may occur due to a  client  request  (PPP  termina-
tion),  a tunnel server request (Call-Clear-Request), or a telco issue
(call disconnect).

In the case of a client-requested termination, the tunnel server  will
terminate  the PPP session. The tunnel server will subsequently send a
Call-Clear-Request to  the  NAS.  The  NAS  will  then  send  a  Call-
Disconnect-Notify  message  to  the tunnel server, and will disconnect
the call.



Aboba & Zorn                                                  [Page 9]


INTERNET-DRAFT                                       November 20, 1996


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)
                                                        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



Aboba & Zorn                                                 [Page 10]


INTERNET-DRAFT                                       November 20, 1996


                                   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


8.  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.


8.1.  Distinct userIDs

If distinct RADIUS servers are being used, it is likely that two  dis-
tinct  userID/password  pairs  will be required to complete the RADIUS
and tunnel authentications. One pair will be used in the  initial  PPP
authentication,  and  the  second  pair  will  be  used for the tunnel
authentication.

However, in order to provide maximum ease of use in the case where the
userID/password  pairs are identical, tunnel clients typically attempt
authentication with the same userID/password pair as was used  in  the
initial PPP negotiation. Only after this fails do they prompt the user
for the second pair.

In this case, tunnel client implementations should take  care  not  to
put  up  error  messages  indicating  a bad password. Instead a dialog
should be presented requesting the tunnel userID/password combination.

In the case where token cards are being used for both authentications,
the  tunnel  client  MUST NOT attempt to present the token used in the
first authentication during the  second  authentication,  since  these
will  never be identical. Instead the user should be prompted to enter
the second token.


8.2.  Multilink PPP issues

It is possible for the two  RADIUS  servers  to  return  distinct  MAX



Aboba & Zorn                                                 [Page 11]


INTERNET-DRAFT                                       November 20, 1996


CHANNEL 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.


9.  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.


9.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
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 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



Aboba & Zorn                                                 [Page 12]


INTERNET-DRAFT                                       November 20, 1996


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.


10.  Acknowledgements

Thanks to Gurdeep Singh Pall of Microsoft for many useful  discussions
of this problem space.


11.  References

[1]  B. Aboba, L. Liu, J. Alsop, J. Ding.  "Review of  Roaming  Imple-
mentations."  draft-aboba-roam-rev-00.txt,  Microsoft,  Aimnet, i-Pass
Alliance, Asiainfo, September, 1996.

[2]  B. Aboba, G. Zorn.  "Dialup  Roaming  Requirements."  draft-zorn-
dial-roam-req-02.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.



Aboba & Zorn                                                 [Page 13]


INTERNET-DRAFT                                       November 20, 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-
radius-tunnel-auth-00.txt, Microsoft Corporation, October, 1996.

[8] B. Aboba.  "The Network Access Identifier and Authentication Rout-
ing."  draft-aboba-roam-nai-00.txt,  Microsoft  Corporation, November,
1996.



12.  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 14]


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