By replacing private dial modem pools with inexpensive Internet-based access, VPNs can reduce the cost of remote access for travelers, teleworkers, and day extenders. In studies conducted last year by TeleChoice and Lucent NetCare, respondents cited remote access as their top reason for adopting VPN technology. But, in a May 2000 Infonetics report, two of the top 10 barriers to implementing VPNs were difficulty supporting remote access VPN users and difficulty managing authentication mechanisms.
What's the problem? When deploying a remote access VPN, challenges that must be mastered include client software installation and configuration, dynamically assigned addresses, and reliable user authentication. In today's column, we'll focus on issues associated with user authentication—the mechanisms used to verify user identity.
Device-level authentication
IP Security (IPsec) was designed for secure site-to-site (gateway-to-gateway) and remote access (client-to-gateway) tunneling between mutually authenticated devices. IPsec can protect tunneled packets against spoofing, modification, replay, eavesdropping, and other man-in-the-middle attacks. But, in order to trust anything received over an IPsec tunnel, one must first verify the sender's identity.
The standard used to accomplish this is called the Internet Key Exchange (IKE). IKE authenticates devices: the security gateway or client host at each end of an IPsec tunnel. Several authentication methods are supported; the most basic is pre-shared key. In this method, devices "A" and "B" are configured with the same key. Device "A" uses the key to encrypt and send a known value to Device "B". Host "B" decrypts the incoming packet, using the key associated the packet's source address. If successful, Host "B" believes that Host "A" is authentic.
Pre-shared keys are easy to deploy on a limited scale—for example, a modest site-to-site VPN. In larger VPNs, assigning unique keys to each gateway-gateway or gateway-client device pair becomes unwieldy. Furthermore, with IKE "main mode", a group of devices that share a pool of dynamic addresses—a very common remote access scenario—must use the same pre-shared key. But any key, known to an entire group, is more easily compromised.
Stronger authentication can be accomplished through public key cryptography. Public keys may be used alone ("raw") or embedded in X.509 digital certificates. In small VPNs, public/private key pairs and certificates can be configured manually or with simple device management tools. In larger VPNs—such as those involving many remote users—a Public Key Infrastructure (PKI) can be used to manage certificate enrollment, distribution, and verification.
Why can't I just use RADIUS?
Few companies are anxious to build their own PKI or purchase a managed PKI service solely for remote access. Instead, many would like to continue "legacy" authentication methods that are almost universally employed for direct-dial remote access today. In a survey of 175 companies conducted by Lucent NetCare, 57 percent wanted to use RADIUS authentication with their remote access VPN. Other popular legacy methods include TACACS+, two-factor tokens like SecurID, and one-time passwords.
Unfortunately, none of these legacy methods are directly compatible with standard IKE. Recall that IKE provides mutual (two-way) device-level authentication. Legacy methods like RADIUS provide one-way user-level authentication. Typically, the user provides his credentials (e.g., name and password) through some type of challenge-response interaction—open-ended interaction that is not supported by the current IKE standard.
Square peg, round hole
Fitting legacy authentication into IKE is like trying to insert a square peg into a round hole. They weren't made for each other, but you can pound the peg into the hole if you try hard enough.
The IETF didn't really overlook legacy user authentication. It started working on this challenge years ago, when the IKE standard was still underway. XAUTH, an IKE extension to accommodate legacy authentication, was first proposed in December 1997. Another approach called Hybrid was proposed in June 1998. But there was little industry consensus on the best solution, or even the problem. Some expected PKI to be deployed faster than it has been. Others argued that IKE should not be (further) complicated by legacy authentication. In March 2000, after a full year of charter debate, a new IPsec Remote Access (IPSRA) working group was formed to focus on remote access requirements.
http://www.isp-planet.com/technology/remote_access_conundrum-1-1.html
