Ready for 2.2.7?

[Jouni Malinen]

On Tue, Mar 31, 2015 at 5:01 PM, Arran Cudbard-Bell
<a.cudbardb at freeradius.org> wrote:

> It means that session resumption works against a cluster of RADIUS servers
> with a front end load balancer, without the need for a common session data
> store.
>
> Granted, that's only strictly true for EAP-TLS and EAP-TTLS/PEAP (if
> anonymous outer identities are disallowed), but it's still useful.
> An option to allow it would be appreciated.

It should actually already be possible to enable this by adding
phase1="tls_disable_session_ticket=0" into the network profile in
wpa_supplicant/eapol_test. This workaround (of not sending session
ticket) can also be disabled with eap_workaround=0, but it looks like
that actually results in other issues with FreeRADIUS (mismatch in
EAP-MSCHAPv2 header length when used within PEAP), so at least for
now, the phase1 parameter to do this looks like the way to go, if you
want to use TLS session ticket.

> If OpenSSL presented a sane API or serialised ex_data, we could've embedded
> the session-state list in the ticket, and stored the inner identity too.
> That would have negated the need for a common database or store for anonymous
> outer identities. Unfortunately OpenSSL doesn't do either of those things...

I've done something similar with EAP-FAST, but that is all handled
outside OpenSSL.

> I've tested the case where the client presents the session ticket extension
> and support is not enabled on the server, it doesn't cause issues, at least
> not with OpenSSL 1.0.1f. Other SSL implementations or versions might not be
> so forgiving.

I don't know which TLS implementation is involved in the problem cases
or whether the EAP server implementation manages to break this on  its
own. Anyway, none of the reported interop issues with TLS session
ticket extension have been with FreeRADIUS.

- Jouni