While this is mostly theoretical, the hash functions can fail and it is
better for the upper layer code to explicitly check for such failures.
Signed-off-by: Jouni Malinen <j@w1.fi>
Do not try to derive a PMK-R0 and PMK-R1 again for the case where an
association was started with FT protocol and PTK is rekeyed using 4-way
handshake. Instead, use the previously derived PMK-R1 to allow a new PTK
to be derived.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Do not try to derive a PMKID for EAPOL-key msg 1/4 when going through
4-way handshake to rekey PTK during an association that was started
through FT protocol.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is needed to allow PTK rekeying to be performed through 4-way
handshake in an association started through FT protocol.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is needed to avoid leaving some timers (e.g., for PTK rekeying)
running afrer a STA has disassociated.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
FT rules for PTK derivation do not use PMK. Remove the unused argument
to the PTK derivation function.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
There is no PMK/PMKID when going through 4-way handshake during an
association started with FT protocol, so need to allow the operation to
proceed even if there is no selected PMKSA cache entry in place.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The PMK and PMKID information from FILS ERP and FILS PMKSA caching needs
to be stored within struct wpa_state_machine for PTK to work. Without
this, PTK derivation would fail and attempt to go through rekeying would
result in disconnection. Furthermore, wpa_rekey_ptk() timer needs to be
started at the completion of FILS association since the place where it
was done for non-FILS cases at the end of 4-way handshake is not reached
when FILS authentication is used.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
All nla_put*() operations should be verified to succeed, so check this
recently added one for NL80211_ATTR_EXTERNAL_AUTH_SUPPORT.
Fixes: 236e793e7b ("nl80211: External authentication in driver-based AP SME mode")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Commit 4b16c15bbc ("EAP-pwd server: Use os_get_random() for
unpredictable token") replaced use of os_random(), i.e., of random(),
with os_get_random(), but forgot to remove the now unused srandom()
call. Clean up the implementation and remove that unneeded code.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Unexpected fragment might result in data->inbuf not being allocated
before processing and that could have resulted in NULL pointer
dereference. Fix that by explicitly checking for data->inbuf to be
available before using it.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
data->inbuf allocation might fail and if that were to happen, the next
fragment in the exchange could have resulted in NULL pointer
dereference. Unexpected fragment with more bit might also be able to
trigger this. Fix that by explicitly checking for data->inbuf to be
available before using it.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Report failure from getKey() if MSK cannot be derived due to unexpected
sha1_vector() local failure.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
There are number of deployed APs with broken PMF implementation where
the IGTK KDE uses swapped bytes in the KeyID field (0x0400 and 0x0500
instead of 4 and 5). Such APs cannot be trusted to implement BIP
correctly or provide a valid IGTK, so do not try to configure this key
with swapped KeyID bytes. Instead, continue without configuring the IGTK
so that the driver can drop any received group-addressed robust
management frames due to missing keys.
Normally, this error behavior would result in us disconnecting, but
there are number of deployed APs with this broken behavior, so as an
interoperability workaround, allow the connection to proceed.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Previously wpa_supplicant_key_neg_complete() was called before the
attempt to configure the IGTK received from the authenticator. This
could resulted in somewhat surprising sequence of events if IGTK
configuration failed since completion event would be followed by
immediate disconnection event. Reorder these operations so that
completion is reported only if GTK and IGTK are configurated
successfully.
Furthermore, check for missing GTK KDE in case of RSN and handle that
with an explicit disconnection instead of waiting for the AP to deliver
the GTK later.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
In case of drivers that don't use wpa_supplicant as SME, autoscan
feature was never disabled.
Signed-off-by: Wiktor Drewniak <wiktor.drewniak@gmail.com>
For reassociation with the same AP wpa_supplicant attempts to use cached
PMKSA. For this purpose PMKID is passed in RSNE in (Re)Association
Request frame. In the case of SAE AP, open authentication shall be used
during reassociation. Otherwise cached PMKID becomes invalid after full
SAE authentication.
The previous implementation correctly handles SME-in-wpa_supplicant
cases. However SME-in-driver cases, complete SAE authentication is
performed. As a result, first reassociation attempt fails.
Fix SME-in-driver behavior by reseting authentication algorithm to
WPA_AUTH_ALG_OPEN when reassociating with SAE AP with an existing PMKSA
cache entry.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
When FILS authentication is used with ERP, no EAPOL frames are expected
after association. However, for drivers that set the
WPA_DRIVER_FLAGS_4WAY_HANDSHAKE_8021X capability flag, the EAP state
machine was not configured correctly and was waiting for EAPOL frames,
which leads to disconnection.
Fix this by reordering the if branches to set the EAPOL/EAP state
machines to success when FILS authentication was already completed.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
When processing the NL80211_CMD_PROBE_CLIENT command response, the
nl80211 layer in the kernel sends a response containing the cookie
associated with the client probe request. This response was not handled
by driver_nl80211.c when sending the command, and it was mistakenly
handled as an asynchronous event. This incorrect event did not include
the MAC/ACK attributes, so it was ignored in practice, but nevertheless,
the command response should not be processed as an event.
Fix this by reading the response as part of the sending the command
flow.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Include the MAC address of the peer, knowledge of whether the poll was
ACKed, and cookie into the debug message to make this more useful.
Signed-off-by: Jouni Malinen <j@w1.fi>
Remove FT IEs clearing from sme_deinit() as it is done twice. The
sme_clear_on_disassoc() call to sme_update_ft_ies() takes care of this.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
SA Query wasn't stopped after disconnection, which could potentially
result in an unexpected SA timeout firing later when already connected
to another AP. Fix that by stopping SA Query when an association is
terminated.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
pending_p2ps_group flag is not always cleaned, which may later result
in an unexpected GO bring up, after PD response is transmitted in
wpas_prov_disc_resp_cb().
This can be seen when running the following hwsim tests together:
- p2ps_channel_sta_connected_disallow_freq_mcc
- p2ps_channel_active_go_and_station_different_mcc
Fix this by clearing pending_p2ps_group flag also when processing new
PD requests. In addition, set this flag only when really needed.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
It looks like it is possible for the RECEIVE state to leak memory where
a previously allocated sm->lki is moved to sm->oki while sm->oki is
pointing to not yet freed entry. It is not clear how this can be
triggered, but it has come up in hwsim testing under heavy load.
Free sm->oki if it is still set in RECEIVE before replacing it with
sm->lki to avoid this memory leak.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
