Message ID | 1436367657.15083.45.camel@infradead.org |
---|---|
State | Not Applicable |
Headers | show |
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.
--- 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;