Dynamic Compulsory Tunneling with RADIUS and PPTP (Windows NT Server 4.0)

Dynamic Compulsory Tunneling with RADIUS and PPTP

Many of the most interesting applications of the Point-to-Point Tunneling Protocol (PPTP) involve dial-up network access. The most popular means of authorizing dial-up network users today is through the RADIUS protocol.

On This Page

Introduction
A Taxonomy of PPTP Tunnels
RADIUS: A Brief Overview
Integrating RADIUS and PPTP

Introduction

Many of the most interesting applications of PPTP involve dial-up network access. Some applications—such as the provision of secure access to corporate intranets via the Internet—are characterized by voluntary tunneling, where the PPTP tunnel is created at the request of the user for a specific purpose. Other potentially more compelling applications involve compulsory tunneling, where the tunnel is created automatically without any action from the user and, more importantly, without allowing the user any choice in the matter. 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 being subject to manual configuration. It makes sense to use RADIUS to centrally administer compulsive tunneling because RADIUS is widely deployed and was designed to carry this type of information. New RADIUS attributes are needed to carry tunneling information.

A Taxonomy of PPTP Tunnels

For the purposes of this paper, PPTP tunnels come in two basic flavors: compulsory (or mandatory) and voluntary (or non-mandatory). Within the compulsory category there are two classes: static and dynamic; the static tunnels can be divided again, into realm-based and automatic classifications.

Voluntary and Compulsory Tunnels

Both the method of their creation and the location of the client-side termination point of the tunnel are what differentiates compulsory tunnels from voluntary tunnels. Voluntary tunnels, as the name suggests, are created deliberately by an end user, and the client-side tunnel endpoint resides on the user's computer:

Figure 1: - Voluntary Tunneling

With voluntary tunneling, it is possible to simultaneously open a secure tunnel through the Internet (e.g., to gain access to a corporate intranet) and access other Internet hosts via basic TCP/IP protocols without tunneling. For example, suppose that Alice has a personal account with an Internet provider that she uses to telecommute. Alice could open a PPTP tunnel to her company's intranet and work on a quarterly report while downloading Usenet news from her ISP's NNTP server.

Compulsory tunnels are created without the end user's consent, and possibly without their knowledge. The client-side termination point of a compulsory tunnel typically resides on a remote access server (RAS). All traffic originating from the end user's computer is forwarded over the PPTP tunnel by the RAS.

Figure 2: - Compulsory Tunneling

Although it might still be possible for the user of a compulsory tunnel to access services outside the Intranet, this access would be controlled by the administrators of the network where the PPTP server resides. Essentially, compulsory tunneling allows Internet access control. Voluntary tunnels place an increased computational burden on the tunnel user's computer, since it is required to process the tunneling protocol; voluntary tunnels also use more network bandwidth than compulsory tunnels. This is because PPTP allows multiple connections to be carried over a single tunnel.

In Figures 1 and 2, all of Chuck and Don's traffic can be forwarded over a single tunnel if it is destined for the same PPTP server. Alice and Bob's traffic must remain separate, however, even if it eventually ends up in the same place. On the other hand, the combination of compulsory tunnels with large amounts of Internet-bound traffic both slows down the Internet from the user's point of view and may require greater provision of egress bandwidth on the corporate intranet. Voluntary tunnels are often used to provide privacy and integrity protection for intranet traffic being sent over the Internet. Compulsory tunnels may be used in this way too (although the initial leg of the connection is outside the tunnel) but they offer access control as well.

Static Compulsory Tunnels

Static tunnel configurations typically require either dedicated equipment (automatic tunnels) or manual configuration (realm-based tunnels). Automatic tunneling has the advantage of using the existing Internet infrastructure to carry intranet traffic, but may require the provisioning of dedicated local access lines and network access equipment, with the associated costs. For example, users might be required to call a specific telephone number in order to connect to a RAS that would automatically tunnel all connections to a particular PPTP server. In realm-based tunneling schemes, the remote access server examines a portion of the user's name (called a realm) to decide where to tunnel the traffic associated with that user.

For example, users in the conglomo.com realm would be tunneled to one destination, while those in the bigco.com realm would be sent somewhere else. Realm-based tunneling is relatively simple to implement, does not require dedicated equipment and (after the initial configuration is complete) has low overhead; however, configuration changes may be expensive and time-consuming. In addition, all traffic for the same realm is tunneled to the same destination, which may be undesirable.

Dynamic Compulsory Tunnels

Dynamic tunnels offer the greatest flexibility of any compulsory tunneling scheme. This is because the choice of tunnel destination is made on a per-user basis, at the time that the user connects to the RAS. Users from the same realm may be tunneled to different destinations depending upon parameters such as user name, department, RAS location, and even the time of day. Dynamic tunneling requires few (if any) modifications to RAS configurations and can be administered from a central site. It is appropriate for implementation on a shared-use network, since neither dedicated-access devices nor phone lines are needed. The down side is that dynamic tunneling requires the RAS to have the ability to obtain session configuration data "on the fly." Fortunately, there are several ways to do this, the most widely supported being through the RADIUS protocol.

