Project

General

Profile

EAP-TLS authentication

Starting with strongSwan 4.5.0, charon supports EAP-TLS authentication. EAP-TLS uses a TLS handshake to authenticate client and server (or an AAA backend) mutually with certificates.

While EAP-TLS is a secure and very flexible protocol, it is rather slow when used over IKE. Depending on the fragment and certificate size, it requires 6-10 additional IKE exchanges compared to traditional IKEv2 certificate authentication. But there are other reasons to use EAP-TLS, such as Windows 7 smartcard authentication or if you require certificate authentication against a centralized AAA backend server.

As EAP-TLS authenticates the client and the EAP server mutually, it is possible to skip IKEv2 server authentication and use the EAP-only authentication mechanism.

Compatibility

The EAP-TLS backend uses its own TLS stack shipped with strongSwan. This stack supports TLS versions 1.0, 1.1 and 1.2 and has been tested against:

- OpenSSL 0.9.8 server via FreeRADIUS EAP-TLS (TLS 1.0)
- Windows 7 client via IKEv2 EAP-TLS (TLS 1.0)
- Windows 7 client via IE9 (TLS 1.0, 1.1, 1.2)
- GnuTLS server via Apache mod_gnutls (TLS 1.1)
- NSS client via Firefox 3.6.8 (TLS 1.0)
- Self (TLS 1.0, 1.1, 1.2)

Installation

To enable EAP-TLS, pass --enable-eap-tls to the ./configure options.

Configuration

Connections

EAP-TLS is configured as any other EAP method. The client uses leftauth=eap, the server selects EAP-TLS for the client using rightauth=eap-tls. strongSwan supports AAA backend servers via RADIUS, rightauth=eap-radius also works in conjunction with EAP-TLS.

By default, the Gateway uses IKEv2 certificate authentication to prove its identity to the clients. But as EAP-TLS is a mutual authentication protocol, EAP-only authentication can be used by specifying leftauth=eap.

Certificates for EAP-TLS are configured the same way as for traditional IKEv2 certificate authentication, using ipsec.d/cacerts, ipsec.secrets and leftcert=/rightcert=. CRL and OCSP revocation is supported in TLS, too.

If a Gateway uses different certificates for IKEv2 and for EAP-TLS authentication, the EAP-TLS certificate may be loaded using the leftcert2= keyword.

For authentication against an AAA backend server, the Gateway usually uses a different identity in IKE than the AAA backend in EAP. To specify a different AAA identity on the client, the new aaa_identity ipsec.conf keyword has been introduced. It defaults to the IKEv2 identity defined with rightid. A Gateway terminating the EAP-TLS authentication locally may use the aaa_identity within EAP-TLS, but requires a certificiate with such a subject/subjectAltName.

EAP-TLS options

The EAP-TLS plugin has an option in strongswan.conf to control the fragment size:

charon {
  # ...
  plugins {
    eap-tls {
      fragment_size = 512
    }
  }
}

The default fragment size is 1024 bytes.

TLS stack options

There is usually no cipher suite configuration required, the TLS stack enables all secure algorithms that it has registered crypto backends for. Depending on the plugin configuration, the TLS stack supports the following cipher suites:

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_NULL_SHA,
TLS_ECDHE_RSA_WITH_NULL_SHA,
TLS_RSA_WITH_NULL_SHA,
TLS_RSA_WITH_NULL_SHA256,
TLS_RSA_WITH_NULL_MD5,

DSA, ECDH and DH suites are currently not supported, ECDHE and ECDSA require the openssl crypto backend. ECDHE support is limited to the named curves SECP256R1, SECP384R1, SECP521R1, SECP224R1 and SECP192R1 with uncompressed points. CAMELLIA encryption requires either the openssl or gcrypt backend.

The NULL encryption suites are used by EAP-TLS, as only the handshake of TLS is used. NULL encryption is automatically disabled if the stack is used for other purposes.

To limit the cipher suite set by algorithm, there are three strongswan.conf options:

libtls {
  key_exchange = ecdhe-ecdsa, ecdhe-rsa, dhe-rsa, rsa
  cipher = aes128, aes256, camellia128, camellia256, 3des, null
  mac = md5, sha1, sha256, sha384
}

Only cipher suites using the specified algorithms are enabled, the configuration above currently enables all supported suites.

To specify the list of suites directly, use the suites option and a comma separated list of the cipher suites above:

libtls {
  suites = TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
}