On Tue, Mar 31, 2015 at 3:17 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 30 Mar 2015, at 20:09, Matthew Newton <mcn4@leicester.ac.uk> wrote: Compatibility with what?
eapol_test, booo.
Compatibility with any correct TLSv1.2 -based implementation..
Noticed today that with TLS 1.2 FR and eapol_test 2.4 (and so presumably wpa_supplicant) disagreed on the MPPE keys. Not sure where the fault lies there. Both were running on the same machine, linked against the same version of OpenSSL.
FreeRADIUS has incorrect key derivation for TLSv1.2. eaptls_gen_mppe_keys() has not taken into account that the PRF algorithm changes in the new TLS version. That PRF() call there would need to be modified to take into acocunt that difference between TLS versions. Or likely much more easily, you could move to using SSL_export_keying_material() whenever building with OpenSSL 1.0.1 or newer. That has some complexities for EAP-FAST (not supported by that OpenSSL function because someone thought that it would be create to design EAP-FAST in a way that is different from others..). Anyway, EAP-FAST is not supported yet by FreeRADIUS and has interop issues with TLS v1.2 anyway, so it is unclear when it is going to need new key derivation.. wpa_supplicant, and as such, eapol_test, too, uses SSL_export_keying_material() in this case to get the correct keys out from OpenSSL.
Only allowing TLS 1.0 and 1.1 fixed the problem.
Well, yes. That avoids the case where eaptls_gen_mppe_keys() needs to use another PRF.
eapol_test also doesn't send the RFC 5077 session ticket extension in the client hello. Stupid eapol_test *grumble*.
If only the deployed authentication servers were to support TLS extensions.. Clients have to disable session tickets due to so many broken RADIUS servers out there with TLS implementation rejecting any attempt to connect with such an extension included. - Jouni