XAUTH marks the spot
To better understand the issues, let's examine XAUTH. XAUTH inserts a new exchange in the middle of IKE, after device-level authentication (phase 1). With XAUTH, an IPsec gateway can prompt a client for extended authentication ("send me your user's name and password"). If the client responds with satisfactory user-level credentials, tunnel setup continues (phase 2). User authentication based on CHAP (RADIUS, TACACS+), two-factor token authentication (SecurID, Defender), one-time passwords (OTP), and S/Key are all supported by XAUTH.

For example, consider a company using RADIUS for direct-dial authentication. This company might transition to IPsec by deploying a group pre-shared key for device-level authentication, followed by RADIUS user authentication. XAUTH lets the company roll out IPsec/IKE without replacing or replicating its RADIUS user database. When ready, the company can add strong authentication by assigning digital certificates to gateways and users, phasing out legacy authentication and XAUTH.

So, what's the catch? XAUTH is vulnerable to man-in-the-middle attacks, especially when used with "main mode" IKE and a group pre-shared key as described above. XAUTH also carries known plaintext (name and password prompts) as encrypted payload—hints an attacker might use to try to "crack" the encryption key.

A Hybrid approach
IKE requires bidirectional, symmetric device-level authentication. If the client identifies itself with a pre-shared key, the gateway must also use a pre-shared key. But the gateway should really use strong authentication. Hybrid Authentication, a refinement of XAUTH, enables this.

Hybrid provides unidirectional, asymmetric authentication. The gateway can authenticate itself using any method supported by IKE: pre-shared key, raw public key, or digital certificate. The client device uses the same method with null values that are effectively ignored. Once the gateway has been authenticated, an XAUTH exchange between IKE phases 1 and 2 authenticates the user.

This approach enables strong gateway authentication in cases where XAUTH alone would not—such as when remote users have dynamically assigned addresses. A companion proposal known as Mode-Cfg enables the exchange of addressing information between IPsec gateway and client, another remote access requirement not addressed by standard IKE.

With both Hybrid and vanilla XAUTH, the open-ended exchange between IKE phases can inhibit gateway-client interoperability with products that do not support XAUTH. Because Hybrid and XAUTH are draft protocols, vendors can and do implement different versions of them. When it comes to legacy authentication, it is usually necessary to use an IPsec gateway and client supplied by the same vendor.

When standards and implementations differ
The IPSRA is tasked with defining a standard mechanism for user-level authentication to an IPsec device running IKE, accommodating legacy methods. But this group's charter includes a major caveat: solutions that do not change IPsec or IKE are preferred. This ruling effectively eliminated XAUTH and Hybrid from the standards track, and these Internet Drafts expired.

However, vendors did not stop implementing XAUTH. As NAI's Dave Mason observed after a recent VPN workshop, "These protocols aren't going to happen—they already have happened!" Many vendors now ship products with Hybrid or vanilla XAUTH, including Alcatel, CheckPoint, Cisco, CoSine, IRE, Radguard, SonicWall, and SSH. Many others support legacy authentication in some fashion, without identifying XAUTH or Hybrid on product spec sheets.

Go to page 3: Rocky road ahead?