Ready for 2.2.7?

[Jouni Malinen]

On Tue, Mar 31, 2015 at 3:17 AM, Arran Cudbard-Bell
<a.cudbardb at freeradius.org> wrote:
>
>> On 30 Mar 2015, at 20:09, Matthew Newton <mcn4 at 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