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 |
|
Maximum size of an EAP-TLS packet |
include_length |
|
Include length in non-fragmented EAP-TLS packets |
max_message_count |
|
Maximum number of processed EAP-TLS packets ( |
TLS Options
The eap-tls plugin uses the strongSwan libtls library that can be
configured and fine-tuned with the following TLS options.