RADIUS: A Brief Overview

The Remote Authentication Dial In User Service (RADIUS) protocol is currently the most popular method for managing remote user authentication and authorization. RADIUS is a very light-weight, UDP-based protocol.

The following excerpt is from RFC 2058, Remote Authentication Dial In User Service (RADIUS), Rigney et al, January 1997:

"Managing dispersed serial line and modem pools for large numbers of users can create the need for significant administrative support. Since modem pools are by definition a link to the outside world, they require careful attention to security, authorization and accounting. This can be best achieved by managing a single 'database' of users, which allows for authentication (verifying user name and password) as well as configuration information detailing the type of service to deliver to the user (for example, SLIP, PPP, telnet, rlogin).

Key features of RADIUS are:

Client/Server Model

A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response which is returned.

RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user.

A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.

Network Security

Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password.

Flexible Authentication Mechanisms

The RADIUS server can support a variety of methods to authenticate a user. When it is provided with the user name and original password given by the user, it can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms.

Extensible Protocol

All transactions are comprised of variable length Attribute-Length-Value 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol.

Because RADIUS is designed to carry authorization data and is widely deployed, it seems reasonable to use it as a means to transfer the information required to set up dynamic tunnels.

Integrating RADIUS and PPTP

In order to implement dynamic compulsory tunnels using RADIUS, two things are necessary:

1. RADIUS attributes must defined to carry the data needed to create a new tunnel or use an existing tunnel.

2. an implementation strategy must be devised.

RADIUS Attributes

The information needed to set up a new tunneled connection is as follows:

• the tunnel protocol to be used (i.e., PPTP, L2TP, etc.)

• the address of the desired tunnel server (TS)

• the tunnel transport medium to be used. (Some tunneling protocols (such as L2TP) can operate over a number of different mediums such as X.25, Asynchronous Transfer Mode (ATM), as well as over IP.

Attributes containing the above information are sufficient to start a new tunnel (if necessary) and to open a connection within the tunnel. Other attributes may be desirable (e.g., the tunnel protocol client's password for L2TP) but are not required. To enable the use of RADIUS accounting1Rigney, January 1997. to track network usage, a couple of more items are needed:

• the address of the tunnel client (i.e., the NAS)

• a unique identifier for the tunneled connection

These last two, in conjunction with the first three, allow any tunnel connection to be identified in a globally unique manner. This unique identification is necessary for both accounting and auditing purposes. For more information about these attributes, including format and data types, please see RADIUS Attributes for Tunnel Protocol Support, Zorn, November 1996, a work in progress, published as draft-ietf-radius-tunnel-auth-00.txt. This and other Internet Drafts are available from various sites on the Internet, including ftp://ftp.isi.edu/internet-drafts.

Implementation Strategy

Defining the RADIUS attributes needed to support dynamic tunneling is fairly straightforward. Deciding how to use the attributes in the real world is a bit trickier, since there are many options. For example, what entity should authenticate the user, and when? This question turns out to be fairly controversial.

Authentication Options

There are at least three possible options for user authentication and authorization with respect to dynamic compulsory tunnels:

1. Authenticate and receive authorization (including tunneling information) once, at the RAS end of the tunnel

2. Authenticate (and receive authorization information) once, at the RAS end of the tunnel, and somehow forward the RADIUS reply to the remote end of the tunnel

3. Authenticate on both ends of the tunnel

The trust model for the first option is unfortunate, since it requires the operator of the tunnel server to trust the operator of the NAS to disallow inappropriate access to the network. The second option has an appropriate trust model, but is unlikely to scale well, due to the way RADIUS authenticates reply messages. The third option is robust, is likely to scale well, and allows authenticated accounting to take place at both ends of the tunnel. If a RADIUS proxy server2 is used, option three also supports the use of a single username and password at both ends. The chain of events in the initiation of a tunnel connection using option three might look like this:

Figure 3: – Authentication using Option 3

In Figure 3, the remote user dials into the RAS and enters his or her password as part of the PPP authentication sequence (1). The RAS uses RADIUS to check the password and receives attributes (via a local RADIUS Proxy Server) that tell it to tunnel the user to a particular PPTP server (2-5). The RAS obediently opens a tunneled connection to the specified PPTP server (creating a tunnel if necessary). The PPTP server re-authenticates the user (6), checking the password against the same RADIUS server as used in the initial exchange (7, 8). In this case, we assume that the operator of the RAS and RADIUS Proxy (say, BigISP) has a pre-existing business relationship with the operator of the PPTP and RADIUS servers (say, Conglomo). is allows the user to use a single username/password pair to gain access access to both ends of the tunnel. Other scenarios are possible; for more information, see Implementation of Mandatory Tunneling via RADIUS, Aboba and Zorn, November 1996; work in progress, published as draft-aboba-radius-tunnel-imp-01.txt.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

The names of companies, products, people, characters, and/or data mentioned herein are fictious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

0197 Part no. 098-68648