Protecting the 'private' in VPN

By ALAN MACLEOD
Network World, 09/27/99

While the IP Security (IPSec) standard delivers strong authentication and encryption capabilities, it falls short in the features necessary to deploy and manage large-scale remote dial-up communities in a virtual private network.

Device-level authentication is a standard part of the IPSec Internet Key Exchange (IKE) negotiation, but IP address assignment and user-level authentication procedures are not. As a result, Internet Engineering Task Force efforts called IKE Configuration Method, Extended Authentication and Hybrid Authentication are underway to simplify and standardize key dial-up VPN services.

Remote users need a valid, internally recognized IP address to access the corporate network. Today they receive IP configuration information when they dial in to their corporate networks. This same requirement exists for remote access IP VPNs. To alleviate the need to manually assign IP addresses to each user, the IPSec working group has proposed the IKE Configuration Method. Known as Mode Config, it allows a dial-up user to receive IP configuration information as part of the IKE negotiation. Mode Config lets companies operate their IP VPNs in the same way they operate traditional remote access; it should be mandatory feature for any VPN.

The IPSec working group has focused primarily on digital certificates as the long-term solution for authentication at the device and user levels, but there are near-term issues.

First, distributing "trusted" certificates to a large body of remote users is complex. Second, a digital signature is generated from a key that resides on each PC. While the key is typically protected, the PC is often physically vulnerable to unauthorized access. Third, today's network operating systems (NOS) do not directly support certificates for user authentication.

For device-level authentication, preshared keys, which are somewhat analogous to passwords, offer a near-term alternative to certificates. They are easier to deploy, as they can be distributed once to each PC during the initial configuration process. However, they are less secure than certificates.

While the ultimate goal is to authenticate certificates directly to the NOS directory, two more near-term solutions have been proposed. The first is Extended Authentication within ISAKMP/Oakley (XAuth). The second is Hybrid Authentication Mode for IKE. Both proposals are defined as extensions to the IKE negotiation process and are based on the Mode Config draft described above.

XAuth allows user-level authentication against existing third-party authentication systems such as Remote Authentication Dial-In User Service, NetWare Bindery or Novell Directory Services. Because XAuth expects user input - username and password - it still requires certificates or preshared keys for first-phase device-level authentication.

In the most common XAuth scenario, a company's dial-up VPN users are assigned the same preshared key. This is not a problem for authenticating users; they still go through a username and password authentication. However, it is an issue for users authenticating their security gateways. It would not be difficult to spoof the gateway to obtain people's usernames and passwords. Certificates are necessary to address this problem.

As a result, Hybrid Authentication Mode for IKE has been proposed. Hybrid Authentication, a variation on the XAuth draft, combines the best of both worlds. Certificates are deployed only on the security gateways, not on all PCs. At the same time, the IKE negotiation is extended to allow authentication against existing third-party systems.

During the first phase of device-level authentication, the remote PC is optionally authenticated by the gateway via a digital signature/certificate. The gateway must return a digital signature/certificate to the client to confirm that it is the correct gateway. Second-phase user authentication is then based on username and password, allowing integration into existing authentication systems.

It's worth noting that because both proposals build on mechanisms used in IPSec, they can coexist within a full certificate infrastructure. The protocols have reasonably strong support within the VPN vendor community and provide a solution that will be required for many years to come, if not for the lifetime of IP VPNs.

Protecting the 'private' in VPN

Related Links