[RADIATOR] EAP authentication using TLSv1.2 with OpenSSL 1.0.1f or 1.0.1g based servers may fail

Heikki Vatiainen 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 
access point/controller.

For the details, please see this message on the hostapd/wpa_supplicant 
mailing list:


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,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, 
NetWare etc.

More information about the radiator mailing list