When looking for PMKSA cache entries to use with a new association, only
accept entries created with the same network block that was used to
create the cache entry.
Signed-hostap: Jouni Malinen <j@w1.fi>
This makes it clearer that the PMKSA caching entry gets removed from
the driver regardless of how the internal entry from wpa_supplicant
gets cleared. In practice, this call was skipped only for the case
when the entry for the current AP was being updated, so the previous
version was likely to work with all drivers. Anyway, it is cleaner
to explicitly remove the old entry even in that case before the new
entry gets added.
Signed-hostap: Jouni Malinen <j@w1.fi>
Whenever PMK gets changed (e.g., due to re-authentication), all PMKSA
caching entries that were created using the previous PMK needs to be
replaced. Previously, only the entry for the current AP was cleared.
Flush the other entries based on network_ctx matches to get rid of the
OKC entries. These entries can then be re-creating using OKC with the
new PMK.
If a network configuration block is removed or modified, flush
all PMKSA cache entries that were created using that network
configuration. Similarly, invalidate EAP state (fast re-auth).
The special case for OKC on wpa_supplicant reconfiguration
(network_ctx pointer change) is now addressed as part of the
PMKSA cache flushing, so it does not need a separate mechanism
for clearing the network_ctx values in the PMKSA cache.
If the driver maintains its own copy of the PMKSA cache, we need to
clear an entry from the driver whenever wpa_supplicant is dropping
an old PMKSA cache entry.
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
IEEE 802.11w/D6.0 defines new AKMPs to indicate SHA256-based algorithms for
key derivation (and AES-CMAC for EAPOL-Key MIC). Add support for using new
AKMPs and clean up AKMP processing with helper functions in defs.h.
