Unable to connect to WPA2-Enterprise since 2.4-r1: WPA_ALG_PMK bug?

[Jouni Malinen]

On Wed, Jul 08, 2015 at 04:00:57PM +0100, David Woodhouse wrote:
> On Mon, 2015-05-04 at 23:46 +0300, Jouni Malinen wrote:
> > That message has nothing to do with this issue. The real error is
> > identified by the "RSN: no PMKSA entry found - trigger full EAP
> > authentication" message following the EAP exchange. In practice, this
> > indicates that the authentication server and wpa_supplicant derived
> > different MSK from the EAP authentication.
> 
> Right. Almost certainly because it has the same problem as FreeRADIUS
> 2.2.6, and uses the wrong PRF for TLS 1.2.

Yes.. This seems to be quite common bug in EAP-TLS/TTLS/PEAP
implementations. I just hope that the correct implementation "wins"
rather sooner than later to make this a long standing interop issue that
requires a workaround to be maintained for years..

It is kind of unexpected that the FreeRADIUS 2.2.6 case gets hit since
that is the old release series and it would require OpenSSL on the
server to be updated to 1.0.2 version to get TLS v1.2 enabled. Maybe
some common distro has selected that combination(?). I've been lazy
enough to even test this with FreeRADIUS 2.2.6 since I don't have
OpenSSL 1.0.2 as the default system library anywhere.. :)

> Since Fedora updated to wpa_supplicant 2.4, I'm now getting reports
> from across the company that access to the corporate wifi is failing.
> 
> I've internally shipped a version of wpa_supplicant with commit
> 35efa2479f reverted for now, to get people working.

That's probably fine for now, but there is desire to get rid of TLS v1.0
(and v1.1 for that matter) eventually..

> I believe we're using Cisco ISE; I'm talking to the IT people to
> confirm that, and the version ? obviously with a view to getting it
> fixed, but this being Cisco it could take *months* before we even
> manage to get them to reproduce it in-house and accept that it's a
> problem?.

If you can get a clearly identifiable version information for a server
that uses something else than FreeRADIUS 2.2.6 or 3.0.7 and shows this
same issue with TLS v1.2, that would be interesting to hear about. There
might be sufficient justification to add a workaround in wpa_supplicant
for this if the issue is indeed widespread and does not show any clear
signs of going away in the near term with majority of client devices not
supporting TLS v1.2 yet.

> Well.... this "works":
> 
> --- a/src/crypto/tls_openssl.c
> +++ b/src/crypto/tls_openssl.c
> @@ -2648,7 +2648,7 @@ int tls_connection_prf(void *tls_ctx, struct tls_connection *conn,
>                        const char *label, int server_random_first,
>                        u8 *out, size_t out_len)
>  {
> -#if OPENSSL_VERSION_NUMBER >= 0x10001000L
> +#if 0// OPENSSL_VERSION_NUMBER >= 0x10001000L

With some strange values of "working".. :) This is actually showing that
the older (OpenSSL backwards compatibility) MSK derivation in
wpa_supplicant has the same bug if there were an OpenSSL version that
supports TLSv1.2 without the SSL_export_keying_material() API (though,
such a version does not exist). Anyway, yes, wpa_supplicant could
certainly derive the incorrect MSK with TLS v1.2, if desired, to match
at least the version that FreeRADIUS 2.2.6 and 3.0.7 use.

> Now, obviously I'm not suggesting that as a viable solution. But
> perhaps it points to a potential workaround. What if we calculate
> *both* the incorrect and the correct PMK, and add *both* to the PMKSA
> cache in wpa_supplicant_get_pmk()?
> 
> Then it'll silently work with both broken and sane authenticators.

Yes, that's likely the best approach to use as the default behavior
(with a config option to disable this workaround) for some time if the
conclusion is that it is significantly easier to modify wpa_supplicant
on the clients than the authentication server... (Which would be a bit
sad, but potentially true in some cases.)

> Obviously that's *horrid*, and I'm going to have to autoflagellate for
> even thinking it. We'd only even want to contemplate it if the problem
> really is widespread enough to warrant such. There really *is* a lot of
> merit in saying "Your kit is crap. Get something better from someone
> who actually provides decent support."

What I'm worried about is that some of the other client supplicant
vendors could come up with implementations that have the same issue
and this mess could remain in place for years.. As such, there is some
benefit in making sure wpa_supplicant rejects the connection rather than
hide the issue if there is any chance of that resulting in sufficient
complaints to get the authentication server fixed.

That said, I might need to change the debug messages to make it much
clearer that the issue in this case is most likely in mismatching MSK
rather than something specific to PMKSA caching..

> A variant on this workaround idea is that we don't just add the 'wrong'
> one to the PMKSA cache, but we add some kind of 'poison' instead, which
> if matched will trigger a fallback to TLSv1.1. But given that falling
> back to TLSv1.1 will cause us to use the old PRF *anyway*, it's not
> clear that there's any real benefit in doing it that way instead...

Probably not.. This is likely more complex and I don't think the
possibility of using HMAC-SHA1+MD5-based PRF after a successfully
completed TLS v1.2 exchange would be that horrible price to pay as a
temporary (hopefully..) interop workaround.
 
-- 
Jouni Malinen                                            PGP id EFC895FA