wpa_supplicant disables PMKSA caching with FT-EAP by default due to
known interoperability issues with APs. This is allowed only if the
network profile is explicitly enabling caching with
ft_eap_pmksa_caching=1. However, the PMKID for such PMKSA cache entries
was still being configured to the driver and it was possible for the
driver to build an RSNE with the PMKID for SME-in-driver cases. This
could result in hitting the interop issue with some APs.
Fix this by skipping PMKID configuration to the driver fot FT-EAP AKM if
ft_eap_pmksa_caching=1 is not used in the network profile so that the
driver and wpa_supplicant behavior are in sync for this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Convert the previously used text log entries to use the more formal
OCV-FAILURE prefix and always send these as control interface events to
allow upper layers to get information about unexpected operating channel
mismatches.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Make reporting of OCV validation failure reasons more flexible by
removing the fixed prefix from ocv_verify_tx_params() output in
ocv_errorstr so that the caller can use whatever prefix or encapsulation
that is most appropriate for each case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
To support the STA testbed role, the STA has to use specified channel
information in OCI element sent to the AP in EAPOL-Key msg 2/4, SA Query
Request, and SA Query Response frames. Add override parameters to use
the specified channel while populating OCI element in all these frames.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
It was possible for the RSN state machine to maintain old PMKSA cache
selection (sm->cur_pmksa) when roaming to another BSS based on
driver-based roaming indication. This could result in mismatching state
and unexpected behavior, e.g., with not generating a Suite B PMKSA cache
entry.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
"SET dpp_version_override <ver>" can now be used to request
wpa_supplicant and hostapd to support a subset of DPP versions. In
practice, the only valid case for now is to fall back from DPP version 2
support to version 1 in builds that include CONFIG_DPP2=y.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Do not allow association to continue if the local configuration enables
PFS and the station indicates it supports PFS, but PFS was not
negotiated for the association.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new "dpp_pfs=1" entry can be used to determine whether PFS was used
during derivation of PTK when DPP AKM is negotiated for an association.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Check AP's DPP Protocol Version during network introduction and mark the
PMKSA cache as suitable for PFS use with version 2 or newer. This avoids
unnecessary attempt of negotiating PFS with version 1 APs.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Allow wpa_supplicant to be requested to override the RSNXE Used subfield
in FT reassociation case for testing purposes with "SET ft_rsnxe_used
<0/1/2>" where 0 = no override, 1 = override to 1, and 2 = override to
0.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Drivers that trigger roaming need to know the lifetime and reauth
threshold time of configured PMKSA so that they can trigger full
authentication to avoid unnecessary disconnection. To support this, send
dot11RSNAConfigPMKLifetime and dot11RSNAConfigPMKReauthThreshold values
configured in wpa_supplicant to the driver while configuring a PMKSA.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Check whether the Transition Disable KDE is received from an
authenticated AP and if so, whether it contains valid indication for
disabling a transition mode. If that is the case, update the local
network profile by removing the less secure options.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Support Extended Key ID in wpa_supplicant according to
IEEE Std 802.11-2016 for infrastructure (AP) associations.
Extended Key ID allows to rekey pairwise keys without the otherwise
unavoidable MPDU losses on a busy link. The standard is fully backward
compatible, allowing STAs to also connect to APs not supporting it.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
This was not supposed to be conditional on CONFIG_FILS.
Fixes: ecbf59e693 ("wpa_supplicant configuration for Beacon protection")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous design for adding RSNXE into FT was not backwards
compatible. Move to a new design based on 20/332r3 to avoid that issue
by not include RSNXE in the FT protocol Reassociation Request frame so
that an AP not supporting RSNXE can still validate the FTE MIC
correctly.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Verify that the AP included RSNXE in Beacon/Probe Response frames if it
indicated in FTE that RSNXE is used. This is needed to protect against
downgrade attacks based on the design proposed in 20/332r3.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is a workaround needed to keep FT protocol backwards compatible for
the cases where either the AP or the STA uses RSNXE, but the other one
does not. This commit adds setting of the new field to 1 in
Reassociation Request/Response frame during FT protocol when the STA/AP
uses RSNXE in other frames. This mechanism is described in 20/332r3.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
While 13.7.1 (FT reassociation in an RSN) in P802.11-REVmd/D3.0 did not
explicitly require this to be done, this is implied when describing the
contents of the fourth message in the FT authentication sequence (see
13.8.5). Furthermore, 20/332r2 is proposing an explicit validation step
to be added into 13.7.1.
Signed-off-by: Jouni Malinen <j@w1.fi>
While there may have initially been cases where the RSNE from
Beacon/Probe Response frames was not available from some drivers, it is
now more valuable to notice if such a case were to be hit with drivers
that are always expected to have such information available. As such,
make it a fatal error if the scan results for the current AP are not
available to check the RSNE/RSNXE in EAPOL-Key msg 3/4.
Signed-off-by: Jouni Malinen <j@w1.fi>
Avoid printing confusing FT debug entries from wpa_sm_set_ft_params()
when FT is not actually used for the connection.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use the same reason code to indicate that IE different in 4-way
handshake and also print a hexdump of RSNXE in both Beacon/ProbeResp and
EAPOL-Key msg 3/4 in the log.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_tdls_set_key() did set the key_id to -1 to avoid a useless
NL80211_CMD_SET_KEY call that the updated nl80211 driver no longer
carries out. Remove the no longer required workaround.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
The initial implementation of the PTK derivation workaround for
interoperability with older OWE implementations forced
WPA_KEY_MGMT_PSK_SHA256 to be used for all of PTK derivation. While that
is needed for selecting which hash algorithm to use, this was also
changing the length of the PTK components and by doing so, did not
actually address the backwards compatibility issue.
Fix this by forcing SHA256 as the hash algorithm in PTK derivation
without changing the PTK length calculation for OWE when
owe_ptk_workaround is enabled.
Fixes: 65a44e849a ("OWE: PTK derivation workaround in AP mode")
Fixes: 8b138d2826 ("OWE: PTK derivation workaround in STA mode")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
IEEE P802.11az/D2.0 renamed the FILS Wrapped Data element,
removing the FILS prefix. Change the code accordingly.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Since SAE PMK can be updated only by going through a new SAE
authentication instead of being able to update it during an association
like EAP authentication, do not allow PMKSA entries to be used for
caching after the reauthentication threshold has been reached. This
allows the PMK to be updated without having to force a disassociation
when the PMK expires if the station roams between the reauthentication
threshold and expiration timeout.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Since SAE PMK can be updated only by going through a new SAE
authentication instead of being able to update it during an association
like EAP authentication, do not allow PMKSA entries to be used for OKC
after the reauthentication threshold has been reached. This allows the
PMK to be updated without having to force a disassociation when the PMK
expires if the station roams between the reauthentication threshold and
expiration timeout.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
SAE authentication derives PMKID differently from the EAP cases. The
value comes from information exchanged during SAE authentication and
does not bind in the MAC addresses of the STAs. As such, the same PMKID
is used with different BSSIDs. Fix both the hostapd and wpa_supplicant
to use the previous PMKID as is for OKC instead of deriving a new PMKID
using an incorrect derivation method when using an SAE AKM.
This fixes use of opportunistic key caching with SAE.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Rekeying a pairwise key using only keyid 0 (PTK0 rekey) has many broken
implementations and should be avoided when using or interacting with
one. The effects can be triggered by either end of the connection and
range from hardly noticeable disconnects over long connection freezes up
to leaking clear text MPDUs.
To allow affected users to mitigate the issues, add a new configuration
option "wpa_deny_ptk0_rekey" to replace all PTK0 rekeys with fast
reconnects.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
Add a new wpa_supplicant network profile configuration parameter
beacon_prot=<0/1> to allow Beacon protection to be enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Initial OWE implementation used SHA256 when deriving the PTK for all OWE
groups. This was supposed to change to SHA384 for group 20 and SHA512
for group 21. The new owe_ptk_workaround=1 network parameter can be used
to enable older behavior mainly for testing purposes. There is no impact
to group 19 behavior, but if enabled, this will make group 20 and 21
cases use SHA256-based PTK derivation which will not work with the
updated OWE implementation on the AP side.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add the new set_key() parameter "key_flag" to provide more specific
description of what type of a key is being configured. This is needed to
be able to add support for "Extended Key ID for Individually Addressed
Frames" from IEEE Std 802.11-2016. In addition, this may be used to
replace the set_tx boolean eventually once all the driver wrappers have
moved to using the new key_flag.
The following flag are defined:
KEY_FLAG_MODIFY
Set when an already installed key must be updated.
So far the only use-case is changing RX/TX status of installed
keys. Must not be set when deleting a key.
KEY_FLAG_DEFAULT
Set when the key is also a default key. Must not be set when
deleting a key. (This is the replacement for set_tx.)
KEY_FLAG_RX
The key is valid for RX. Must not be set when deleting a key.
KEY_FLAG_TX
The key is valid for TX. Must not be set when deleting a key.
KEY_FLAG_GROUP
The key is a broadcast or group key.
KEY_FLAG_PAIRWISE
The key is a pairwise key.
KEY_FLAG_PMK
The key is a Pairwise Master Key (PMK).
Predefined and needed flag combinations so far are:
KEY_FLAG_GROUP_RX_TX
WEP key not used as default key (yet).
KEY_FLAG_GROUP_RX_TX_DEFAULT
Default WEP or WPA-NONE key.
KEY_FLAG_GROUP_RX
GTK key valid for RX only.
KEY_FLAG_GROUP_TX_DEFAULT
GTK key valid for TX only, immediately taking over TX.
KEY_FLAG_PAIRWISE_RX_TX
Pairwise key immediately becoming the active pairwise key.
KEY_FLAG_PAIRWISE_RX
Pairwise key not yet valid for TX. (Only usable with Extended Key ID
support.)
KEY_FLAG_PAIRWISE_RX_TX_MODIFY
Enable TX for a pairwise key installed with KEY_FLAG_PAIRWISE_RX.
KEY_FLAG_RX_TX
Not a valid standalone key type and can only used in combination
with other flags to mark a key for RX/TX.
This commit is not changing any functionality. It just adds the new
key_flag to all hostapd/wpa_supplicant set_key() functions without using
it, yet.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
In order to correctly encrypt rekeying frames, wpa_supplicant now checks
if a PTK is currently installed and sets the corresponding encrypt
option for tx_control_port().
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
Add PMKSA candidates from scan results only if they advertise an AKMP
that is used with RSN pre-authentication. Previously, candidates were
added but then ignored later if the AKMP was not suitable.
Signed-off-by: Jouni Malinen <j@w1.fi>
This buffer was getting corrupted, so add more details to make it
clearer what causes the corruption should this type of regression show
up again.
Signed-off-by: Jouni Malinen <j@w1.fi>
Protect RSNXE, if present, in FT Reassociation Request/Response frames.
This is needed for SAE H2E with FT.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use a single struct definition and a single shared implementation for
parsing EAPOL-Key KDEs and IEs instead of maintaining more or less
identical functionality separately for wpa_supplicant and hostapd.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add the new RSNXE into (Re)Association Request frames and EAPOL-Key msg
2/4 when using SAE with hash-to-element mechanism enabled. This allows
the AP to verify that there was no downgrade attack when both PWE
derivation mechanisms are enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If the AP advertises RSN Extension element, it has to be advertised
consistently in the unprotected (Beacon and Probe Response) and
protected (EAPOL-Key msg 3/4) frames. Verify that this is the case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Commit e820cf952f ("MFP: Add MFPR flag into station RSN IE if 802.11w
is mandatory") added indication of MFPR flag in non-FT cases and was
further extended to cover FT protocol in commit ded56f2faf ("FT: Fix
MFPR flag in RSNE during FT protocol"). Similar fix is needed for
FILS+FT as well.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Hardcode this to be defined and remove the separate build options for
PMF since this functionality is needed with large number of newer
protocol extensions and is also something that should be enabled in all
WPA2/WPA3 networks.
Signed-off-by: Jouni Malinen <j@w1.fi>
If FT over-the-DS case is enforced through the "FT_DS <BSSID>" control
interface command, the PMF capability check during BSS selection is not
used and that could have allowed PMF to be disabled in the over-the-DS
case even if the local network profile mandated use of PMF. Check
against this explicitly to avoid unexpected cases if the APs within the
same mobility domain are not configured consistently.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Commit e820cf952f ("MFP: Add MFPR flag into station RSN IE if 802.11w
is mandatory") added indication of MFPR flag in non-FT cases, but forgot
to do so for the FT protocol cases where a different function is used to
build the RSNE. Do the same change now for that FT specific case to get
consistent behavior on indicating PMF configuration state with MFPR.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
gcc 8.3.0 was apparently clever enough to optimize away the previously
used os_memset() to explicitly clear a stack buffer that contains keys
when that clearing happened just before returning from the function.
Since memset_s() is not exactly portable (or commonly available yet..),
use a less robust mechanism that is still pretty likely to prevent
current compilers from optimizing the explicit clearing of the memory
away.
Signed-off-by: Jouni Malinen <j@w1.fi>
