On Wed, Dec 02, 2015 at 12:46:03PM +0500, mutahir latif wrote: > I am trying to use enterprise wifi on an embedded device. My setup contains > the following things: > - Embedded device with wpa_supplicant 2.5 > - TP-link router configured for WPA2 > - Free-radius server Based on the debug log, it looks like you are using FreeRADIUS v3.0.10. Which OpenSSL version is this built with? On the client side, wpa_supplicant was apparently built against GnuTLS 2.12.23. Short answer: This is a bug in the OpenSSL version used on the server that runs FreeRADIUS. Update to OpenSSL 1.0.1h or newer (and well, you should really go to the latest version to get all security issues resolved). If you have to work around this on the client side, updating the GnuTLS version to 3.0.x or newer hides this issue. Long answer: This turned out to be significantly more complex than I assumed in the beginning.. I'm leaving my notes below for anyone who wants to go through the details. It took something like 90 minutes to write this email.. :) > I am getting a PMKID mismatch issue. Please find the wpa_supplicant.conf > file and the wpa_supplicant log attached here. The most common reason for this "RSN: PMKID mismatch - authentication server may have derived different MSK?!" error has been a bug in the authentication server when using TLS v1.2. However, you seem to be using FreeRADIUS v3.0.10 which should have those issues fixed.. Interestingly, I did not see any issues when testing a wpa_supplicant build against GnuTLS v2.12.23 (from Ubuntu 14.04) and hostapd as the authentication server. However, when I replaced the authentication server with FreeRADIUS v3.0.10 (against OpenSSL 1.0.1f-ubuntu2.15), I see something that looks quite similar to what you have in the debug log. However, that is not the case when using wpa_supplicant built with OpenSSL or a newer version of GnuTLS. This would seem to imply that there is likely something wrong with the combination of wpa_supplicant with that old GnuTLS version. I don't even have that old GnuTLS version in my normal test set and all the versions I tried between GnuTLS 3.0.0 and 3.3.14 worked fine for this. I added 2.12.23 to the list of my own builds and was able to reproduce the issue with it. The strange thing here is that I did not see this issue when using hostapd as the authentication server.. However, now that I ran a test with the Ubuntu package of OpenSSL 1.0.1f-ubuntu2.15 used in hostapd build, this issue showed up. So the magic combination seems to be OpenSSL 1.0.1f-ubuntu2.15 on the authentication server side and GnuTLS 2.12.23 on the client side. I was able to reproduce this with upstream OpenSSL 1.0.1f package and similarly with 1.0.1g, but not with 1.0.1h. Running a diff between those versions shows a change in tls1_export_keying_material() which is the most likely reason for this interop issue. The relevant OpenSSL commit is this one: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4fdf917 Which was reported in this ticket: https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3319 The difference in behavior between GnuTLS versions is due to different cipher suite getting selected. GnuTLS 3.0.x added support for GCM cipher suites and apparently OpenSSL 1.0.1f SSL_export_keying_material() worked correctly with TLS v1.2 when such a GCM cipher suite was selected (TLS_RSA_WITH_AES_128_GCM_SHA256 0x009c in the specific test case I saw) while the same function failed is an older cipher suite was selected (TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0x0033 in my test case). This is yet another lovely addition to the EAP-TLS/PEAP/TTLS PRF issues with TLS v1.2. It's going to be interesting to see how easily this can be fixed on the server side since this time this depends on fixing an OpenSSL bug with distros maintaining some ancient baseline version like 1.0.1f. Would need to get any such distro pulling in this fix: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4fdf917 (which was not even mentioned in the OpenSSL 1.0.1h change log..) -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
