One document matched: draft-ietf-radius-tunnel-imp-04.txt
Differences from draft-ietf-radius-tunnel-imp-03.txt
RADIUS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
Category: Standards Track Glen Zorn
<draft-ietf-radius-tunnel-imp-04.txt> Microsoft
9 October 1998
Implementation of L2TP Compulsory Tunneling via RADIUS
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (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-04.txt> and expires May 1, 1999. Please send
comments to the authors.
2. Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
3. Abstract
This document discusses implementation issues arising in the provi-
sioning of compulsory tunneling in dial-up networks using the L2TP
protocol. This provisioning can be accomplished via the integration
of RADIUS and tunneling protocols. Implementation issues encountered
with other tunneling protocols are left to separate documents.
4. Terminology
Voluntary Tunneling
In voluntary tunneling, a tunnel is created by the user,
typically via use of a tunneling client.
Aboba & Zorn Standards Track [Page 1]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
Compulsory Tunneling
In compulsory tunneling, a tunnel is created without any
action from the user and without allowing the user any
choice.
Tunnel Network Server
This is a server which terminates a tunnel. In L2TP termi-
nology, 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 L2TP ter-
minology, a NAS performing compulsory tunneling is referred
to as the L2TP Access Concentrator (LAC).
RADIUS authentication server
This is a server which provides for authentication/autho-
rization via the protocol described in [1].
RADIUS proxy
In order to provide for the routing of RADIUS authentication
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.
be used to locate the tunnel endpoint when realm-based tun-
neling is used.
5. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [4].
6. Introduction
Many applications of tunneling protocols involve dial-up network
access. Some, such as the provisioning of secure access to corporate
intranets via the Internet, are characterized by voluntary tunneling:
the tunnel is created at the request of the user for a specific pur-
pose. Other applications involve compulsory tunneling: the tunnel is
created without any action from the user and without allowing the user
any choice.
Examples of applications that might be implemented using compulsory
tunnels are Internet software upgrade servers, software registration
servers and banking services. These are all services which,without
compulsory tunneling, would probably be provided using dedicated net-
works or at least dedicated network access servers (NAS), since they
are characterized by the need to limit user access to specific hosts.
Given the existence of widespread support for compulsory tunneling,
however, these types of services could be accessed via any Internet
Aboba & Zorn Standards Track [Page 2]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
service provider (ISP). The most popular means of authorizing dial-up
network users today is through the RADIUS protocol. The use of
RADIUS allows the dial-up users' authorization and authentication data
to be maintained in a central location, rather than on each NAS. It
makes sense to use RADIUS to centrally administer compulsory tun-
neling, since RADIUS is widely deployed and was designed to
carry this type of information. New RADIUS attributes are needed to
carry the tunneling information from the RADIUS server to the NAS.
Those attributes are defined in [3].
6.1. Advantanges of RADIUS-based compulsory 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 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 flexibility in account manage-
ment. For example, BIGCO may desire to provide Janet with an account
that allows access to both the Internet and the intranet, with Janet's
intranet access provided by a tunnel server located in the engineering
department. However BIGCO may desire to provide Fred with an account
that provides only access to the intranet, with Fred's intranet access
provided by a tunnel network server located in the sales department.
Such a situation cannot be accommodated with realm-based tunneling,
but can be accomodated via user-based tunneling as enabled by the
attributes defined in [3].
7. Authentication alternatives
RADIUS-based compulsory tunneling can support both single authentica-
tion, where the user is authenticated at the NAS or tunnel server, or
dual authentication, where the user is authenticated at both the NAS
and the tunnel server. When single authentication is supported, a
variety of modes are possible, including telephone-number based
authentication. When dual-authentication is used, a number of modes
are available, including dual CHAP authentications; CHAP/EAP authenti-
cation; CHAP/PAP(token) authentication; and EAP/EAP authentication,
using the same EAP type for both authentications. EAP is described in
[5].
Aboba & Zorn Standards Track [Page 3]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
The alternatives are described in more detail below.
7.1. Single authentication
Single authentication alternatives include:
NAS authentication
NAS authentication with RADIUS reply forwarding
Tunnel server authentication
7.1.1. NAS authentication
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 permits accounting to done at the NAS. Disadvantages are
that it requires that the tunnel server trust the NAS, since no user
authentication occurs at the tunnel server. Due to the lack of user
authentication, accounting cannot take place at the tunnel server with
strong assurance that the correct party is being billed.
NAS-only authentication is most typically employed along with LCP for-
warding and tunnel authentication, both of which are supported in
L2TP, described in [2]. Thus, the tunnel server can be set up to
accept all calls occurring within authenticated tunnels, without
requiring PPP authentication. However, this approach is not compati-
ble with roaming, since the tunnel server will typically only be set
up to accept tunnels from a restricted set of NASes. A typical initia-
tion sequence looks like this:
Client and NAS: Call Connected
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: NCP negotiation
The process begins with an incoming call to the NAS, and the PPP LCP
negotiation between the client and the NAS. In order to authenticate
the client, the NAS will send a RADIUS Access-Request to the RADIUS
server and will receive a RADIUS Access-Accept including tunnel
attributes, or an Access-Reject.
In the case where an L2TP tunnel is indicated, the NAS will now bring
up a control connection if none existed before, and the NAS and tunnel
server will bring up the call. At this point, data will begin to flow
through the tunnel. The NAS will typically employ LCP forwarding,
although it is also possible for the tunnel server to renegotiate LCP.
If LCP renegotiation is to be permitted, the NAS SHOULD NOT send an
Aboba & Zorn Standards Track [Page 4]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
LCP CONFACK completing LCP negotiation. Rather than sending an LCP
CONFACK, the NAS will instead send an LCP Configure-Request packet,
described in [6]. The Client MAY then renegotiate LCP, and from that
point forward, all PPP packets originated from the client will be
encapsulated and sent to the tunnel server.
Since address assignment will occur at the tunnel server, the client
and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will
occur between the client and the tunnel server.
7.1.2. NAS authentication with RADIUS reply forwarding
With this approach, authentication and authorization occurs once at
the NAS and the RADIUS reply is forwarded to the tunnel server. This
approach disallows network access for unauthorized NAS users; does not
require trust between the NAS and tunnel server; and allows for
accounting to be done at both ends of the tunnel. However, it also
requires that both ends share the same secret with the RADIUS server,
since that is the only way that the tunnel server can check the RADIUS
Access-Reply.
In this approach, the tunnel server will share secrets with all the
NASes and associated RADIUS servers, and there is no provision for LCP
renegotiation by the tunnel server. Also, the tunnel server will need
to know how to handle and verify RADIUS Access-Accept messages.
While this scheme can be workable if the reply comes directly from a
RADIUS server, it would become unmanageable if a RADIUS proxy is
involved, since the reply would be authenticated using the secret
shared by the client and proxy, rather than the RADIUS server. As a
result, this scheme is impractical.
7.1.3. Tunnel server authentication
In this scheme, authentication and authorization occurs once at the
tunnel server. This requires that the NAS determine that the user
needs to be tunneled (through RADIUS or NAS configuration). Where
RADIUS is used, the determination can be made using one of the follow-
ing methods:
Telephone-number based authentication
UserID
7.1.3.1. Telephone-number based authentication
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 or to provide tunnel attributes based on the Calling-Station-Id
or Called-Station-Id. Similarly, in L2TP the tunnel server MAY choose
Aboba & Zorn Standards Track [Page 5]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
to reject or accept the call based on the Dialed Number and Dialing
Number included in the L2TP Incoming-Call-Request packet sent by the
NAS. Accounting can also take place based on the Calling-Station-Id
and Called-Station-Id.
RADIUS as defined in [1] requires that an Access-Request packet con-
tain a User-Name attribute as well as either a CHAP-Password or User-
Password attribute, which must be non-empty. To satisfy this require-
ment the Called-Station-Id or Calling-Station-Id MAY be furnished in
the User-Name attribute and a dummy value MAY be used in the User-
Password or CHAP-Password attribute.
In the case of telephone-number based authentication, a typical initi-
ation sequence looks like this:
Client and NS: Call Connected
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP negotiation
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
The process begins with an incoming call to the NAS. If configured for
telephone-number based authentication, the NAS sends a RADIUS Access-
Request containing the Calling-Station-Id and the Called-Station-Id
attributes. The RADIUS server will then respond with a RADIUS Access-
Accept or Access-Reject.
The NAS MUST NOT begin PPP authentication before bringing up the tun-
nel. If timing permits, the NAS MAY bring up the tunnel prior to
beginning LCP negotiation with the peer. If this is done, then LCP
will not need to be renegotiated between the peer and tunnel server,
nor will LCP forwarding need to be employed.
If the initial telephone-number based authentication is unsuccessful,
the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS
MUST send an LCP-Terminate and disconnect the user.
In the case where tunnel attributes are included in the RADIUS Access-
Accept, and an L2TP tunnel is indicated, the NAS will now bring up a
control connection if none existed before. This is accomplished by
sending an L2TP Start-Control-Connection-Request message to the tunnel
server. The tunnel server will then reply with an L2TP Start-Control-
Connection-Reply. If this message indicates an error, or if the con-
trol connection is terminated at any future time, then the NAS MUST
send an LCP-Terminate and disconnect the user.
The NAS will then send an L2TP Incoming-Call-Request message to the
tunnel server. Among other things, this message will contain the Call
Aboba & Zorn Standards Track [Page 6]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
Serial Number, which along with the NAS-IP-Address and Tunnel-Server-
Endpoint is used to uniquely identify the call. The tunnel server will
reply with an L2TP Incoming-Call-Reply message. If this message indi-
cates an error, then the NAS MUST send an LCP-Terminate and disconnect
the user. If no error is indicated, the NAS then replies with an L2TP
Incoming-Call-Connected message.
At this point, data can begin to flow through the tunnel. If LCP nego-
tiation had been begun between the NAS and the client, then LCP for-
warding may be employed, or the client and tunnel server will now
renegotiate LCP and begin PPP authentication. Otherwise, the client
and tunnel server will negotiate LCP for the first time, and then move
on to PPP authentication.
If a renegotiation is required, at the time that the renegotiation
begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP
negotiation, and the client and NAS MUST NOT have begun NCP negotia-
tion. Rather than sending an LCP CONFACK, the NAS will instead send an
LCP Configure-Request Packet, described in [6]. 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, and LCP renegotiation is
required, the NAS MAY in its initial setup notification include a copy
of the LCP CONFACKs sent in each direction which completed LCP negoti-
ation. The tunnel server MAY then use this information to avoid an
additional LCP negotiation. With L2TP, the initial setup notification
can also include the authentication information required to allow the
tunnel server to authenticate the user and decide to accept or decline
the connection. However, in telephone-number based authentication, PPP
authentication MUST NOT occur prior to the NAS bringing up the tunnel.
As a result, L2TP authentication forwarding MUST NOT be employed.
In performing the PPP authentication, the tunnel server can access its
own user database, or alternatively can send a RADIUS Access-Request.
The latter approach is useful in cases where authentication forwarding
is enabled, such as with roaming or shared use networks. In this case,
the RADIUS and tunnel servers are under the same administration and
are typically located close together, possibly on the same LAN.
Therefore having the tunnel server act as a RADIUS client provides for
unified user administration. Note that the tunnel server's RADIUS
Access-Request is typically sent directly to the local RADIUS server
rather than being forwarded via a proxy.
The interactions involved in initiation of a compulsory tunnel with
telephone-number based authentication are summarized below. In order
to simplify the diagram that follows, we have left out the client.
However, it is understood that the client participates via PPP negoti-
ation, authentication and subsequent data interchange with the Tunnel
Server.
Aboba & Zorn Standards Track [Page 7]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
INITIATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call connected
Send RADIUS
Access-Request
with Called-Station-Id,
and/or Calling-Station-Id
LCP starts
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
7.1.3.2. User-Name
Since authentication will occur only at the tunnel-server, tunnel ini-
tiation must occur prior to user authentication at the NAS. As a
result, this scheme typically uses either the domain portion of the
userID or attribute-specific processing on the RADIUS server. Since
the user identity is never verified by the NAS, either the tunnel
server owner must be willing to be billed for all incoming calls, or
other information such as the Calling-Station-Id must be used to ver-
ify the user's identity for accounting purposes.
Aboba & Zorn Standards Track [Page 8]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
In attribute-specific processing RADIUS may be employed and an
attribute is used to signal tunnel initiation. For example, tunnel
attributes can be sent back if the User-Password attribute contains a
dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID
beginning with a special character ('*') could be used to indicate the
need to initiate a tunnel. When attribute-specific processing is
used, the tunnel server may need to renegotiate LCP.
Another solution involves using the domain portion of the userID; all
users in domain X would be tunneled to address Y. This proposal sup-
ports compulsory tunneling, but does not provide for user-based tun-
neling.
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 server, since it did not verify the identity via RADIUS. How-
ever, 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 busi-
ness relationship with the NAS owner. Thus this approach is incompati-
ble with roaming.
A typical initiation sequence involving use of the domain portion of
the userID looks like this:
Client and NAS: Call Connected
Client and NAS: PPP LCP negotiation
Client and NAS: Authentication
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP re-negotiation
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
The process begins with an incoming call to the NAS, and the PPP LCP
negotiation between the Client and NAS. The authentication process
will then begin and based on the domain portion of the userID, the NAS
will now bring up a control connection if none existed before, and the
NAS and tunnel server will bring up the call. At this point, data MAY
begin to flow through the tunnel. The client and tunnel server MAY
now renegotiate LCP and will complete PPP authentication.
At the time that the renegotiation begins, the NAS SHOULD NOT have
sent an LCP CONFACK completing LCP negotiation, and the client and NAS
MUST NOT have begun NCP negotiation. Rather than sending an LCP CON-
FACK, the NAS will instead send an LCP Configure-Request packet,
described in [6]. The Client MAY then renegotiate LCP, and from that
point forward, all PPP packets originated from the client will be
encapsulated and sent to the tunnel server. In single authentication
compulsory tunneling, L2TP authentication forwarding MUST NOT be
Aboba & Zorn Standards Track [Page 9]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
employed. When LCP re-negotiation has been concluded, the NCP phase
will begin, and the tunnel server will assign an address to the
client.
In performing the PPP authentication, the tunnel server can access its
own user database, or it MAY send a RADIUS Access-Request. After the
tunnel has been brought up, the NAS and tunnel server can start
accounting.
The interactions are summarized below.
INITIATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
Authentication
phase starts
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
ENDIF
IF no control
connection exists
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
7.2. Dual authentication
In this scheme, authentication occurs both at the NAS and the tunnel
server. This requires the dial-up client to handle dual
Aboba & Zorn Standards Track [Page 10]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
authentication, 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 dual authentication include support for authentication
and accounting at both ends of the tunnel; use of a single
userID/password pair via implementation of RADIUS on the tunnel net-
work server; no requirement for telephone-number based authentication,
or attribute-specific processing on the RADIUS server.
Dual authentication allows for accounting records to be generated on
both the NAS and tunnel server ends, making auditing possible. Also
the tunnel endpoint does not need to have an account relationship with
the NAS owner, making this approach compatible with roaming.
A disadvantage of dual authentication is that unless LCP forwarding is
used, LCP will need to be renegotiated; some clients do not support it
at all, and others only support only a subset of the dual authentica-
tion combinations. Feasible combinations include PAP/PAP(token),
PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, CHAP/EAP, EAP/CHAP, and
EAP/EAP. EAP is described in [5].
In the case of a dual authentication, a typical initiation sequence
looks like this:
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: 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 Tunel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
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 containing tunnel attributes.
In the case where an L2TP tunnel is indicated, the NAS will now bring
up a control connection if none existed before, and the NAS and tunnel
server will bring up the call. At this point, data MAY begin to flow
through the tunnel. The client and tunnel server MAY now renegotiate
LCP and go through another round of PPP authentication. At the time
that this renegotiation begins, the NAS SHOULD NOT have sent an LCP
CONFACK completing LCP negotiation, and the client and NAS MUST NOT
have begun NCP negotiation. Rather than sending an LCP CONFACK, the
NAS will instead send an LCP Configure-Request packet, described in
Aboba & Zorn Standards Track [Page 11]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
[6]. The Client MAY then renegotiate LCP, and from that point for-
ward, all PPP packets originated from the client will be encapsulated
and sent to the tunnel server. When LCP re-negotiation has been con-
cluded, the NCP phase will begin, and the tunnel server will assign an
address to the client.
If L2TP is being used as the tunnel protocol, the NAS MAY in its ini-
tial setup notification include a copy of the LCP CONFACKs sent in
each direction which completed LCP negotiation. The tunnel server MAY
then use this information to avoid an additional LCP negotiation. With
L2TP, the initial setup notification can also include the authentica-
tion information required to allow the tunnel server to authenticate
the user and decide to accept or decline the connection. However, this
facility creates a vulnerability to replay attacks, and can create
problems in the case where the NAS and tunnel server authenticate
against different RADIUS servers. As a result, where user-based tun-
neling via RADIUS is implemented, L2TP authentication forwarding
SHOULD NOT be employed.
In performing the PPP authentication, the tunnel server can access its
own user database, or it MAY send a RADIUS Access-Request. After the
tunnel has been brought up, the NAS and tunnel server can start
accounting.
The interactions involved in initiation of a compulsory tunnel with
dual authentication are summarized below.
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
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Conection-Reply
to NAS
Aboba & Zorn Standards Track [Page 12]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
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
ENDIF
8. Termination sequence
The tear down of a compulsory tunnel involves an interaction between
the client, NAS and Tunnel Server. This interaction is virtually iden-
tical regardless of whether telephone-number based authentication,
single authentication, or dual authentication is being used. In any
of the cases, the following events occur:
Tunnel Server to NAS: L2TP Call-Clear-Request (optional)
NAS to Tunnel Server: L2TP Call-Disconnect-Notify
Tunnel termination can occur due to a client request (PPP termina-
tion), a tunnel server request (Call-Clear-Request), or a line problem
(call disconnect).
In the case of a client-requested termination, the tunnel server MUST
terminate the PPP session. The tunnel server MUST subsequently send a
Call-Clear-Request to the NAS. The NAS MUST then send a Call-Discon-
nect-Notify message to the tunnel server, and will disconnect the
call.
The NAS MUST also respond with a Call-Disconnect-Notify message and
disconnection if it receives a Call-Clear-Request from the tunnel
server without a client-requested termination.
In the case of a line problem or user hangup, the NAS MUST send a
Call-Disconnect-Notify to the tunnel server. Both sides will then tear
down the call.
The interactions involved in termination of a compulsory tunnel are
summarized below. In order to simplify the diagram that follows, we
have left out the client. However, it is understood that the client
MAY participate via PPP termination and disconnection.
Aboba & Zorn Standards Track [Page 13]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
TERMINATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
IF user disconnected
send
Call-Disconnect-Notify
message to tunnel server
Tear down the call
stop accounting
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
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 compulsory tunnels.
9.1. Distinct userIDs
If distinct RADIUS servers are being used, it is likely that distinct
userID/password pairs will be required to complete the RADIUS and tun-
nel authentications. One pair will be used in the initial PPP authen-
tication with the NAS, and the second pair will be used for authenti-
cation at the tunnel server.
This has implications if the NAS attempts to forward authentication
information to the tunnel server in the initial setup notification.
Since the userID/password pair used for tunnel authentication is dif-
ferent 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.
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. Rather than putting up an error message indicat-
ing an authentication failure, it is preferable to present a dialog
Aboba & Zorn Standards Track [Page 14]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
requesting the tunnel userID/password combination.
A similar issue arises when extended authentication methods are being
used, as is enabled by EAP, described in [5]. In particular, when one-
time passwords or cryptographic calculators are being used, different
passwords will be used for the first and second authentications. Thus
the user will need to be prompted to enter the second password.
9.2. Multilink PPP issues
It is possible for the two RADIUS servers to return different Port-
Limit attributes. For example, it is conceivable that the NAS RADIUS
server will only grant use of a single channel, while the tunnel
RADIUS server will grant more than one channel. In this case, the cor-
rect behavior is for the tunnel client to open a connection to another
NAS in order to bring up a multilink bundle on the tunnel server. The
client MUST NOT indicate to the NAS that this additional link is being
brought up as part of a multilink bundle; this will only be indicated
in the subsequent negotiation with the tunnel server.
It is also conceivable that the NAS RADIUS server will allow the
client to bring up multiple channels, but that the tunnel RADIUS
server will allow fewer channels than the NAS RADIUS server. In this
case, the client should terminate use of the excess channels.
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. The userID is subsequently relayed by the NAS to
the RADIUS server in the User-Name attribute, as part of the RADIUS
Access-Request.
Similarly, [2] refers to use of the userID in determining the tunnel
endpoint, although it does not provide guidelines for how RADIUS or
tunnel routing is to be accomplished. Thus the possibility of con-
flicting interpretations exists.
The use of RADIUS in provisioning of compulsory tunneling relieves the
userID from having to do double duty. Rather than being used both for
routing of the RADIUS authentication/authorization request as well for
determination of the tunnel endpoint, the userID is now used solely
for routing of RADIUS authentication/authorization requests. Tunnel
attributes returned in the RADIUS Access-Response are then used to
determine the tunnel endpoint.
Since the framework described in this document allows both ISPs and
tunnel users to authenticate users as well as to account for resources
consumed by them, and provides for maintenance of two distinct
userID/password pairs, this scheme provides a high degree of
Aboba & Zorn Standards Track [Page 15]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
flexibility. Where RADIUS proxies and tunneling are employed, it is
possible to allow the user to authenticate with a single userID/pass-
word pair at both the NAS and the tunnel endpoint. This is accom-
plished by routing the NAS RADIUS Access-Request to the same RADIUS
server used by the tunnel server.
11. References
[1] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authen-
tication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[2] A. Valencia, K. Hamzeh, A. Rubens, T. Kolar, M. Littlewood, W.
Townsley, J. Taarud, G. Pall, B. Palter, W. Verthein. "Layer Two Tun-
neling Protocol L2TP." Internet draft (work in progress), draft-ietf-
pppext-l2tp-11.txt, September 1998.
[3] Zorn, G., Leifer, D., Rubens, A., and J. Shriver, "RADIUS
Attributes for Tunnel Protocol Support", Internet draft (work in
progress), draft-ietf-radius-tunnel-auth-06.txt, September 1998.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol
(EAP)", RFC 2284, March 1998.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 51,
RFC 1661, July 1994.
12. Security considerations
Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS
server may be processed by one or more proxies prior to being received
by the NAS. In order to ensure that tunnel attributes arrive without
modification, intermediate RADIUS proxies forwarding the Access-Reply
MUST NOT modify tunnel attributes. If the RADIUS proxy does not sup-
port tunnel attributes, then it MUST send an Access-Reject to the NAS.
This is necessary to ensure that the user is only granted access if
the services requested by the RADIUS server can be provided.
Since RADIUS tunnel attributes are used for compulsory tunneling,
address assignment is handled by the tunnel server rather than the
NAS. As a result, if tunnel attributes are present, the NAS MUST
ignore any address assignment attributes sent by the RADIUS server. In
addition, the NAS and client MUST NOT begin NCP negotiation, since
this could create a time window in which the client will be capable of
sending packets to the transport network, which is not permitted in
compulsory tunneling.
Aboba & Zorn Standards Track [Page 16]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
13. Acknowledgements
Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions
of this problem space, and to Allan Rubens of Ascend and Bertrand
Buclin of AT&T Labs Europe for his comments on this document.
14. Chair's Address
The RADIUS Working Group can be contacted via the current chair:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 510-426-0770
E-Mail: cdr@livingston.com
15. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425-936-6605
EMail: bernarda@microsoft.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425-703-1559
EMail: glennz@microsoft.com
16. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other Inter-
net organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English. The limited
Aboba & Zorn Standards Track [Page 17]
INTERNET-DRAFT L2TP Compulsory Tunneling via RADIUS 9 October 1998
permissions granted above are perpetual and will not be revoked by the
Internet Society or its successors or assigns. This document and the
information contained herein is provided on an "AS IS" basis and THE
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR-
RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
17. Expiration Date
This memo is filed as <draft-ietf-radius-tunnel-imp-04.txt>, and
expires May 1, 1999. n
Aboba & Zorn Standards Track [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-22 07:53:36 |