CRACK: The VPN authenticator
Of the three types of
authentication supported under
the IPSec Internet Key
Exchange (IKE) specification,
only digital certificate-based
authentication provides secure
access for remote users.
Digital certificates require
additional services on the
corporate network that are
collectively known as a
public-key infrastructure
(PKI). While many
organizations are on their way
to some type of PKI
implementation, few have fully
integrated PKI and digital
certificates into their
corporate IT infrastructures.
Three systems geared toward
solving the problem of linking
remote-access users and legacy
authentication methods (LAM)
such as SecurID and RADIUS
have been proposed to the
Internet Engineering Task
Force - eXtended
Authentication (XAUTH), Hybrid
Authentication and
Challenge/Response
Authentication of
Cryptographic Keys (CRACK).
By DAN HARKINS for Network World
In the two years since the final version of the IP Security standards were finalized, enterprise network managers have shown confidence in the security, reliability and manageability of IPSec VPNs.
As network managers began to deploy IPSec-based VPNs, it became evident that several major areas in the IPSec standards needed attention in order to properly support remote access. One of the areas was authentication.
Of the three types of authentication supported under the IPSec Internet Key Exchange (IKE) specification, only digital certificate-based authentication provides secure access for remote users. Digital certificates require additional services on the corporate network that are collectively known as a public-key infrastructure (PKI).
Unfortunately, while many organizations are on their way to some type of PKI implementation, few have fully integrated PKI and digital certificates into their corporate IT infrastructures.
However, corporate networks have an enormous installed base of user authentication systems based on other technologies, such as RSA's SecurID card or user/password databases accessible through Remote Access Dial-In User Service (RADIUS) servers.
Three systems geared toward solving the problem of linking remote-access users and legacy authentication methods (LAM) such as SecurID and RADIUS have been proposed to the Internet Engineering Task Force - eXtended Authentication (XAUTH), Hybrid Authentication and Challenge/Response Authentication of Cryptographic Keys (CRACK).
CRACK, the newest of the three, allows for an asymmetric form of authentication to take place directly within the IKE protocol. By adding a new authentication method to IKE via the CRACK protocol, the security properties that have been precisely crafted into IKE are retained. This is a major difference between CRACK and other IKE authentication extensions, such as XAUTH and Hybrid Authentication. A critical goal of CRACK is that no sacrifice of security has been made for usability.
In the CRACK proposal, a fourth authentication method is added to IKE. When the VPN server and end user begin their authentication dialog, the user indicates he wants to use CRACK. The VPN server responds - if it supports CRACK - by presenting its authentication credentials based on a digital certificate.
The initial dialog provides strong authentication of the VPN server to the end user. Although one of the goals of CRACK is to avoid the deployment of PKI, only the VPN server (not the client) needs a certificate in CRACK. Many VPN vendors provide a "mini PKI" in their products that can issue certificates for servers, or simple PKI products such as those built into Microsoft's Windows 2000 Server can be used. Because an organization typically has only a small number of VPN tunnel servers, the difficulty of a full-fledged deployment of PKI is avoided, while the benefits of certificate-based authentication are kept.
Once the server has authenticated to the user, it is the user's responsibility to authenticate to the server. Instead of using certificates, though, the user selects a supported LAM. This is a key attribute of CRACK: changing the VPN authentication method from a symmetric one to an asymmetric one, with PKI for VPN servers and LAMs for VPN clients.
Any LAM can be supported with CRACK, including simple user name/password pairs, challenge/response tokens, or time-based tokens such as SecurID. CRACK allows for an arbitrarily long dialog between end user and VPN server, which can support important features such as changing the personal identification number on a token card.
Only after the user fully authenticates is the Phase 1 IKE security association created. Then IKE Phase 2 proceeds as always, and the VPN tunnel can be brought up. CRACK lets remote-access users use legacy authentication methods and is the first proposal to maintain the strong mutual authentication properties of IKE.
The years of careful analysis that went into the development and approval of IKE still apply. The same confidence that network managers have in the security of traditional IPSec VPNs is maintained in CRACK-based remote access VPNs.
Changes in the IPSec suite of security protocols are aimed at making IPSec-based products more accessible to remote-access users. One of the stickiest areas of change is in authentication of end users. CRACK-based remote-access authentication offers the proven and analyzed security of IPSec with the convenience of traditional authentication systems.
SNP.
