[RADIATOR] EAP authentication using TLSv1.2 with OpenSSL 1.0.1f or 1.0.1g based servers may fail
hvn at open.com.au
Thu Dec 17 08:14:33 CST 2015
Hello list members. It has come to our attention that TLS based EAP
methods, such as EAP-TLS, EAP-TTLS and PEAP, may fail in some cases.
The currently verified failure case is this:
- Client wishes to use TLSv1.2 and the server agrees to do so, and
- Radiator on the server uses OpenSSL 1.0.1f or 1.0.1g, and
- The client supports certain TLS cipher suites.
The above was verified with Ubuntu 14.04 as the server and
wpa_supplicant with GnuTLS 2.12.23 as the client.
When this happens, the server derives incorrect keying material. The
keying material is typically used to create the Wi-Fi encryption keys
returned with MPPE-Recv-Key and MPPE-Send-Key RADIUS attributes. As the
result, the client authenticates normally but is unable to access the
network because of the key mismatch between the client and the Wi-Fi
For the details, please see this message on the hostapd/wpa_supplicant
By default Radiator 4.14 and later support all TLS versions for TLS
based EAP methods. To configure Radiator not to use TLSv1.2, use the
EAPTLS_Protocols configuration parameter. For example: to allow TLSv1
and TLS1.1 only:
EAPTLS_Protocols TLSv1, TLSv1.1
See section '5.21.33 EAPTLS_Protocols' in the Radiator 4.16 reference
manual for more information.
We are considering a patch in Radiator that disables TLSv1.2 for EAP if
the OpenSSL version is one of the above.
Thanks to Nick Lowe for letting us know about this.
Heikki Vatiainen <hvn at open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
More information about the radiator