Need to copy own address and peer address locally and pass them to
pasn_deauthenticate(), because this pointer data will be flushed from
the PTKSA cache before sending the Deauthentication frame and these
pointers to then-freed memory would be dereferenced.
Fixes: 24929543 ("PASN: Deauthenticate on PTKSA cache entry expiration")
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
Map to correct control interface commands for PASN start and stop.
Fixes: ad338cfe58 ("ctrl_iface: Add support for PASN authentication")
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
PMKSA caching for the FT initial mobility domain association was fully
defined in IEEE Std 802.11-2020. The state before that was unclear and
there has been interoperability issues in this area, so use of PMKSA
caching with FT-EAP has been disabled in wpa_supplicant by default.
The wpa_supplicant and hostapd implementation of PMKSA caching for FT
ended up using an earlier default mechanism (SHA-1) for deriving the
PMKID when using the FT-EAP. This does not match what got defined in
IEEE Std 802.11-2020, 12.11.2.5.2 (SHA256). It is not really desirable
to use SHA-1 for anything with FT since the initial design of FT was
based on SHA256. Furthermore, it is obviously not good to differ in
behavior against the updated standard. As such, there is sufficient
justification to change the implementation to use SHA256 here even
though this ends up breaking backwards compatibility for PMKSA caching
with FT-EAP.
As noted above, this is still disabled in wpa_supplicant by default and
this change results in PMKSA caching not working only in cases where it
has been enabled explicitly with ft_eap_pmksa_caching=1. Those cases
recover by falling back to full EAP authentication.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add QCA_WLAN_VENDOR_ATTR_CONFIG_WFC_STATE vendor attribute. Userspace
uses this attribute to configure wfc state to the driver/firmware. The
driver/firmware uses this information to optimize power savings, rate
adaption, roaming, etc.
Signed-off-by: Mukul Sharma <quic_mukul@quicinc.com>
wpa_supplicant used the WPS IE from a Probe Response frame, if one was
received, even if there might have been a more recent Beacon frame with
an updated WPS IE. This could result in using stale information about
active WPS registrar, e.g., when operating on the 6 GHz band.
Prefer WPS IE from a Beacon frame over the default selection of Probe
Response frame (if one has been received) in cases where the Beacon
frame is received more recently than the Probe Response frame and active
WPS Registrar information is being checked. Skip this for the case where
UUID-E is needed since that is not available in the Beacon frame.
Signed-off-by: Sai Pratyusha Magam <quic_smagam@quicinc.com>
OCV cannot be used without PMF and such a configuration were to be used
with wpa_supplicant, the AP would reject the association. hostapd is
already enabling PMF automatically whenever OCV is being enabled, so do
the same with wpa_supplicant.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
IEEE Std 802.11-2020, 12.4.7.6 says that status code CHALLENGE_FAILURE,
needs to be sent in case the verification action fails for SAE Confirm
message frame from a STA: "An SAE Confirm message, with a status code
not equal to SUCCESS, shall indicate that a peer rejects a previously
sent SAE Confirm message. An SAE Confirm message that was not
successfully verified is indicated with a status code of
CHALLENGE_FAILURE."
hostapd, however, did not use this status code for this case. In
ieee802_11.c the function sae_check_confirm() is called and in case of
verification failure (-1 is returned), the response is set to
WLAN_STATUS_UNSPECIFIED_FAILURE (status code = 1). Fix this to use
CHALLENGE_FAILURE.
Signed-off-by: Koen Van Oost <koen.vanoost@airties.com>
Signed-off-by: Mert Ekren <mert.ekren@airties.com>
If a higher priority BSS has invalid security parameters, e.g., an
invalid SAE password, and a lower priority BSS is discovered only after
the local network profile has been temporarily disabled, the BSSID
ignoring mechanism is not sufficient to allow the lower priority BSS to
be tried and all consecutive attempts will continue to use the higher
priority BSS. This might prevent connection in some unexpected cases
with invalid network configuration.
Extend BSSID ignoring mechanism to work in this type of a case by
ignoring the BSSID that resulted in disabling the SSID temporarily
during the first connection attempt after having re-enabled the SSID.
This allows a lower priority BSS, if any is available in scan results,
to be tried next to see if it might have working security parameters.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Explicitly check for invalid cases where the configured channel and
bandwidth might result in the full channel number range going beyond the
list of supported channels to avoid reading beyond the end of the
channel buffer.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The SA/DA checks needs to be reversed for the TX case.
Fixes: 8481c750 ("PASN: Fix Authentication frame checks")
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
If an AP is started on a DFS channel (or any channels within its
bandwidth require DFS) and DFS is offloaded to the driver, hostapd needs
to wait for CAC to complete. But the driver may not do CAC and just
switches to a non-DFS channel instead. This would result in a failure to
start the AP because hostapd fails to receive a CAC complete event and
cannot finish interface setup.
Skip CAC and complete AP setup in the channel switch event handler for
this case.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add CLOSE_LOG command to stop hostapd logging to file. This can be
followed with RELOG to restart logging to the same file path.
Signed-off-by: Sai Pratyusha Magam <quic_smagam@quicinc.com>
Add a new subcommand QCA_NL80211_VENDOR_SUBCMD_DOZED_AP to configure
doze mode state on an AP interface. This is also used as an event to
indicate the updated configuration. In doze mode, AP transmits
beacons at higher beacon intervals and RX is disabled.
Uses attributes defined in enum qca_wlan_vendor_attr_dozed_ap.
Signed-off-by: Purushottam Kushwaha <quic_pkushwah@quicinc.com>
During the roam scan, if there are no desired APs found in the partial
frequency list, an immediate full scan on all the supported frequencies
is initiated as a fallback. This would include the 6 GHz PSC
frequencies. Define an attribute to allow that behavior to be modified
to include PSCs only if 6 GHz use has been detected.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
When the RADIUS server requests a STA to be deauthenticated imminently
without providing a reason URL, there is no need to allow the STA spend
any additional time associated. Deauthenticate the STA immediately after
it has ACK'ed the WNM-Notification frame indicating imminent
deauthentication or at latest two seconds after having processes the
Access-Accept message.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Currently sta_mlo_info.req_links is not getting cleared before
populating the requested links information for a new connection/roam
event. This is causing wrong requested links bitmap in
sta_mlo_info.req_links if there is a change in requested link IDs
between the previous and the new connection. To avoid such issues fully
clear MLO connection information after disconnection and before
populating MLO connection information during (re)association event.
Fixes: cc2236299f ("nl80211: Get all requested MLO links information from (re)association events")
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
IGTK and BIGTK MLO KDEs should be validated only when the AP sends them
in EAPOL-Key msg 3/4. Though IEEE P802.11be/D2.2 mandates MLO AP to
enable PMF and Beacon Protection features there is no text to mandate a
STA to discard connection when the MLO AP doesn't send IGTK and BIGTK
MLO KDEs in EAPOL-Key msg 3/4 for a link. Also, fix
wpa_sm->mgmt_group_cipher checks before processing MLO IGTK and BIGTK
MLO KDEs.
Fixes: f15cc834cb ("MLD STA: Processing of EAPOL-Key msg 3/4 frame when using MLO")
Fixes: 8f2e493bec ("MLD STA: Validation of MLO KDEs for 4-way handshake EAPOL-Key frames")
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
During the roam scan, if there are no desired APs found in the partial
frequency list, an immediate full scan on all the supported frequencies
is initiated as a fallback. This flag controls the frequency list
creation for full scan on the following lines.
1 - Full scan to exclude the frequencies that were already scanned by
the previous partial scan.
0 - Full scan to include all the supported frequencies irrespective of
the ones already scanned by partial scan.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Taking sizeof(ptr) is incorrect to determine size of passed in hash and
results in hlen getting set to a very large value since MD5_MAC_LEN >
sizeof(ptr). Provide the actual size of the hash buffer from the caller
to fix this.
tls_key_x_server_params_hash() callers src/tls/tlsv1_client_read.c and
src/tls/tlsv1_server_write.c both pass in a large enough hash (hash[64]
or hash[100]) that this does not appear to have an impact, though it is
still wrong.
Signed-off-by: Glenn Strauss <gstrauss@gluelogic.com>
This new value was added to verify peer certificate if it is provided,
but not reject the TLS handshake if no peer certificate is provided.
Signed-off-by: Glenn Strauss <gstrauss@gluelogic.com>
Fix memory leak of intro.peer_key in wpas_dpp_rx_peer_disc_resp(). The
other code paths were updated to use dpp_peer_intro_deinit(), but this
non-privacy-protection version of the station implementation was missed.
Fixes: 148de3e0dc ("DPP3: Private Peer Introduction protocol")
Signed-off-by: Glenn Strauss <gstrauss@gluelogic.com>
The dev pointer could potentially be NULL here in some P2PS cases, so
check it explicitly before dereferencing it when checking for 6 GHz
capability.
Fixes: b9e2826b9d ("P2P: Filter 6 GHz channels if peer doesn't support them")
Signed-off-by: Jouni Malinen <j@w1.fi>
Try to make the bounds checking easier for static analyzers by checking
each length field separately in addition to checking them all in the end
against the total buffer length.
Signed-off-by: Jouni Malinen <j@w1.fi>
Try to avoid static analyzer warnings due to use of the FTE length
field instead of the separately stored and validated length field value
when deriving FTE MIC.
Signed-off-by: Jouni Malinen <j@w1.fi>
Try to avoid static analyzer warnings due to use of the RSNE length
field instead of the separately stored and validated length field value
when deriving FTE MIC.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit 25b52e5f83 ("FT: Extend FTE parsing for FT-SAE-EXT-KEY") used
possible MIC length iteration to try to figure out the length of the MIC
field in FTE. That was the only option available at the time, but FTE is
now being extended in IEEE 802.11-REVme to explicitly indicate the
length of the MIC field for the new FT-SAE-EXT-KEY AKM to make this
easier.
Use the new design from the approved comment resolution (*) in
REVme/D2.0 ballot CID 3135 to simplify implementation. This gets rid of
the need to pass in key length and the somewhat strange need_{r0kh,r1kh}
parameters to wpa_ft_parse_ies().
(*)
https://mentor.ieee.org/802.11/dcn/22/11-22-1991-02-000m-proposed-resolutions-to-some-lb270-comments.docx
Signed-off-by: Jouni Malinen <j@w1.fi>
This is needed to avoid trying the subsequent connections with the old
PMKID that the AP claims not to hold and continues connection failures.
This was already handled for the SME-in-the-driver case in commit commit
50b77f50e8 ("DPP: Flush PMKSA if an assoc reject without timeout is
received"), but the wpa_supplicant SME case did not have matching
processing.
Add the needed check to avoid recover from cases where the AP has
dropped its PMKSA cache entry. Do this only based on the specific status
code value (53 = invalid PMKID) and only for the PMKSA entry that
triggered this failure to minimize actions taken based on an unprotected
(Re)Association Response frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is going to be needed once wpa_supplicant starts dropping the PMKSA
cache entry on status code 53 (invalid PMKID) rejection of association.
Signed-off-by: Jouni Malinen <j@w1.fi>
Change of the wpas_pasn_start() prototype did not update the fuzzer
tool.
Fixes: 309765eb66 ("PASN: Use separate variables for BSSID and peer address")
Signed-off-by: Jouni Malinen <j@w1.fi>
The addition of the "spa" argument was missed in the empty inline
function.
Fixes: 9ff778fa4b ("Check for own address (SPA) match when finding PMKSA entries")
Signed-off-by: Jouni Malinen <j@w1.fi>
Depending on the crypto library, crypto_ec_point_from_bin() can fail if
the element is not on curve, i.e., that error may show up before getting
to the explicit crypto_ec_point_is_on_curve() check. Add a debug print
for that earlier call so that the debug log is clearly identifying
reason for rejecting the SAE commit message.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This prevents attempts of trying to use PMKSA caching when the existing
entry was created using a different MAC address than the one that is
currently being used. This avoids exposing the longer term PMKID value
when using random MAC addresses for connections.
In practice, similar restriction was already done by flushing the PMKSA
cache entries whenever wpas_update_random_addr() changed the local
address or when the interface was marked down (e.g., for an external
operation to change the MAC address).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This is needed to be able to determine whether a PMKSA cache entry is
valid when using changing MAC addresses. This could also be used to
implement a mechanism to restore a previously used MAC address instead
of a new random MAC address.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Using separate variables for BSSID and peer address is needed to support
Wi-Fi Aware (NAN) use cases where the group address is used as the BSSID
and that could be different from any other peer address. The
infrastructure BSS cases will continue to use the AP's BSSID as both the
peer address and BSSID for the PASN exchanges.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Rename struct pasn_data::bssid to peer_addr to be better aligned with
different use cases of PASN and its extensions. This is a step towards
having option to use different peer address and BSSID values for NAN use
cases.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
It is possible for there to be multiple STA entries (e.g., one for each
BSS) when a sniffer capture contains multiple associations using MLO.
For such cases, the new PTK information needs to be updated to all
existing STA entries to be able to find the latest TK when decrypting
following frames since the other STA entries might be located first when
trying to figure out how to decrypt a frame.
In addition to the PTK, copy the MLD MAC addresses to the other STA and
BSS entries to make sure the latest values are used when trying to
decrypt frames.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Kernel commit 22e76844c566 - ("ieee80211: Increase PMK maximum length to
64 bytes") increased the maximum allowed length for NL80211_ATTR_PMK to
64 bytes. Thus, allow sending 64 bytes PMK in NL80211_CMD_SET_PMKSA and
if NL80211_CMD_SET_PMKSA fails with ERANGE try NL80211_CMD_SET_PMKSA
again without PMK. Also, skip sending PMK when PMK length is greater
than 64 bytes.
This is needed for some newer cases like DPP with NIST P-521 and
SAE-EXT-KEY with group 21. The kernel change from 48 to 64 octets is
from February 2018, so the new limit should be available in most cases
that might want to use these new mechanisms. Maintain a backwards
compatible fallback option for now to cover some earlier needs for DPP.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
wpa_supplicant has support for only a single FT key hierarchy and as
such, cannot use more than a single mobility domain at a time. Do not
allow FT protocol to be started if there is a request to reassociate to
a different BSS within the same ESS if that BSS is in a different
mobility domain. This results in the initial mobility domain association
being used whenever moving to another mobility domain.
While it would be possible to add support for multiple FT key hierachies
and multiple mobility domains in theory, there does not yet seem to be
sufficient justification to add the complexity needed for that due to
limited, if any, deployment of such networks. As such, it is simplest to
just prevent these attempts for now and start with a clean initial
mobility domain association.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
