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

[David Woodhouse]

On Mon, 2015-05-04 at 23:46 +0300, Jouni Malinen wrote:
> On Mon, May 04, 2015 at 06:59:41PM +0200, Ralf Ramsauer wrote:
> > Freeradius 2.2.6 fails to connect with
> > 
> >     May 04 17:43:03 lefay wpa_supplicant[642]: nl80211: Unexpected
> >     encryption algorithm 5
> 
> 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.

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.

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?.


> > But keep in mind, in most cases people do not have access to the wifi
> > backend :)
> 
> Maybe so, but the real issue here was in the authentication server and
> there is not really much that the client side can do to fix that.


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
        SSL *ssl;
        if (conn == NULL)
                return -1;

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.

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."

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...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

? It recently took Cisco about 5 months just to accept a bug report? about their VPN server dropping UDP packets for the heinous crime of? being received out-of-order, despite the conversation starting with? a clear diagnosis, a reference to the OpenSSL PR in which it was? fixed, and instructions on reproducing it. And we *still* don't?? actually have a *fix*.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20150708/59e584b9/attachment-0001.bin>