PMKID mismatch

[Jouni Malinen]

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