Advanced Features of Linux strongSwan the OpenSource VPN Solution Institute of Internet Technologies and Applications Hochschule für Technik Rapperswil, Schweiz The powerful advanced features of the Linux strongSwan VPN solution will be presented: IPsec policies based on wildcards, certificate hierarchies or group memberships defined by X.509 attribute certificates; certificate revocation based on the Online Certificate Status Protocol; Virtual IP address assignment; smartcard support; Dead Peer Detection. Also the new and user-friendly strongSwan User-Mode-Linux testing environment will be demonstrated. 1 IPsec-based Virtual Private Networks Figure 1 shows a typical VPN scenario where two subnets 10.1.0.0/16 and 10.2.0.0/16 possessing private network addresses are connected with each other over the Internet by means of a site-to-site VPN tunnel. The tunnel is established between the VPN gateways 11.22.33.44 and 55.66.77.88 which automatically encrypt and authenticate each packet that is being exchanged between the two networks. „R oad Warrior“ VPN Client 10.3.0.2 10.1.0.5 10.2.0.3 55.66.x.x Internet VPN Tunnel Head Subsidiary Quarters VPN Tunnel 10.1.0.0/16VPN Gateway VPN Gateway 10.2.0.0/16 11.22.33.44 55.66.77.88 Figure 1: Typical VPN scenario The second much more challenging scenario depicted in Figure 1 is remote access. So called „road warriors“, equipped with dynamical IP addresses assigned by their local Internet Service Providers (ISPs) are able to build up a VPN tunnel to the security gateway 11.22.33.44 from any point of the Internet using either fixed connections, public WLAN hot spots or mobile communication channels. Thus the remote access clients get full access to all resources in the 10.1.0.0/16 network as if they were located right at Head Quarters. Reprint of LinuxTag2005 Paper 1 We will come back to the special properties of the road warrior case later in this paper and continue by first giving a short overview on the IPsec standard which basically consists of two parts: ● The actual encryption and authentication of tunneled IP packets takes place in the kernel using the Encapsulating Security Payload (ESP) standard defined by RFC 2406. ESP is IP protocol 50 and doesn't have ports. ● The initial negotiation and the ensuing periodic re-keying of IPsec tunnels is done by a userland daemon running the Internet Key Exchange (IKE) protocol defined by RFCs 2407, 2408, and 2409. IKE is transported over UDP datagrams and must use the well-known source and destination port 500. 1.1 The IPsec Kernel Part - ESP The ESP encapsulation of IP packets is shown in figure 2. Referring to the site-to-site VPN scenario depicted in figure 1, a TCP packet exchanged between a host 10.1.0.5 in the 10.1.0.0/16 network and a host 10.2.0.7 in the 10.2.0.0/16 network will carry these two addresses as source and destination in the original IP header, whereas the outer IP header of the IPsec packet will contain the addresses 11.22.33.44 and 55.66.77.88 of the VPN gateways that do the actual tunneling. ESP encrypts the whole original IP packet including the internal header and secures the encrypted content against unauthorized modification by computing and appending a cryptographic checksum. Before applying ESP Original TCP Encapsulating Security IP v4 Data IP Header Header Payload (ESP): RFC 2406 After applying ESP Outer ESP Original TCP ESP ESP IP v4 Data IP Header Header IP Header Header Trailer Auth encrypted authenticated Figure 2: IPsec Encapsulating Security Payload (ESP) Depending on the Linux kernel version, strongSwan employs different mechanisms to implement the IPsec kernel part: ● Under a Linux 2.4 kernel, KLIPS from the FreeS/WAN project is used to implement the IPsec kernel functionality. KLIPS, distributed as part of strongSwan, can either be compiled statically into the kernel or loaded dynamically as a kernel module ipsec.o. For encryption, authentication and compression, built-in functions from the FreeS/WAN project and/or crypto modules provided by JuanJo Ciarlante are used. ● Under a Linux 2.6 kernel, the native KAME stack ported from the BSD project to Linux is used. Encryption, authentication and compression tasks use the standard modules offered by the kernel's crypto API. Reprint of LinuxTag2005 Paper 2 1.2 The IPsec Userland Part - IKE strongSwan's userland daemon pluto is responsible for setting up, re-keying and deleting IPsec tunnels using the standardized Internet Key Exchange (IKE) protocol. An IKE negotiation is divided into Phase 1 where the VPN peers do mutual authentication, followed by one or several Phase 2 exchanges where the encryption, authentication and compression parameters for the actual tunneling of IP packets between predefined subnets are set up. strongSwan implements IKE Main Mode for Phase 1 and IKE Quick Mode for Phase 2. The potentially vulnerable IKE Aggressive Mode Phase 1 variant is not supported by strongSwan out of security considerations. IKE Main Mode peer authentication can either be based on Pre-Shared Keys (PSK) or on RSA signatures as shown in figure 3. Initiator Responder IK E IS A K MP S A 1 Header Proposal IK E IS A K M P S A 2 Header Response IK E DH Key N 3 Header Exchange i IK E DH Key 4 N encrypted Header Exchange r IK E ID Cert Sig 5 Header i i i encrypted IK E 6 ID Cert Sig Header r r r Figure 3: Internet Key Exchange Protocol (IKE) IKE Main Mode consists of six messages exchanged between the VPN peers: 1. The initiator proposes a series of supported encryption and authentication transforms for securing the IKE negotiation. 2. The responder selects a set of transforms common to both parties. 3. The initiator sends a public Diffie-Hellman factor and a nonce. 4. The responder in turn also sends a public Diffie-Hellman factor and a nonce which is a random number. Using the Diffie-Hellman key exchange algorithm both end points can now compute a common shared secret that is used to encrypt all ensuing IKE messages. 5. The initiator sends its identity and a signature computed by encrypting a hash formed over all exchanged IKE messages with its RSA private key. Although an option in IKE, strongSwan always includes a trusted X.509 certificate that can be used by the peer to verify the signature. 6. Now it is the responder's turn to identify and authenticate itself. Each IKE Quick Mode will then add another three messages. Reprint of LinuxTag2005 Paper 3 2 From FreeS/WAN to strongSwan The FreeS/WAN project (www.freeswan.org) was founded in 1999 by John Gilmore with the ultimate goal of automatically encrypting a significant part of the Internet traffic using Opportunistic Encryption (OE) based on IPsec and IKE. The grand idea behind OE was to do host authentication using raw RSA public keys fetched via the ubiquitous Domain Name System (DNS). Because most existing VPN implementations did not and still do not support the use of raw RSA keys, the author decided to contribute a X.509 patch to the FreeS/WAN project in order to make it possible for Linux hosts to set up IPsec tunnels with any other VPN product using standardized X.509 certificates. The first X.509 patch was released in 2000 and all further versions delivered over the next four years were developed by the author as professor for security and communications at the Zürcher Hochschule Winterthur (ZHW) with major contributions from a whole group of diploma students. In 2002, due to the increasing demand for the X.509 patch, Ken Bantoft bundled it with several other FreeS/WAN add-ons like Mathieu Lafon's NAT traversal patch and JuanJo Ciarlante's alternative crypto algorithms and started his Super FreeS/WAN distribution that quickly became extremely popular. FreeS/WAN 1.3 X.509 Patch 0.1 2000 ZHW Ken Bantoft X.509 Patch 0.9.32 Super FreeS/WAN 1.99.8 2002 FreeS/WAN 1.99 X.509 Patch 0.9.42 Openswan 1.0.9 2003 Xelerance X.509 Patch 1.5.4 Openswan 2.3.1 2004 FreeS/WAN 2.04 X.509 Patch 1.6.3 strongSwan 2.4.2 2004 Linux 2.6 Kernel ITA-HS R FreeS/WAN 2.06 Figure 4: The FreeS/WAN Genealogy Towards the end of 2003 when it became evident that the FreeS/WAN project was going to be discontinued in spring 2004 with the final 2.06 release, Ken Bantoft, FreeS/WAN project leader Michael Richardson and Paul Wouters founded Xelerance Corporation with the goal of carrying on the IPsec development within their Openswan project (www.openswan.org). Whereas Openswan has been moving closer to the mainstream VPN path by adding IKE Aggressive Mode and Cisco's legacy XAUTH authentication, the author decided to fork a strongSwan distribution (www.strongswan.org) of his own in order to be able to quickly integrate and deploy new certificate-based features originating from the Zürcher Hochschule Winterthur. Reprint of LinuxTag2005 Paper 4 In March 2005 the author accepted an offer to join the Hochschule für Technik Rapperswil (HSR, www.hsr.ch) where as a professor for security and communications he is now heading the Institute for Internet Technologies and Applications (ITA). Being an important part of the ITA strategy, the maintenance and continuing evolution of the strongSwan distribution will be guaranteed in the years to come. 3 The „Road Warrior“ Remote Access Case One of strongSwan's powerful features inherited from FreeS/WAN is the support of road warrior connections as shown in figure 5.