Configuring Suite B, VPN-A and VPN-B in IPSec with Strongswan

Many vendors have got the various IPSec standards already implemented within their products for ease of use.  This is my configuration for matching these standards with Strongswan.

It’s always nice to use a standard; they come from RFCs so have some level of scrutiny and make things interoperable.  These suites in my experience tend to be the ones which are implemented most widely.  As a security professional I’m happy that someone has investigated the best solutions with which to use.

I’d highly recommend to use AES GCM wherever possible, from personal experience I’ve found it to run for better than 3DES or “standard” AES on more modern equipment.

Suite B VPN Combined

The details below can be used to make cryptography which matches Suite B apply to our IPSec connections in Strongswan.  We want to try the more secure algorithms first.

conn suite-b-combined
    # Suite-B-GCM-256 then Suite-B-GCM-128
    # Provides confidentiality and integrity protection
    # Traffic will be encrypted
    keyexchange=ikev2
    ike=aes256-sha384-ecp384-prfsha384,aes128-sha256-ecp256-prfsha256!
    esp=aes256gcm16,aes128gcm16!

All Suites Combined

This approach should work with most things during the negotiation process, and I’ve removed the suites which do not encrypt our data.  This configuration includes the newer Suite B as well as the older VPN-A and VPN-B.  Please note that this connection configuration uses 3DES which many organizations have given a “Legacy” rating.

conn suite-b-vpn-a-vpn-b
    # Suite-B-GCM-256, Suite-B-GCM-128, Suite "VPN-B" then Suite "VPN-A"
    # Provides confidentiality and integrity protection
    # Traffic will be encrypted
    keyexchange=ikev2
    ike=aes256-sha384-ecp384-prfsha384,aes128-sha256-ecp256-prfsha256,aes,aesxcbc,modp2048,3des-sha1-modp1024!
    esp=aes256gcm16,aes128gcm16,aes-aesxcbc,3des-sha1!

Suite “Suite-B-GCM-128”

It isn’t technically necessary to specify the PRF with Strongswan if it matched the same algorithm used by Integrity, but included here for completeness.

Suite “Suite-B-GCM-128”
ESP:
Encryption AES with 128-bit keys and 16-octet Integrity Check Value (ICV) in GCM mode [RFC4106]
Integrity NULL

