Use the RSN Override Link KDE to include the override variants of the
RSNE/RSNXE for each link so that all variants are verifies when
processing the protected EAPOL-Key message 3/4.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This allows all variants to be verified based on a protected frame to
achieve robust downgrade protection.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This provides an implicitly protected (SNonce is used as an input to PTK
derivation) mechanism for a STA to indicate support for RSN overriding
in a manner that does not cause interopability issues with deployed APs.
In addition, update sm->SNonce on the Authenticator only based on
message 2/4 since that is the only EAPOL-Key message that is defined to
provide the actual SNonce value. While clearing of this internal buffer
on message 4/4 might not cause issues, it is better to keep the actual
SNonce value here since the SNonce cookie can be used at a later point
in the sequence.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This replaces the use of the RSNE Override and RSNE Override 2 elements
with empty payload to indicate which RSNE variant was used.
In addition, this adds stricter validation of the RSNE in
(Re)Association Request frame to allow only the pairwise cipher suites
and AKMs listed in the indicated RSNE variant to be used.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add support for RSNE/RSNXE Override elements. Use these elements to
determine AP's extended RSN parameters.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
While TKIP should not really be used at all anymore and is not allowed
for WPA3 (which is required for Wi-Fi 7), there are some deployed APs
that allow WPA2 PSK to be used with MLO and even allowing WPA+WPA2 mode
with TKIP as the group cipher). IEEE P802.11be/D5.0 does not seem to
explicitly disallow this combination, so handle the MLO GTK KDE key
processing similarly to the way GTK KDE is processed, i.e., including
swapping of Michael MIC Tx and Rx keys for TKIP.
This fixes issues with Michael MIC failures if TKIP is used as a group
cipher for a multi-link association.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add a new "ssid_verified=1" entry into the control interface STATUS
command output if the SSID has been verified for the current
association. This verification may have been done implicitly (e.g., with
SAE H2E and FT protocol binding in the SSID into key derivation or with
FILS protecting the SSID element in the (Re)Association Request frame)
or explicitly with the recently added SSID protection mechanism during
the 4-way handshake.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
If the kck_len is 0 then the pointer may be NULL. If that happens UBSAN
complains about the NULL pointer as memcpy() has the arguments declared
to never be NULL even if the copied number of bytes were zero.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Add support for SSID protection in 4-way handshake based on the
mechanism added in IEEE 802.11REVme/D6.0. This is a mitigation against
CVE-2023-52424 (a.k.a. the SSID Confusion Attack).
This functionality is disabled by default and can be enabled with
ssid_protection=1 in the network profile. Once there has been more
testing of this to confirm there is no significant interoperability
issues, the goal is to be able to change this to be enabled by default.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
PMKSA cache API is included in libpasn.so used by external modules,
e.g., Wi-Fi Aware. To avoid dependency on IEEE8021X_EAPOL define for the
external modules at compile time, remove PMKSA cache static inline
functions from the header file and add wrapper function stubs.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This was done using the below semantic patch. There are a few more
places that were missed due to variable declarations or additional
checks in the for loop.
@@
iterator name for_each_link;
identifier max_links =~ "MAX_NUM_MLD_LINKS|MAX_NUM_MLO_LINKS";
expression links;
expression further_tests;
identifier i;
statement stmt;
@@
-for (i = 0; i < max_links; i++)
+for_each_link(links, i)
{
(
- if (!(links & BIT(i)))
- continue;
...
|
- if (!(links & BIT(i)) || further_tests)
+ if (further_tests)
continue;
...
|
- if (further_tests || !(links & BIT(i)))
+ if (further_tests)
continue;
...
|
- if (links & BIT(i))
stmt
|
- if (further_tests && (links & BIT(i)))
+ if (further_tests)
stmt
|
- if ((links & BIT(i)) && further_tests)
+ if (further_tests)
stmt
)
}
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
When the station (non-AP MLD) is associated with an AP MLD the link ID
for TDLS setup is derived from the discovery response frame and the link
ID is used in TDLS setup operation when acting as initiator. The driver
sends the received discovery response frame followed by the TDLS setup
request event. But the discovery response frame is received after the
setup request event leading to use incorrect link ID value for TDLS
setup operation causing the setup failure. Process the TDLS setup
request if the discovery response frame is received, else defer the
process until the discovery response frame is received and process the
setup request after discovery response frame is processed.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The standard is somewhat unclear on whether the PMKIDs used in
(Re)Association Request frame (i.e., potential PMKIDs that could be used
for PMKSA caching during the initial mobility domain association) are to
be retained or removed when generating EAPOL-Key msg 2/4.
wpa_supplicant has replaced the PMKID List contents from (Re)Association
Request frame with PMKR1Name when generating EAPOL-Key msg 2/4 for FT.
Allow it to be configured (ft_prepend_pmkid=1) to prepend the PMKR1Name
without removing the PMKIDs from (Re)Association Request frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
The Encrypted Key Data field need to be set to 1 whenever using an AEAD
cipher. Without this, the Authenticator would discard the EAPOL-Key
request frame when using FILS.
Signed-off-by: Jouni Malinen <j@w1.fi>
Allow the Key Data field to be encrypted in EAPOL-Key msg 2/4 and 4/4.
This is for testing purposes to enable a convenient mechanism for
testing Authenticator behavior with either potential future extensions
or unexpected Supplicant behavior.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow additional elements and KDEs to be added to EAPOL-Key msg 2/4 and
4/4. This is for testing purposes to enable a convenient mechanism for
testing Authenticator behavior with either potential future extensions or
incorrect Supplicant behavior.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This was done with spatch using the following semantic patch and minor
manual edits to clean up coding style and avoid compiler warnings in
driver_wext.c:
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !os_memcmp(a, b, ETH_ALEN)
+ ether_addr_equal(a, b)
Signed-off-by: Jouni Malinen <j@w1.fi>
This memcpy was causing warnings from static analyzers since it is being
misinterpreted as copying all the data into the lnkid.bssid[] array
instead of that and the following arrays. Since the copy is not needed
at all, just use the original pointer to get rid of these warnings.
Signed-off-by: Jouni Malinen <j@w1.fi>
Also this EAPOL frame uses the MLD MAC address of the AP MLD when sent
during an MLO association.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
For MLO association, specify destination address as the MLD MAC address
for sending Group Key msg 2/2.
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Add support for Authentication negotiated over IEEE Std 802.1X
with key derivation function using SHA-384.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
To support Opportunistic Key Caching for Suite B key management, KCK
needs to be stored on PMKSA to derive the new PMKID correctly for the
new roaming AP.
Signed-off-by: Vinoth V <vinoth117@gmail.com>
wpa_supplicant postpones expired PMKSA deletion untillassociation is
lost for SAE to avoid forced disconnection. But during this time the
driver may use the expired PMKSA for reassociation with the current
connected AP.
Remove the current PMKSA for SAE from the driver after reauth threshold
is passed when the driver takes care of BSS selection.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Do not reject reauth threshold passed PMKSA indicated in successful
association event since the PMKSA is still valid.
Additionally, remove the reauth threshold passed PMKSA entry from the
driver to prevent using it further in the driver.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Add the copied EHT capabilities into the sta_add() call when adding a
TDLS peer.
The mld_link_id value was previously only for AP mode, but it can now be
used for TDLS links as well to indicate the link on which a
single-link-TDLS direct link is negotiated.
Signed-off-by: Jouni Malinen <quic_klokere@quicinc.com>
When the current association is with an AP MLD, the BSSID for TDLS
operations needs to be selected based on which link is used to transmit
the frames.
Signed-off-by: Jouni Malinen <quic_klokere@quicinc.com>
When the current association is with an AP MLD, the Discovery Response
needs to be sent using the link that matches the indicated BSSID.
Signed-off-by: Jouni Malinen <quic_klokere@quicinc.com>
This is needed to be able to determine which link is used for TDLS setup
when the current association is with an AP MLD.
Signed-off-by: Jouni Malinen <quic_klokere@quicinc.com>
This is needed to be able to configure the STA entry into the driver
with the information for EHT.
Signed-off-by: Jouni Malinen <quic_klokere@quicinc.com>
This is needed to allow the driver to know on which operating channel
(as specified by the link that is affiliated with AP MLD for the current
association) is used for transmitting TDLS Discovery Response. This
commit adds the link_id parameter to various functions, but does not
implement the driver interface change itself.
Signed-off-by: Jouni Malinen <quic_klokere@quicinc.com>
wpa_supplicant does not configure BIGTK(s) to the driver when the STA
reconnects to the same AP after disconnect due to not clearing the last
configured BIGTK values during disconnect. To avoid such issues clear
the BIGTK values while clearing PTK and other group keys.
Fixes: 2d4c78aef7 ("Configure received BIGTK on station/supplicant side")
Fixes: f15cc834cb ("MLD STA: Processing of EAPOL-Key msg 3/4 frame when using MLO")
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
The FTE parser itself used valid data, but the reassembled buffer was
available only during the parser run. That buffer will be needed for the
caller as well since most of the parsed data is used as pointers instead
of copied data.
Store the reassembled buffer in struct wpa_ft_ies and require
wpa_ft_parse_ies() callers to use wpa_ft_parse_ies_free() to free any
possibly allocated temporary data after wpa_ft_parse_ies() calls that
return success (0).
Fixes: 43b5f11d96 ("Defragmentation of FTE")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Extend wpa_ft_mic() to take in an array of link addresses to allow the
FTE MIC to be calculated for Reassociation Request frame as described in
IEEE P802.11be/D4.0, 13.8.4. This commit does not change actual
behavior, i.e., this is just preparing wpa_ft_mic() and the existing
callers with a new argument.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The set of protected elements in the FTE in Reassociation Response frame
is different for MLO. Count RSNE and RSNXE separately for each link.
This implementation uses the number of links for which a GTK was
provided which does not fully match the standard ("requested link") and
a more accurate implementation is likely needed, but that will require
some more complexity and state information.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
In theory, each device that supports WMM (or the IEEE 802.11 QoS for
that matter) is expected to advertise how many replay counters it
supports and the peer device is supposed to use that information to
restrict the total number of different MSDU priorities (AC/UP) that
might be used. In practice, this is not really done in deployed devices
and instead, it is just assumed that everyone supports the eight
different replay counters so that there is no need to restrict which
MSDU priorities can be used.
hostapd implementation of WMM has advertised support for 16 PTKSA replay
counters from the beginning while wpa_supplicant has not had any code
for setting the supported replay counter fields in RSNE, i.e., has left
the value to 0 which implies that only a single replay counter is
supported. While this does not really result in any real issues with
deployed devices, this is not really correct behavior based on the
current IEEE 802.11 standard and the WMM specification.
Update wpa_supplicant to use similar design to the hostapd RSNE
generation by setting the number of supported PTKSA replay counters to
16 whenever WMM is enabled. For now, this is done based on the
association being for HT/VHT/HE/EHT and also based on the AP supporting
WMM since it is much more likely for the local device to support WMM and
eight replay counters (which can be indicated only with the value that
implies support for 16 counters since there is no separate value for 8).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
sm->bssid has not yet been updated here, so use the provided bssid
instead. This avoids replacing the PTKSA entry for the previous AP when
a new PTKSA is being stored while using the FT protocol.
Fixes: d70060f966 ("WPA: Add PTKSA cache to wpa_supplicant for PASN")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
RSNXE bits were modified, so update the relevant places accordingly.
Please note, WLAN_RSNX_CAPAB_PROT_RANGE_NEG was renamed to
WLAN_RSNX_CAPAB_URNM_MFPR and the bit position is changed to 15 instead
of 10, while BIT 10 is used for WLAN_RSNX_CAPAB_URNM_MFPR_X20 and is not
supported yet.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Add a callback handler to notify details of a PMKSA cache entry when it
is added to the PMKSA cache. This can be used to provide external
components more convenient access to the PMKSA cache contents.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This is a step in separating RSN and WPA(v1) processing of EAPOL-Key
frames into separate functions. This allows the implementation to be
simplified and potentially allows the validation rules to be made
stricter more easily. This is also a step towards allowing WPA(v1)
functionality to be removed from the build in the future.
Signed-off-by: Jouni Malinen <j@w1.fi>
CONFIG_NO_RC4=y could have been used to remove this functionality, but
it might as well be done automatically based on CONFIG_FIPS=y as well.
Signed-off-by: Jouni Malinen <j@w1.fi>
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>
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>
