Scenario

This article describes how to create a secure network-level transport between two hosts. All traffic sent between both hosts will be encrypted automatically as in enters the TCP/IP stack at the network (IP) level by using IPSec Encapsulating Security Payload (ESP) protocol.

For more details about IPSec, read IPSec pilot between glass and teapot.

Security Policy Database (SPD) configuration

The Security Policy Database (SPD) defines which IP traffic flows are to be affected by IPSec. Any traffic protected by IPSec can be protected by two different security mechanisms:

• Confidentiality.

  Is achieved by using IPSec Encapsulating Security Payload (ESP) protocol.

  The IPSec ESP protocol cyphers the contents of the payload to be transported over IP. ESP, optionally, offers authentication and integrity, but it is considered weak since it does only affect the payload but not the header of the encapsulating IP datagram.

• Authentication and Integrity.

  Is achieved by using IPSec Authentication Header (AH) protocol.

  The IPSec AH protocol protects that payload and any unmutable field of the encapsulating IP header.

By configuring the SPD, it is possible to use:

• IPSec Transport Mode to protect all the traffic sent between two hosts.
• IPSec Tunnel Mode to protect all the traffic sent between to networks.

For the machine ipsec-a:

Create the file /etc/racoon/setkey.sh with the following lines:

#!/sbin/setkey -f
spdflush ;
spdadd 192.168.0.40 192.168.0.41 any -P out ipsec esp/transport//require ;
spdadd 192.168.0.41 192.168.0.40 any -P in  ipsec esp/transport//require ;

This file should be marked executable and will be executed before launching racoon in order to populate the SPD with the proper entries.

For the machine ipsec-b:

Create the file /etc/racoon/setkey.sh with the following lines:

#!/sbin/setkey -f
spdflush ;
spdadd 192.168.0.41 192.168.0.40 any -P out ipsec esp/transport//require ;
spdadd 192.168.0.40 192.168.0.41 any -P in  ipsec esp/transport//require ;

This file should be marked executable and will be executed before launching racoon in order to populate the SPD with the proper entries.

Racoon configuration

racoon is a user-space daemon in charge of negotiating and establishing the Security Associations (SA) between two peer.

When the kernel sees an IP datagram, affected by a SPD rule, for which there is no SA yet established, the kernel will invoke racoon in order to negotiate and set it up with the corresponding peer defined in the SPD.

The peers can authenticate using some of the following:

• Pre-Shared Keys (PSK)

  Both peers mutually agree on a shared secret, which is manually configured by the administrator and stored in the file /etc/racoon/psk.txt.

• RSA Signature

  Each peer has an associated private key and public key X.509 certificate. Authentication takes place by exchanging certificates between peers and validating them, while RSA is used for authentication.

• GSSAPI

  Kerberos is used for authentication of both peers.

In out scenario, RSA Signature using X.509 public key certificates will be used for authentication between the peers so, in first place, we need to generate private keys and their corresponding certificates for each peer. The steps used to generate the certificates are described in Setting up Certificate Authority (CA) using OpenSSL.

The configuration for both peers is identical, so we will use the same racoon configuration file. However, the private key and public key certificate for each peer is different, so we should take this into consideration.

The peer private key must be installed into /etc/racoon/certs/key.pem, the peer signed public key certificate into /etc/racooon/certs/cert.pem and the CA public key certificate into /etc/racoon/certs/cacert.pem.

This is the /etc/racoon/racoon.conf configuration file:

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