IKEv2:
Encryption AES with 128-bit keys in CBC mode [RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC5903

RFC 6379

conn suite-b-gcm-128
    # Suite-B-GCM-128
    # Provides confidentiality and integrity protection
    # Traffic will be encrypted
    keyexchange=ikev2
    ike=aes128-sha256-ecp256-prfsha256!
    esp=aes128gcm16!

Suite “Suite-B-GCM-256”

It isn’t technically necessary to specify the PRF with Strongswan if it matched the same algorithm used by Integrity, but included here for completeness.

Suite “Suite-B-GCM-256”
ESP:
Encryption AES with 256-bit keys and 16-octet ICV in GCM mode [RFC4106]
Integrity NULL

IKEv2:
Encryption AES with 256-bit keys in CBC mode [RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC5903]

RFC 6379

conn suite-b-gcm-256
    # Suite-B-GCM-256
    # Provides confidentiality and integrity protection
    # Traffic will be encrypted
    keyexchange=ikev2
    ike=aes256-sha384-ecp384-prfsha384!
    esp=aes256gcm16!

Suite “Suite-B-GMAC-128”

Warning: This suite does NOT encrypt your data, so in other words it’s probably not what you want to use unless you know what you’re doing.

Suite “Suite-B-GMAC-128”
ESP:
Encryption NULL
Integrity AES with 128-bit keys in GMAC mode [RFC4543]

IKEv2:
Encryption AES with 128-bit keys in CBC mode [RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC5903]

RFC 6379

conn suite-b-gmac-128
    # Suite-B-GMAC-128
    # Provides integrity protection but NOT confidentiality
    # Traffic will NOT be encrypted
    keyexchange=ikev2
    ike=aes128-sha256-ecp256-prfsha256!
    esp=aes128gmac!

Suite “Suite-B-GMAC-256”

Warning: This suite does NOT encrypt your data, so in other words it’s probably not what you want to use unless you know what you’re doing.

Suite “Suite-B-GMAC-256”
ESP:
Encryption NULL
Integrity AES with 256-bit keys in GMAC mode [RFC4543]

IKEv2:
Encryption AES with 256-bit keys in CBC mode [RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC5903]

RFC 6379

conn suite-b-gmac-256
    # Suite-B-GMAC-256
    # Provides integrity protection but NOT confidentiality
    # Traffic will NOT be encrypted
    keyexchange=ikev2
    ike=aes256-sha384-ecp384-prfsha384!
    esp=aes256gmac!

Suite “VPN-A”

This suite is probably going to work with almost anything which supports IPSec, including a great deal of legacy devices and software implementations.  However 3DES which VPN-A uses has been somewhat deprecated by Cisco and Microsoft among others.  Many standards bodies such is NIST and ENISA no longer allow 3DES to be used.  In other words I’d say please don’t use Triple DES unless you really have to, there are far more efficient alternatives available.

2.1. Suite “VPN-A”

This suite matches the commonly used corporate VPN security used in IKEv1 at the time of this document’s publication.

IPsec:
Protocol Encapsulating Security Payload (ESP) [RFC2406]
ESP encryption TripleDES in CBC mode [RFC2451]
ESP integrity HMAC-SHA1-96 [RFC2404]

IKE and IKEv2:
Encryption TripleDES in CBC mode [RFC2451]
Pseudo-random function HMAC-SHA1 [RFC2104]
Integrity HMAC-SHA1-96 [RFC2404]
Diffie-Hellman group 1024-bit Modular Exponential (MODP) [RFC2409]

RFC 4308

conn vpn-a
    # Suite VPN-A - Deprecated
    # Provide confidentiality and integrity protection
    # Traffic will be encrypted
    keyexchange=ike
    ike=3des-sha1-modp1024!
    ikelifetime=24h
    esp=3des-sha1!
    lifetime=8h

Suite “VPN-B”

Again this suite is fairly interopable and as such should run on a great deal of older equipment, but personally I’d still prefer to use AES in GCM.

Suite “VPN-B”

This suite is what many people expect the commonly used corporate VPN security that will be used within a few years of the time this document’s publication.

IPsec:
Protocol ESP [RFC2406]
ESP encryption AES with 128-bit keys in CBC mode [AES-CBC]
ESP integrity AES-XCBC-MAC-96 [AES-XCBC-MAC]

IKE and IKEv2:
Encryption AES with 128-bit keys in CBC mode [AES-CBC]
Pseudo-random function AES-XCBC-PRF-128 [AES-XCBC-PRF-128]
Integrity AES-XCBC-MAC-96 [AES-XCBC-MAC]
Diffie-Hellman group 2048-bit MODP [RFC3526]

RFC 4308

conn vpn-b
    # Suite VPN-B
    # Provide confidentiality and integrity protection
    # Traffic will be encrypted
    keyexchange=ike
    ike=aes-aesxcbc-modp2048!
    ikelifetime=24h
    esp=aes-aesxcbc!
    lifetime=8h

Implementation

In order to use these configurations you have a few choices on how to do it.

First option is to edit the /etc/ipsec.conf file, and copy and paste the code examples above to enforce these suites as default configurations under a conn %default.

Second option is also to edit the /etc/ipsec.conf file but use the IKE and ESP lines for a specific VPN you may have setup.

Don’t forget to ipsec restart after making changes to the IPSec configuration files.

If you followed my previous Ubuntu IPSec VPN post your ipsec.conf could look like the following.

conn %default
    # Suite-B-GCM-256 then Suite-B-GCM-128
    # Provides confidentiality and integrity protection
    # Traffic will be encrypted
    keyexchange=ikev2
    ike=aes256-sha384-ecp384-prfsha384,aes128-sha256-ecp256-prfsha256!
    esp=aes256gcm16,aes128gcm16!

conn red-to-blue
    authby=secret
    auto=route
    left=192.168.100.100
    right=192.168.100.200
    type=transport

As a second option you could take the keyexchange, IKE and ESP configurations and apply them into your existing connections.

conn red-to-blue
    authby=secret
    auto=route
    keyexchange=ikev2
    ike=aes256-sha384-ecp384-prfsha384,aes128-sha256-ecp256-prfsha256!
    esp=aes256gcm16,aes128gcm16!
    left=192.168.100.100
    right=192.168.100.200
    type=transport

The third option which is probably the most consistent is to use the Stronswan include statement, for instance also=suite-b-combined. So you’re config could look like the following.

conn suite-b-combined
    # Suite-B-GCM-256 then Suite-B-GCM-128
    # Provides confidentiality and integrity protection
    # Traffic will be encrypted
    keyexchange=ikev2
    ike=aes256-sha384-ecp384-prfsha384,aes128-sha256-ecp256-prfsha256!
    esp=aes256gcm16,aes128gcm16!

conn red-to-blue
    also=suite-b-combined
    authby=secret
    auto=route
    left=192.168.100.100
    right=192.168.100.200
    type=transport

Testing

If you setup a host to host VPN then run the following command.

ipsec statusall

You should see something like the following, which indicates it is working as expected.  You want to pay attention to the line mentioning IKE proposal.

Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-24-generic, x86_64):
uptime: 32 seconds, since Oct 05 14:36:45 2015
malloc: sbrk 1486848, mmap 0, used 334384, free 1152464
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity addrblock
Listening IP addresses:
192.168.100.100
Connections:
red-to-blue: 192.168.100.100…192.168.100.200 IKEv1/2
red-to-blue: local: [192.168.100.100] uses pre-shared key authentication
red-to-blue: remote: [192.168.100.200] uses pre-shared key authentication
red-to-blue: child: dynamic === dynamic TRANSPORT
Routed Connections:
red-to-blue{1}: ROUTED, TRANSPORT
red-to-blue{1}: 192.168.100.100/32 === 192.168.100.200/32
Security Associations (1 up, 0 connecting):
red-to-blue[2]: ESTABLISHED 24 seconds ago, 192.168.100.100[192.168.100.100]…192.168.100.200[192.168.100.200]
red-to-blue[2]: IKEv2 SPIs: 57c28ec01281715f_i 3a69a68ce254949c_r*, pre-shared key reauthentication in 2 hours
red-to-blue[2]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
red-to-blue{1}: INSTALLED, TRANSPORT, ESP SPIs: c7bcd891_i c0bffd93_o
red-to-blue{1}: AES_GCM_16_256, 1536 bytes_i (24 pkts, 0s ago), 1536 bytes_o (24 pkts, 0s ago), rekeying in 42 minutes
red-to-blue{1}: 192.168.100.100/32 === 192.168.100.200/32