There are several methods to validate the authentication of the client attempting to access the network. One is to use the internal client database on the VPN switch. This approach will usually take the least effort to implement. However, as your VPN grows into multiple switches to handle increased load and provide backup capability, you will need to consider either copying the database to the other VPN switches or employing another method of client validation.

Using RADIUS

RADIUS is one method to centralize client administration for either single or multiple VPN switches. RADIUS, which was written by Steve Willens of Livingston Enterprises (now owned by Lucent Technologies), coordinates authentication and authorization information between a network access server (VPN switch) and a central authentication and authorization server (RADIUS server, RFC 2138).

Most, if not all, VPN switches provide the capability to authenticate clients first by accessing the switches' internal databases and then, if matches are not found, by accessing external RADIUS servers. Using a centralized RADIUS database for client administration has many benefits, but primarily it eliminates the need to manually keep multiple VPN switch databases in sync (which is almost impossible after users start changing their passwords). Implementing RADIUS will be appreciated by information security and network managers because it greatly simplifies their staffs' responsibilities and reduces the requirement for multiple switch updates every time a new client or switch change occurs. If you are using RADIUS in an existing RAS (remote-access service) environment, you should simply be able to add any RADIUS attributes necessary to support VPN for your environment without having to make any changes to your infrastructure.

Before we delve into implementing a RADIUS server on a VPN, it's worth taking a quick look at the various protocols used by VPNs, because selection of the protocol directly affects the VPN implementation. There are three protocols to consider: PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol) and IPSec (IP Security), though IPSec is technically a collection of protocols. The book Virtual Private Networking: A View From The Trenches, by Bruce Perlmutter with Jonathan Zarkower (Prentice Hall, 1999), provides a more detailed analysis of VPN protocols.

IPSec and Your VPN

As a Layer 3 tunneling protocol, IPSec has some advantages over PPTP and L2TP. IPSec comprises three elements: authentication, encryption and key management. AH (Authentication Header), detailed in RFC 1826, gives packet-level authentication, while payload encryption is provided by ESP (Encapsulation Security Protocol), from RFC 1827. IPSec ESP in tunnel mode can encapsulate an entire encrypted IP packet inside an outer IP packet. This makes IPSec a useful VPN protocol.

IPSec also doesn't dictate how to encrypt (giving switch vendors latitude to implement encryption as they see fit). This flexibility has led to the development of ASICs that let the VPN switches decrypt encoded IPSec packets much more quickly than by using software. IPSec also supports IP version 6 but not IPX. So if IPX is your network protocol, you will need an additional overhead layer to encapsulate it. IPSec also can provide added functionality, such as split tunneling (the ability to route traffic to either the corporate LAN or the Internet) and providing enhanced password management.

Complicating the selection of a VPN protocol standard is the fact that many VPN switch vendors choose different interpretations of the IETF's IPSec draft specifications. Work is being done in this area, but until IPSec is standardized, you are probably better off using a single vendor's products. This is not necessarily bad, however, because for a client to connect to your network, you have to ship a proprietary version of the IPSec client connection software. This adds an additional layer of protection, which may help sell the idea of a VPN to paranoid (and rightfully so) security directors.

Once a vendor and protocol for VPN have been selected, RADIUS can be implemented to validate client logon requests using PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol) or Microsoft's version of CHAP. PAP authentication requires the remote workstation to prove its identity before allowing data traffic. CHAP sends a challenge to the remote device, which encrypts the challenge value with a shared secret and returns the encrypted value with its name as a RADIUS return attribute. Both CHAP and PAP can be used. If the password matches the database, the IPSec tunnel is established.

There are, however, some potential problems with using RADIUS. It and the VPN switch have the ability to pass additional parameters called "attributes," which are values used to accept, reject or modify a user's request. Once a connection has been established, RADIUS client machines use access-attribute values to control aspects of the client connection (such as specifying the name of a place to be called back or a dialing string to be used). This area of the RADIUS protocol is not standardized among vendors, and new passwords and other data may not be compatible with your VPN switch and RADIUS server. RADIUS may choke on the nonstandard parameters, turning your carefully planned VPN implementation into a nightmare.

RADIUS should handle users' resetting their own passwords from the VPN client software. Imagine the look on the security director's face the first time the 90-day expiration date arrives for the VPN client passwords, and 3,000 users call to have their passwords reset. You get the picture--and it's not pretty. To avoid this problem, test your VPN and RADIUS platforms before deploying them. It is also a good idea to obtain both your VPN switch and your RADIUS server from the same hardware vendor to minimize this problem. You might just decide the built-in VPN client database looks pretty good even if you do have to copy the database manually from one server to the other during off-hours. You need a way for clients to make their own password changes--whether using the internal VPN client database or back ending RADIUS to NDS, Windows NT domains or even Unix password files.

