Opportunistic Key Caching on wpa_supplicant

Jouni Malinen j at w1.fi
Sun Oct 2 12:40:40 EDT 2011


On Wed, Sep 21, 2011 at 09:26:45PM -0400, Matt Causey wrote:
> So this time, I was constantly re-authing successfully until the PMK
> expiration timer on the controller fired, and nuked the PMK for my
> station.  After that, all of the supplicant's attempts to use its
> internal PMK would fail.

This seems to be the key problem here.. I went through the debug log
from wpa_supplicant (the one that was too long for the mailing list) and
this particular issue shows up at 1317159147.145598. It looks like you
need two things to trigger this: full re-authentication to change the
PMK and then returning to an AP with which the previous PMK had been
used. The first connection generated the PMKSA cache entry in the
successful OKC attempt. The PMK ended up getting updated when connected
to another AP. However, I think that that did not clear the old PMKSA
cache entry for the other AP. Consequently, when going back to that AP,
the old entry with the old PMKID was used. This wasn't valid anymore at
the AP and it rejected the use of PMKSA caching and forced full
authentication.

I would assume that the PMKSA entry got updated for the AP through which
the full authentication, but not to the other APs that could have used
the same PMK in OKC.

Supplicant does not really know what the expiration time of the PMK is,
so this is something that can happen in practice even without OKC.
Anyway, it should be possible improve the current behavior by better
tracking of which PMKSA cache entries got created opportunistically
based on the PMK that got updated and then remove those PMKSA cache
entries. This would allow OKC to re-create them when the AP is seen the
next time and should avoid this issue. Actually, the tracking part is
already in place and there are some other cases where the PMKSA cache
entries do get cleared. However, this is not currently triggered in the
case the PMK gets updated.

I haven't yet had a chance to test this, so if you can re-run your
test, I would appreciate hearing whether this change fixes the issues
you were seeing:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=c3fea272747f738f5723fc577371fe03711d988f

-- 
Jouni Malinen                                            PGP id EFC895FA


More information about the HostAP mailing list