eap-tls Plugin

Purpose

The eap-tls plugin for libcharon supports EAP-TLS authentication. EAP-TLS uses a TLS handshake to mutually authenticate client and server (or an AAA backend) based on X.509 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 based 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.

The plugin is disabled by default and can be enabled with the ./configure option

--enable-eap-tls

Compatibility

The EAP-TLS backend uses its own TLS stack shipped with strongSwan. This stack supports TLS versions 1.0, 1.1, 1.2, and 1.3 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, 1.3)

Configuration

Connections

EAP-TLS is configured as any other EAP method. The client uses

connections.<conn>.local.auth = eap

and the server selects EAP-TLS for the client using

connections.<conn>.remote.auth = eap-tls

strongSwan supports AAA servers via RADIUS, i.e.

connections.<conn>.remote.auth = eap-radius

also works in conjunction with EAP-TLS.

By default the VPN 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

connections.<conn>.local.auth = eap

on the gateway side.

Certificates for EAP-TLS are configured the same way as for traditional IKEv2 certificate-based authentication, using the swanctl certificate and key directories as well as the swanctl.conf definitions

connections.<conn>.local.certs

and

connections.<conn>.remote.certs

on VPN client and gateway, respectively. CRL and OCSP revocation is supported by TLS, too.

For authentication against an AAA backend server, the VPN gateway usually uses a different identity via IKE than the AAA backend via EAP. To specify a different AAA identity on the client use the swanctl.conf attribute

connections.<conn>.local.aaa_id

It defaults to the IKEv2 identity defined by

connections.<conn>.remote.id

A VPN gateway terminating the EAP-TLS authentication locally may use the aaa_id within EAP-TLS but requires a certificate with such a subject or subjectAltName.

EAP-TLS Options

The eap-tls plugin is configured using the following options in the charon.plugins.eap-tls section of strongswan.conf:

Key Default Description

fragment_size

1024

Maximum size of an EAP-TLS packet

include_length

yes

Include length in non-fragmented EAP-TLS packets

max_message_count

32

Maximum number of processed EAP-TLS packets (0 = no limit)

TLS Options

The eap-tls plugin uses the strongSwan libtls library that can be configured and fine-tuned with the following TLS options.

Examples

topology
Figure 1. strongSwan example showing the use of EAP-TLS only authentication.
topology
Figure 2. strongSwan example showing the use of EAP-TLS with AAA server.