Troubleshooting

You may find additional problems crop up when you implement a RADIUS solution with your VPN.

Some vendors offer different options in RADIUS. For example, Cisco Systems' VPN 3005 Concentrator lets you put network-configuration parameters in RADIUS using common attributes, whereas products from RedCreek and VPNet Technologies use vendor extensions for the same thing. With Cisco's solution, you don't have to make big changes to an existing RADIUS installation, but with RedCreek's and VPNet's, you do.

If you use Microsoft's version of CHAP in password encryption when using RADIUS, the VPN switch must be Microsoft CHAP-enabled and the RADIUS server must also support that CHAP. CHAP uses the MD5 (Message Digest 5) hash algorithm; however, Microsoft's CHAP uses MD4 to hash the password, and the output is used as the input key to DES. The RADIUS server needs to support Unicode as well.

Although not commonly used, MPPE (Microsoft Point-to-Point Encryption)-based 128-bit encryption may not work properly on some VPN switches using certain RADIUS servers because of switch code-level problems. Usually 40-bit encryption is unaffected. So if your environment requires 128-bit encryption, you should test your protocol along with your VPN switch and RADIUS server. For example, Nortel Networks' Contivity series switches have this problem using code level 2.51 with Bay Networks' BSAC (2.2 or later), Funk Software's Steel Belted Radius (2.2 or later) or Nortel's Preside Radius (1.0.49 or later).

Make sure that if you're using both a VPN switch's internal client database (possibly for administrators) and an external RADIUS server (for VPN clients) that the switch's user database is backed up. This backup feature is often not included in the switch configuration database, which can be backed up automatically to an FTP server. The user database must be backed up manually. Another problem associated with backing up the client database on a VPN switch is that you must inhibit logons during the process, and that means off-hour support.

Be careful to first test compatibility if selecting a RADIUS server to manage different hardware platforms, such as Cisco and Nortel routers, and also to provide client VPN logon validation. One vendor's RADIUS implementation may not work as intended--if at all--with other platforms because each vendor uses a different method to update RADIUS databases.

Office-to-office VPNs will require a separate RADIUS server at each location, because the encrypted tunnel does not let the RADIUS servers communicate with one another. You first need to tunnel to use RADIUS, but if you're using RADIUS, you can't build the tunnel. An alternative is to pass RADIUS externally to the VPN tunnel. If you're using CHAP, at least the password is never passed over the Internet; however, if using PAP, you're in trouble. If your network is widely deployed, a primary VPN portal using a central RADIUS server at corporate headquarters may be the best option. If global ISP response-time issues prevent this approach, then RADIUS for the central site and internal client validation at remote locations may be a better approach.

Will there be any problems with port filters you have in place? UDP (User Datagram Protocol) 500 is typically used for IKE (Internet Key Exchange), while RADIUS uses port 1415 for authentication and 1416 for accounting.

Ask Important Questions

If you outsource your VPN, consider any existing RADIUS and proxy RADIUS features your server is using. Will the provider's protocol support your needs? For example, will the provider be able to support split tunneling, thus keeping general client Web surfing off your network while letting in traffic destined for the corporate LAN? Does the provider allow the ability to turn off handshake KeepAlives? Will you have the ability to set a primary or a single DNS server to speed up connections? Will this impact your split-tunnel ability? Will the provider's RADIUS server be able to use proxy RADIUS to point to the corporate RADIUS server, thus preventing the client from having to use multiple logons and track different passwords?

If you're using tokens for additional security, test all configurations before deployment. Tokens may require special support in your RADIUS server, and some VPN solutions target the token server separately from the RADIUS server. Also, some token software versions are known to have problems. For example, SecureID tokens may not work on Win98 clients if launched from a shortcut or Start/Run menus.

As you can see, there are quite a few considerations when implementing a VPN solution, with centralized management of client access being paramount. There are many methods to accomplish this task, including using an internal VPN switch client database, RADIUS servers, proxy RADIUS and LDAP servers. No matter which you choose, implementing a test platform could save you considerable time and money in the long run.

Jim Flint is a systems engineer in the Corporate Network Services LAN group of Galileo International. Send your comments on this article to him at jim.flint@den.galileo.com.