remote anonymous
{
	# Some IPSec implementations have been found to
	# be vulnerable when used in aggressive exchange
	# mode
	exchange_mode main ;

	# Allow for the extension described in RFC 2407
	# called Domain of Interpretation which allows
	# negotiation of the traditional 32-bit sequence
	# numbers or extended 64-bit sequence numbers
	doi ipsec_doi ;

	# Local identifier is taken from the Subject field
	# of the X.509 certificate (Distinguised Name)
	my_identifier asn1dn ;

	# Remote identifier is taken from the Subject field
	# of the X.509 certificate presented by the remote
	# peer (Distinguised Name)
	peers_identifier asn1dn ;

	# Checks that the oeer identity that appears in the
	# ID payload matches the identity specified in the
	# peers_identifier option
	verify_identifier on ;

	# Specifies the path to the certificate and private
	# key files, encoded in PEM, relative to the
	# "path certificate" option specified above
	certificate_type x509 "cert.pem" "key.pem" ;

	# Specifies the path to the CA certificate file,
	# encoded in PEM, relative to the "path certificate"
	# option specified above
	ca_type x509 "cacert.pem" ;

	# Configures the size of the nonce in bytes, which
	# must be no less than 8 and no more than 256
	nonce_size 16 ;

	# Lifetime the Phase 1 SA proposal
	lifetime time 24 hour ;

	proposal
	{
		# Encryption algorithm for phase 1
		encryption_algorithm 3des ;

		# Hash algorithm for phase 1
		hash_algorithm sha1 ;

		# RSA Signature authentication
		authentication_method rsasig ;

		# Diffie-Hellman group for phase 1
		dh_group 2 ;
	}
}

sainfo anonymous
{
	# Diffie-Hellman group for phase 2
	pfs_group 2;

	# Lifetime for the SA
	lifetime time 12 hour ;

	# Encryption algorithms to be used in the SA
	encryption_algorithm 3des, blowfish, des, rijndael ;

	# Authentication algorithms to be used in the SA
	authentication_algorithm hmac_sha1, hmac_md5 ;

	# Use deflate compression (IPComp)
	compression_algorithm deflate ;
}

Starting peers

For every peer, we need to launch racoon. For testing purpouses, we will launch racoon in foreground, so all messages are dumped to the screen:

/usr/sbin/racoon -F

racoon will dump the following messages to the console:

INFO: @(#)ipsec-tools 0.5 (http://ipsec-tools.sourceforge.net)
INFO: @(#)This product linked OpenSSL 0.9.7f 22 Mar 2005 
      (http://www.openssl.org/)
INFO: 127.0.0.1[500] used as isakmp port (fd=7)
INFO: 127.0.0.1[500] used for NAT-T
INFO: 192.168.0.41[500] used as isakmp port (fd=8)
INFO: 192.168.0.41[500] used for NAT-T
INFO: ::1[500] used as isakmp port (fd=9)
INFO: fe80::20c:29ff:fea1:d55c%eth0[500] used as isakmp port (fd=10)

Next, we need to initialize the SPD:

/etc/racoon/setkey.sh

Testing connectivity

To trigger the SA establishment we can ping the other host. The kernel will apply the SPD policy and will ask racoon to negotiate and set up the proper SA between both peers. racoon should dump something like this to the console:

INFO: IPsec-SA request for 192.168.0.40 queued due to no phase1 found.
INFO: initiate new phase 1 negotiation: 
      192.168.0.41[500]192.168.0.40[500]
INFO: begin Identity Protection mode.
INFO: received Vendor ID: DPD
WARNING: unable to get certificate CRL(3) at depth:0 SubjectName:
         /C=ES/ST=Madrid/O=Software AG/OU=IT/CN=ipsec-a
WARNING: unable to get certificate CRL(3) at depth:1 SubjectName:
         /C=ES/ST=Madrid/L=Madrid/O=Software AG/OU=IT/CN=ca-server
INFO: ISAKMP-SA established 192.168.0.41[500]-192.168.0.40[500] 
      spi:2698c81446191f6c:9b9127e3b6956065
INFO: initiate new phase 2 negotiation: 192.168.0.41[0]192.168.0.40[0]
INFO: IPsec-SA established: ESP/Transport 192.168.0.40->192.168.0.41 
      spi=78608282(0x4af779a)
INFO: IPsec-SA established: ESP/Transport 192.168.0.41->192.168.0.40 
      spi=118550227(0x710eed3)