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: http://lists.infradead.org/pipermail/hostap/2015-December/034297.html 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 <h...@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, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
