Configuring IPsec

To ensure the correct parameters are sent in the first packet exchange, Openswan requires that you specify an appropriate ike= line whenever using aggressive mode.

XAUTH

XAUTH is a strange and difficult addition aimed at extending the IKE protocol to support other authorization schemes. It is usually needed for interoperability, but often systems using XAUTH also use other, often proprietary extensions to the IPsec protocol. Chances are high XAUTH will actually not help you reach a working solution. This is also the reason that XAUTH support has been added only very recently, and has not been tested very well: XAUTH support in Openswan is still very experimental.

An additional problem is that some features of XAUTH are actually dependent on other parts of the system, which can at times be incompatible. For instance encrypting and decrypting MD5 or DES passwords, for example from /etc/shadow, does not always seem to work among different systems, and using XAUTH to authenticate against the system's user database using PAM opens up another Pandora's box of problems.

XAUTH stands for Extended Authentication. It is important to realize that it is not an authentication scheme on its own, and is used in addition to another scheme, usually RSA keys or PSKs. XAUTH with PSKs is often called group PSK, since one PSK will be shared with many clients, who then use a user/password or, for example, a SecureID token as the extended authentication. In such a setup, the PSK is used only for Phase 1 authentication, and XAUTH is used to complete the Phase 2 authentication.

This immediately brings us to a very important problem. Since many clients are using the same group PSK for the server, if a single client is compromised, the entire group's PSK is also compromised. Though one might think this is not that important, since another layer of authentication is still needed, this is not entirely true. Anyone with the PSK can play man in the middle and act as the server. The client will happily supply its user/password or SecureID credentials and the rogue server will now be able to log in to the real server as a client. Openswan makes this matter slightly worse by only supporting one group PSK, forcing all clients to use a single shared secret.

Another problem with XAUTH is that it is often misconfigured in such a way that the connection will rekey. When rekeying happens, the user needs to supply the username and password (or SecureID number) again. Since Openswan has no way of querying the user for this, the connection will terminate. XAUTH connections should never require rekeying. Most Windows clients cache the username and password, either in memory or on disk.

One can combine XAUTH with RSA keys instead of PSKs, but since most software clients and hardware vendors do not support XAUTH with RSA, this would only work on an Openswan-to- Openswan interop, in which case one wouldn't need to support XAUTH at all, unless one believes in the additional security of an (easy to guess) user/password combination. Also, since most services behind the VPN, such as a network fileshare, email server access, or printer access, are probably already protected with a required username/password combination for when the user is

104

Chapter 4

connecting from the local LAN network, adding yet another user/password combination, which is likely to be the same one anyway, is not adding any security to the system as a whole.

Yet another problem with XAUTH is that it is often combined with Aggressive Mode, which is inherently dangerous.

XAUTH Gateway (Server Side)

To configure Openswan as an XAUTH server using a single group PSK for Phase 1, we need to add the PSK in the ipsec.secrets file and add XAUTH requirements to the connection. We will use East as XAUTH server and a roadwarrior as an XAUTH client (normally called supplicant).

First we configure East. In ipsec.secrets we add:

193.110.157.131 %any : PSK "secret"

Be aware that Pluto does not support automatic left and right swapping for ipsec.secrets as it does for ipsec.conf, as this would be extremely dangerous.

For XAUTH you do not use the IP address or %any. Instead you must use the groupname. A groupname is really just a PSK, but shared with others.

193.110.157.131 @groupname : PSK "secret"

Our ipsec.conf connection entry on the server becomes:

conn xauth-roadwarriors leftxauthserver=yes left=193.110.157.131 right=%any rightid=@mygroupname rightxauthclient=yes auto=add authby=secret

XAUTH Client (Supplicant Side)

One important difference when using XAUTH on the client as compared to other types of connections is that it needs to be interactive: the user must type in their username and password. Therefore, these connections cannot be loaded using auto=start, and instead should just be added

using auto=add, and manually started using ipsec auto --up connectionname.

This process can be automated using Pluto's whack command directly:

# ipsec whack --xauthname 'username' --xauthpass 'password' --name xauthroadwarriors --initiate

Of course this is not recommended, since you will be storing the username and password for the XAUTH exchange unencrypted in some script. If such a laptop is stolen, the additional security from XAUTH over a plain PSK IPsec tunnel is moot.

A successful XAUTH exchange looks like this:

002 "xauth-roadwarriors" #1: initiating Main Mode 104 "xauth-roadwarriors" #1: STATE_MAIN_I1: initiate

003 "xauth-roadwarriors" #1: received Vendor ID payload [XAUTH]

002 "xauth-roadwarriors" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2

105