RADIUS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
Category: Standards Track Glen Zorn
<draft-ietf-radius-tunnel-imp-03.txt> Microsoft
26 July 1997
Implementation of PPTP/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 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-03.txt> and expires February 1, 1998. Please
send comments to the authors.
2. Abstract
This document discusses implementation issues arising in the provi-
sioning of compulsory 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. Implementation issues
encountered with other tunneling protocols are left to separate docu-
ments.
3. Terminology
Voluntary Tunneling
In voluntary tunneling, a tunnel is created by the user,
typically via use of a tunneling client.
Compulsory Tunneling
In compulsory tunneling, a tunnel is created without any
action from the user and without allowing the user any
choice.
Aboba & Zorn [Page 1]
INTERNET-DRAFT 26 July 1997
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
capaility 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
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
Aboba & Zorn [Page 2]
INTERNET-DRAFT 26 July 1997
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 speci-
fication.
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
Aboba & Zorn [Page 3]
INTERNET-DRAFT 26 July 1997
"unconditionally compliant"; one that satisfies all the MUST and MUST
NOT requirements but not all the SHOULD or SHOULD NOT requirements for
its protocols is said to be "conditionally compliant."
5. 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
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
and to transfer accounting data from the NAS to the RADIUS accounting
server; those attributes are defined in [7].
5.1. Tunneling attributes
As described in [7], provisioning of compulsory tunneling with RADIUS
requires no new RADIUS messages, and implementation of five new RADIUS
attributes: Tunnel-Type, Tunnel-Medium-Type, Acct-Tunnel-Client-End-
point, Tunnel-Server-Endpoint, and Acct-Tunnel-Connection-Id.
The Tunnel-Type attribute indicates the tunneling protocol(s) to be
used (PPTP, L2F, L2TP, ATMP, VTP, IPSEC AH, IP-IP). It MAY be included
in Access-Request, Access-Accept, and Access-Challenge packets.
The Tunnel-Medium-Type Attribute indicates which transport medium to
use (IP, X.25, ATM, Frame Relay) when creating a tunnel for those pro-
tocols (such as L2TP) that can operate over multiple transports.
It MAY be included in in Access-Request, Access-Accept, and Access-
Challenge packets.
Aboba & Zorn [Page 4]
INTERNET-DRAFT 26 July 1997
Acct-Tunnel-Client-Endpoint contains the address of the NAS end of the
tunnel. It SHOULD be included in Accounting-Request packets which
contain Acct-Status-Type attributes with values of either Start or
Stop. This Attribute, along with the Tunnel-Server-Endpoint and
Acct-Tunnel-Connection-ID attributes, may be used to provide a glob-
ally unique means to identify a tunnel for accounting purposes.
Tunnel-Server-Endpoint indicates the address of the server end of the
tunnel. It SHOULD be included in Accounting-Request packets which
contain Acct-Status-Type attributes with values of either Start or
Stop.
Acct-Tunnel-Connection-ID indicates the identifier assigned to the
call. It SHOULD be included in Accounting-Request packets which
contain Acct-Status-Type attributes with values of either Start or
Stop.
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 under
compulsory tunneling.
5.2. Advantanges of RADIUS-based compulsory tunneling
The use of RADIUS in provisioning of compulsory tunnels has several
advantages. These include:
User-based tunneling
Auditing capabilities
Telephone-number based authentication and accounting
Single or dual authentication
5.2.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
Aboba & Zorn [Page 5]
INTERNET-DRAFT 26 July 1997
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
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.
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.
5.3. 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.
The Acct-Tunnel-Client-Endpoint and Acct-Tunnel-Connection-ID
attributes were introduced in [7] in order to support auditing. These
attributes are included within the RADIUS Accounting-Request packet
along with other attributes such as the User-Name and Tunnel-Server-
Endpoint. During accounting, the User-Name, Acct-Tunnel-Connection-
ID, Acct-Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes
uniquely identify the call. This allows the Accounting-Request sent by
the NAS to be reconciled with the corresponding Accounting-Request
sent by the tunnel server.
When implementing L2TP compulsory tunneling based on RADIUS, the NAS
MUST transmit the Call-Serial-Number in the Acct-Tunnel-Connection-ID
attribute in the Accounting-Request packet. In order to protect
against wrapping due to reboots or call volume, a 64-bit NTP timestamp
SHOULD be used as the Call-Serial Number. This feasible in L2TP since
the Call-Serial-Number string is of variable length.
When implementing PPTP compulsory tunneling based on RADIUS, the NAS
MUST transmit the Call-Serial-Number in the Acct-Tunnel-Connection-ID
Aboba & Zorn [Page 6]
INTERNET-DRAFT 26 July 1997
attribute in the Accounting-Request packet. While [6] states that the
Call-Serial-Number SHOULD be unique, this is not required. In addi-
tion, no method for determining the Call-Serial-Number is specified,
which leaves open the possibility of wrapping after a reboot.
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 aver-
age call is of 20 minutes duration, then the Call Serial Number will
wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.5 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 an
Acct-Tunnel-Connection-ID unique over an extended time period. It is
recommended that a 64-bit NTP timestamp be used for this purpose.
5.4. 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-Type, and Tunnel-Server-Endpoint
attributes based on the Calling-Station-Id or Called-Station-Id. Sim-
ilarly, in PPTP/L2TP the tunnel server MAY choose to reject or accept
the call based on the Dialed Number and Dialing Number included in the
PPTP/L2TP 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 Called-Station-Id.
5.5. Single or dual authentication
As described below, RADIUS-based compulsory tunneling can support a
variety of authentication configurations. These include single authen-
tication, where the user is authenticated at the 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 described above, or EAP-based authentication. When
dual-authentication is used, a number of modes are available, includ-
ing dual CHAP authentications; CHAP/EAP authentication;
CHAP/PAP(token) authentication; and EAP/EAP authentication, using the
same EAP type for both authentications.
PAP/PAP, CHAP/PAP and EAP/PAP dual authentications SHOULD NOT be used,
since these combinations involve transmission of cleartext passwords
over the Internet.
Aboba & Zorn [Page 7]
INTERNET-DRAFT 26 July 1997
6. Authentication alternatives in compulsory tunneling
There are several authentication alternatives for integration of
RADIUS and tunneling:
Authenticate at the NAS
Authenticate at the NAS, and forward the RADIUS reply
Authenticate at the tunnel network server
Authenticate at both the NAS and the tunnel network server
We discuss each of these alternatives in turn.
6.1. Authenticate at the NAS
With this approach, authentication and authorization (including tun-
neling information) occurs once, at the NAS. The advantages of this
approach are that it disallows network access for unauthorized NAS
users; and allows RADIUS accounting to be used at the NAS. Disadvan-
tages are that it requires that the tunnel network server trust the
NAS, since no user authentication occurs on the tunnel network server
end of the tunnel. Another disadvantage is that this does not allow
LCP parameters to be re-negotiated by the tunnel network server. Also,
due to the lack of user authentication, accounting cannot take place
at the tunnel network server with strong assurance that the correct
party is being billed. As a result, it does not appear that this
scheme can be practically employed.
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 is the only way that the tunnel network server could check
the RADIUS reply.
In this approach, the tunnel network server MUST share secrets with
all the NASes and associated RADIUS servers, and there is no provision
for LCP renegotiation by the tunnel network server. Also, the tunnel
network server MUST 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, it does not appear that this scheme can be practically
employed.
Aboba & Zorn [Page 8]
INTERNET-DRAFT 26 July 1997
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 RADIUS or NAS configuration). Where
RADIUS is used, the determination can be made using one of the follow-
ing methods:
Telephone-number based authentication
User-Name
EAP Identity
6.3.1. Telephone-number based authentication
Where telephone-number based authentication is used, the Calling-Sta-
tion-Id or Called-Station-Id attributes included in the RADIUS Access-
Request are used to determine whether the call will be accepted or
rejected, and if accepted, where the user is to be tunneled. Where
telephone-number based authentication is used, the User-Name and User-
Password or CHAP-Password attributes need not be present.
In cases where telephone-number authentication may be employed,
accounting may be accomplished on the NAS side via the Calling-Sta-
tion-Id or Called-Station-Id, and on the tunnel server side, via the
userID. Thus this scheme is capable of providing both authentication
and accounting, and appears practical to implement.
6.3.2. User-Name
Where the User-Name attribute is present, RADIUS as defined in [3]
requires that either a CHAP-Password or User-Password attribute be
present in an Access-Request message, as well as requiring that the
password be non-empty. Thus, this scheme either requires attribute-
specific processing on the RADIUS server, or addition of an "Autho-
rize-Only" 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 the userID with some special character ('*') if he wanted
to be tunneled. This particular solution does not support compulsory
tunneling. Another solution involves keying on the domain portion of
the userID; all users in domain X would be tunneled to address Y.
This proposal supports compulsory tunneling, but does not provide for
user-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].
Aboba & Zorn [Page 9]
INTERNET-DRAFT 26 July 1997
Note that when either attribute-specific processing or an authorize-
only message is used, the tunnel network server would need to renego-
tiate 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 ver-
ify the identity via RADIUS. However, in order for that to be of any
use in accounting, the tunnel endpoint needs to have an account rela-
tionship 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 nullifies many
of the benefits of roaming. Due to these difficulties, it does not
appear that this scheme can be practically employed.
6.3.3. EAP Identity
Where EAP is used as described in [11], the NAS may include an EAP-
Message/Identity attribute in the RADIUS Access-Request. Based on the
Identity included in the Access-Request, the RADIUS server may send
tunneling attributes within the RADIUS Access-Challenge packet. The
NAS can then set up the tunnel and EAP authentication may continue
between the client and the tunnel server. This method avoids having to
use attribute-specific processing or an authorize-only message.
However, in this case, the EAP identity is never verified by the NAS,
and so 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 verify the user's identity for accounting purposes.
Where either of these conditions holds true, this scheme may be prac-
tically employed.
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 telephone-number based authentica-
tion, use of EAP, 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
Aboba & Zorn [Page 10]
INTERNET-DRAFT 26 July 1997
the NAS owner. Thus this scheme is compatible with roaming. Disadvan-
tages are that unless LCP forwarding is used, LCP will need to be
renegotiated, and that dual authentications are required.
The use of dual authentication can be complex, since some clients do
not support it at all, and others only support only a subset of the
dual authentication combinations. Feasible combinations include
PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP,
CHAP/EAP, EAP/CHAP, and EAP/EAP. Assuming that the required dual
authentication capabilities are supported, this scheme may be practi-
cally employed.
7. Telephone-number based authentication
7.1. Initiation sequence
In the case of telephone-number based authentication, a typical initi-
ation sequence looks like this:
Client and NAS: Call Connected
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/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 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
NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
RADIUS Server to NAS: RADIUS Accounting-Response
Tunnel Server to RADIUS Server: RADIUS Accounting-Request
with Acct-Status-Type=Start (Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Response
The process begins with an incoming call to the NAS. If configured for
telephone-number based authentication, the NAS MUST send a RADIUS
Access-Request containing the Calling-Station-Id and the Called-Sta-
tion-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 client. If this is done, then LCP
will not need to be renegotiated between the client and tunnel server.
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.
Aboba & Zorn [Page 11]
INTERNET-DRAFT 26 July 1997
In the case where tunnel attributes are included in the RADIUS Access-
Accept, and a PPTP/L2TP tunnel is indicated, the NAS will now bring up
a control connection if none existed before. The control connection
will be of the type indicated by Tunnel-Type, over the medium indi-
cated by Tunnel-Medium-Type, to the tunnel server indicated by Tunnel-
Server-Endpoint. This is accomplished by sending a PPTP/L2TP Start-
Control-Connection-Request message to the tunnel server. The tunnel
server will then with a PPTP/L2TP Start-Control-Connection-Reply. If
this message indicates an error, or if the control connection is ter-
minated at any future time, then the NAS MUST send an LCP-Terminate
and 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 NAS-IP-Address
and Tunnel-Server-Endpoint 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 send an LCP-Ter-
minate and disconnect the user. If no error is indicated, the NAS then
replies with a PPTP/L2TP Incoming-Call-Connected message.
At this point, data MAY begin to flow through the tunnel. If LCP nego-
tiation had been begun between the NAS and the client, the client and
tunnel server MAY 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 DOWN message. 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. 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 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.
Aboba & Zorn [Page 12]
INTERNET-DRAFT 26 July 1997
Therefore having the tunnel server act as a RADIUS client provides for
unified user administration. Other methods are also available, such as
use of LDAP, described in [12], by both the tunnel and RADIUS servers.
Note that the tunnel 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 packet with Acct-Status-Type=Start to a
RADIUS server. The Accounting-Request packet MUST include the follow-
ing attributes: Tunnel-Type, Tunnel-Medium-Type, Acct-Tunnel-Client-
Endpoint, Tunnel-Server-Endpoint, and Acct-Tunnel-Connection-Id. The
Accounting-Request packet MAY also include the Calling-Station-Id and
Called-Station-Id attributes.
The tunnel server can produce its own accounting records, or it MAY
send a RADIUS Accounting-Request packet with Acct-Status-Type=Start to
a local RADIUS server. In the latter case, the RADIUS Accounting-
Request packet MUST contain the following attributes: Tunnel-Type,
Tunnel-Medium-Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-End-
point, and Acct-Tunnel-Connection-Id.
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.
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 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
Aboba & Zorn [Page 13]
INTERNET-DRAFT 26 July 1997
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
Send RADIUS
Accounting-Request with
Acct-Status-Type=Start
(optional)
Send
RADIUS
Accounting-Response
Send a RADIUS
Accounting-Request message
with Acct-Status-Type=Start
containing
Tunnel-Type, Tunnel-Medium-Type,
Acct-Tunnel-Client-Endpoint,
Tunnel-Server-Endpoint,
Acct-Tunnel-Connection-Id,
Calling-Station-Id,
Called-Station-Id.
Send
RADIUS
Accounting-Response
ENDIF
7.2. EAP support
It is expected that the Extensible Authentication Protocol (EAP)
described in [13] will frequently be used along with telephone number-
based authentication and tunneling in order to provide additional
security. In this case, EAP authentication may be used in the tunnel
authentication only, using EAP code present on the NAS, or via support
of EAP within RADIUS described in [11]. In this case, the initiation
sequence will look like this:
Aboba & Zorn [Page 14]
INTERNET-DRAFT 26 July 1997
Client and NAS: Call Connected
Client and NAS: PPP LCP negotiation
NAS to RADIUS Server: RADIUS Access-Request
RADIUS server to NAS: RADIUS Access-Reply/Tunnel attributes
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: EAP authentication
Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start
RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message
Tunnel Server to Client: EAP-Request
Client to Tunnel Server: EAP-Response
Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message
RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success
Client and Tunnel Server: NCP negotiation
NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
RADIUS Server to NAS: RADIUS Accounting-Response
Tunnel Server to RADIUS Server: RADIUS Accounting-Request with
Acct-Status-Type=Start (Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Response
8. Single authentication
8.1. Initiation sequence
In the case of a single authentication compulsory tunnel, a typical
initiation sequence looks like this:
Client and NAS: Call Connected
Client and NAS: PPP LCP negotiation
Client and NAS: EAP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Challenge/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: EAP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Challenge/Access-Reject
Client and Tunnel Server: NCP negotiation
NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
RADIUS Server to NAS: RADIUS Accounting-Response
Tunnel Server to RADIUS Server: RADIUS Accounting-Request
with Acct-Status-Type=Start (Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Response
The process begins with an incoming call to the NAS, and the PPP LCP
negotiation between the Client and NAS. At this point, the NAS must
Aboba & Zorn [Page 15]
INTERNET-DRAFT 26 July 1997
offer EAP, and the Client must accept if the negotiation is to pro-
ceed. If the Client is incapable of authenticating via EAP, then the
NAS MUST send an LCP-Terminate and disconnect the user.
The NAS will now typically send an EAP-Request/Identity packet to the
Client, and the client will respond with an EAP-Response/MyId packet.
The NAS now sends an Access-Request/EAP-Message/EAP-Response/MyId
packet to the RADIUS server, which responds with an Access-Challenge
or an Access-Reject.
If single-authentication tunneling is to be carried out, the Access-
Challenge packet MUST contain the Tunnel-Type, Tunnel-Medium-Type, and
Tunnel-Server-Endpoint Attributes. The presence of tunneling
attributes in the Access-Challenge indicates to the NAS that a tunnel
MUST be brought up prior to continuation of the EAP conversation. As a
result, if the Access-Challenge contains an EAP-Message attribute,
then the NAS MUST NOT send the EAP-Request encapsulated in the EAP-
Message prior to bringing up the tunnel. Since after the tunnel is
brought up LCP will be renegotiated, EAP-Message attributes are effec-
tively ignored whenever the Access-Challenge also contains tunnel
attributes.
In the case where a PPTP/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 renego-
tiate 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 DOWN message. 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 authenti-
cation forwarding MUST NOT be employed.
If the tunnel server and NAS both are using the same RADIUS server,
the RADIUS server will respond to the tunnel server's Access-Request
with an Access-Challenge packet containing tunnel attributes and an
EAP-Message attribute, as before. On receiving the Access-Challenge
including tunnel attributes, the tunnel server will check whether the
tunnel matches the attributes returned by the RADIUS server; if so,
the tunnel attributes will be ignored, and the EAP-Request specified
in the EAP-Message attribute will be sent to the Client. If the tunnel
attributes do not match, then the tunnel server MUST disconnect the
call.
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 MAY start
Aboba & Zorn [Page 16]
INTERNET-DRAFT 26 July 1997
accounting.
The interactions involved in initiation of a compulsory tunnel with
single authentication are summarized below.
INITIATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
EAP authentication
phase starts
Send RADIUS
Access-Request
with EAP-Message/MyId
attribute
IF MyId is known,
send RADIUS
Access-Challenge with
Tunnel-Type,
Tunnel-Medium-Type,
Tunnel-Server-Endpoint,
EAP-Message (optional)
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 via EAP,
bring up IPCP,
start accounting
Send RADIUS
Aboba & Zorn [Page 17]
INTERNET-DRAFT 26 July 1997
Accounting-Request with
Acct-Status-Type=Start
(optional)
Send
RADIUS
Accounting-Response
Send a RADIUS
Accounting-Request message
with Acct-Status-Type=Start
containing
Tunnel-Type, Tunnel-Medium-Type,
Acct-Tunnel-Client-Endpoint,
Tunnel-Server-Endpoint, and
Acct-Tunnel-Connection-Id.
Send
RADIUS
Accounting-Response
ENDIF
9. Dual authentication
9.1. Initiation sequence
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: 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-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
RADIUS Server to NAS: RADIUS Accounting-Response
Tunnel Server to RADIUS Server: RADIUS Accounting-Request
with Acct-Status-Type=Start (Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Response
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. For users requiring mandatory
Aboba & Zorn [Page 18]
INTERNET-DRAFT 26 July 1997
tunneling, the Access-Accept MUST contain the the Tunnel-Type, Tunnel-
Medium-Type, and Tunnel-Server-Endpoint Attributes.
In the case where a PPTP/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 renego-
tiate 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 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. After the
tunnel has been brought up, the NAS and tunnel server MAY 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
Aboba & Zorn [Page 19]
INTERNET-DRAFT 26 July 1997
Send ACK with
Tunnel-Type,
Tunnel-Medium-Type,
Tunnel-Server-Endpoint,
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
Send RADIUS
Accounting-Request with
Acct-Status-Type=Start
(optional)
Send
RADIUS
Accounting-Response
Send a RADIUS
Accounting-Request message
with Acct-Status-Type=Start
containing
Tunnel-Type, Tunnel-Medium-Type,
Acct-Tunnel-Client-Endpoint,
Tunnel-Server-Endpoint, and
Acct-Tunnel-Connection-Id.
Send
RADIUS
Accounting-Response
ENDIF
Aboba & Zorn [Page 20]
INTERNET-DRAFT 26 July 1997
9.2. EAP support
It is expected that the Extensible Authentication Protocol (EAP)
described in [13] will frequently be used along with tunneling in
order to provide additional security. EAP authentication may be used
in the initial NAS authentication, in the tunnel authentication, or
both, with support of EAP within RADIUS described in [11]. In the
case where EAP authentication is carried out between the NAS and
client, the initiation sequence will look like this:
Client and NAS: PPP LCP negotiation
Client and NAS: EAP Authentication
NAS to RADIUS Server: RADIUS Access-Request/EAP-start
RADIUS server to NAS: RADIUS Access-Challenge/EAP-Message
NAS to Client: EAP-Request
Client to NAS: EAP-Response
NAS to RADIUS Server: RADIUS Access-Request/EAP-Message
RADIUS server to NAS: RADIUS Access-Accept/EAP-Message/EAP-Success
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-Accept/Access-Reject
Client and Tunnel Server: NCP negotiation
NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
RADIUS Server to NAS: RADIUS Accounting-Response
Tunnel Server to RADIUS Server: RADIUS Accounting-Request
With Acct-Status-Type=Start(Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Response
In the case where EAP authentication is carried out between the client
and tunnel server, the initiation sequence will look 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
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: EAP authentication
Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-start
RADIUS server to Tunnel Server: RADIUS Access-Challenge/EAP-Message
Tunnel Server to Client: EAP-Request
Client to Tunnel Server: EAP-Response
Tunnel Server to RADIUS Server: RADIUS Access-Request/EAP-Message
RADIUS server to Tunnel Server: RADIUS Access-Accept/EAP-Message/EAP-Success
Client and Tunnel Server: NCP negotiation
NAS to RADIUS Server: RADIUS Accounting-Request with Acct-Status-Type=Start
RADIUS Server to NAS: RADIUS Accounting-Response
Tunnel Server to RADIUS Server: RADIUS Accounting-Request with
Aboba & Zorn [Page 21]
INTERNET-DRAFT 26 July 1997
Acct-Status-Type=Start (Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Response
For the negotiations described above to succeed, the client must be
capable of renegotiating EAP with the tunnel server after an initial
authentication with the NAS.
10. Termination sequence
The tear down of a compulsory tunnel involves an interaction between
the client, NAS, Tunnel Server, and RADIUS Accounting server. This
interaction is virtually identical regardless of whether telephone-
number based authentication, single authentication, or dual authenti-
cation is being used. In any of the cases, the following events occur:
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 with Acct-Status-Type=Stop
RADIUS Server to NAS: RADIUS Accounting-Response
Tunnel Server to RADIUS Server: RADIUS Accounting-Request
with Acct-Status-Type=Stop(Optional)
RADIUS Server to Tunnel Server: RADIUS Accounting-Response
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.
After call tear down is complete, if RADIUS accounting is being used
then the NAS MUST send a RADIUS Accounting-Request with Acct-Status-
Type=Stop packet to a RADIUS accounting server. The Accounting-
Request packet MUST include the following attributes: Tunnel-Type,
Tunnel-Medium-Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-End-
point, and Acct-Tunnel-Connection-Id.
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 with Acct-Status-
Type=Stop to a RADIUS accounting server. The Accounting-Request packet
MUST contain the following attributes: Tunnel-Type, Tunnel-Medium-
Aboba & Zorn [Page 22]
INTERNET-DRAFT 26 July 1997
Type, Acct-Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, and Acct-
Tunnel-Connection-Id.
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.
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 with
Acct-Status-Type=Stop
(optional)
Send RADIUS
Accounting-Response
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 with
Acct-Status-Type=Stop
(optional)
Send RADIUS
Accounting-Response
Send a RADIUS
Accounting-Request message
with Acct-Status-Type=Stop
containing
Tunnel-Type, Tunnel-Medium-Type,
Acct-Tunnel-Client-Endpoint,
Tunnel-Server-Endpoint, and
Acct-Tunnel-Connection-Id.
Send RADIUS
Accounting-Response
ENDIF
Aboba & Zorn [Page 23]
INTERNET-DRAFT 26 July 1997
11. 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.
11.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 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 smart 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.
11.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.
Aboba & Zorn [Page 24]
INTERNET-DRAFT 26 July 1997
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.
12. 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, 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.
12.1. UserID convergence in user-based tunneling
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. The Tun-
nel-Server-Endpoint attribute returned in the RADIUS Access-Response
Is 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 flexibil-
ity. Where RADIUS proxies and tunneling are employed, it is possible
to allow the user to authenticate with a single userID/password pair
at both the NAS and the tunnel endpoint. This is accomplished by rout-
ing the NAS RADIUS Access-Request to the same RADIUS server used by
the tunnel server.
As described in [8], the recommended form for the user ID is
userID@realm, i.e. fred@bigco.com.
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.
Aboba & Zorn [Page 25]
INTERNET-DRAFT 26 July 1997
14. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." Work in progress, draft-ietf-roamops-imprev-04.txt,
Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, June, 1997.
[2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." Internet draft
(work in progress), draft-ietf-roamops-roamreq-05.txt, Microsoft,
July, 1997.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April,
1997.
[5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J.
Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." ."
Internet draft (work in progress), draft-ietf-pppext-l2tp-04.txt,
Ascend Communications, Microsoft, Copper Mountain Networks, U.S.
Robotics, June, 1997.
[6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little.
"Point-to-Point Tunneling Protocol -- PPTP." ." Internet draft (work
in progress), draft-ietf-pppext-pptp-02.txt, Ascend Communications,
Microsoft, Copper Mountain Networks, U.S. Robotics, July, 1997.
[7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." Inter-
net draft (work in progress), draft-ietf-radius-tunnel-auth-02.txt,
Microsoft, July, 1997.
[8] B. Aboba, M. A. Beadles. "The Network Access Identifier." Inter-
net draft (work in progress), draft-ietf-roamops-nai-06.txt,
Microsoft, CompuServe, July, 1997.
[9] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.
[10] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress,
draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
[11] P. Calhoun, A.C. Rubens, B. Aboba. "Extensible Authentication
Protocol Support in RADIUS." Internet draft (work in progress), draft-
ietf-radius-eap-02.txt, US Robotics Access Corp., Merit Network,
Microsoft, May, 1997.
[12] M. Wahl, T. Howes, S. Kille. "Lightweight Directory Access Pro-
tocol (v3)." ." Internet draft (work in progress), draft-ietf-asid-
ldapv3-protocol-04.txt, Critical Angle Inc., Netscape, Isode Limited,
March, 1997.
[13] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication
Protocol (EAP)." ." Internet draft (work in progress), draft-ietf-
Aboba & Zorn [Page 26]
INTERNET-DRAFT 26 July 1997
pppext-eap-auth-02.txt, Merit Network, Inc., June, 1996.
15. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-703-1559
EMail: glennz@microsoft.com
Aboba & Zorn [Page 27]
