Print the MLD MAC addresses and link addresses for both the AP MLD and
non-AP MLD when processing (Re)Association Request frames.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Store SNonce and ANonce from FT Authentication frames during FT
over-the-air so that these values are available for processing the FT
reassociation frames.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Use the MLD MAC addresses and MLO-specific MIC calculation rules per
IEEE P802.11be/D4.0, 13.8.5.
Signed-off-by: Jouni Malinen <quic_jouni@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>
Generate the "extra" data buffer outside wpa_ft_mic() to make this
function easier to share for MLO FT Reassociation Response frame. This
replaces the earlier design in commit e6f64a8e1d ("FT: FTE MIC
calculation for MLO Reassociation Request frame").
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Make this function more capable to address cases where a specific
affiliated link of an AP MLD needs to be found.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
SPA (FTO's MAC address) and AA (FTR's MAC address) are the MLD MAC
addresses when using MLO and the Reassociation Request frame will also
include the non-AP STA MAC addresses for the requested links.
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>
Store the non-AP MLD link address of the link that is used for
association when processing (Re)Association Request frames. This is
needed to get the full set of link addresses when 4-way handshake is not
used (e.g., for FT protocol).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This is needed to be able to find a previously added STA entry when
roaming using FT over-the-DS back to an AP MLD that was used previously.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Use STA address indicated in FT Request/Response frames instead of
transmit or receive addresses for creating/finding STA instance.
For MLO to MLO roaming:
1. STA may use different link compared to FT Action frames negotiated
links.
2. STA may reassociate with target AP MLD with different set of
links compared to links connected to current AP MLD.
So create STA with MLD MAC address and attach to one of the BSS
affiliated with target AP MLD. Update link address of the STA and BSS
during processing of the Reassociation Request frame.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Use AP and STA addresses indicated in FT Request/Response frames for
PMK-R1 and PTK derivation instead of the addresses in the BSS and STA
entries. This is needed for MLO to use the MLD MAC address instead of
one of the link addresses.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
This makes the code more readable by getting rid of the multiple
instances of references to the specifiec fields within the FT Action
frame.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
When FT over-the-DS is used with MLO, the Target AP Address field is
expected to identify the AP MLD using its MLD MAC address.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
FT over-the-DS might have created the new STA entry on another
affiliated BSS during the FT Request/Response exchange, so use a wider
search to locate the correct STA entry when processing the Reassociation
Request/Response frames.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Use the Basic Multi-Link element in (Re)Association Request frames to
learn the non-AP MLD MAC address instead of having to wait until this
address is included in an EAPOL-Key frame. This is needed for FT
protocol (where 4-way handshake is not used) and it is also convenient
to have the MLD MAC address available as soon as possible to be able to
decrypt frames and even to recognize some special AP vs. STA cases when
either the BSSID or the AP MLD MAC address might be used.
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>
The Key MIC field is of variable length when using OWE, so determine the
correct length based on which group was negotiated for OWE during
association.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Check the +HTC bit in FC to determine if the HT Control field is present
when decrypting Robust Management frames. This was already done for QoS
Data frames, but the Management frame case had not been extended to
cover this option.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This is needed to derive the PTK correct when Secure LTF support is used
and the additional KDK component needs to be taken into account.
Signed-off-by: Adil Saeed Musthafa <quic_adilm@quicinc.com>
Commit b20991da69 ("wlantest: MLD MAC Address in CCMP/GCMP AAD/nonce")
updated AAD and nonce construction to use MLD addresses in AAD for A1
and A2. IEEE P802.11be has additional cases where A3 in AAD is set to
the AP MLD address, so cover those as well.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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>
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>
Provide AKM, key length, and information about needed subelements to the
parser function so that the variable length MIC field cases can be
recognized for FT-SAE-EXT-KEY. Knowledge about R0KH-ID/R1KH-ID being
needed is required to be able to iterate over possible MIC field lengths
for the case where the AP does not yet know the correct key length at
the beginning of FT protocol.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Provide AKM to the helper function so that the new SHA256 and SHA512
options can be covered for FT-SAE-EXT-KEY.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Extend wlantest capabilities to cover the new SAE-EXT-KEY AKM and
variable length MIC field and key lengths for it based on the used SAE
group.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow a single STA entry to be found for a non-AP MLD regardless of
which link MAC address was used to transmit/receive it.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Update STA state tracking for SAE authentication as well as the previous
covered Open System algorithm.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This makes the debug message more useful for determining whether an
expected BIGTK has been derived.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
rx_mgmt_beacon() was skipping all steps after a Probe Response frame
from the AP had been processed. This is expected for the parts that were
updating the bss entry information, but the checks for beacon protection
should not be skipped in this manner.
Skip onlu the updating parts while checking that beacon protection is
used correctly to make this more useful.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Use the MLD MAC Address instead of link address in CCMP/GCMP AAD/nonce
construction when processing an individually addressed Data frame with
FromDS=1 or ToDS=1 between an AP MLD and non-AP MLD.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Do not complain about unprotected Action frames for additional
categories that have been defined as not being Robust.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Data frame processing had already been extended to support additional
cipher suites, but Robust Management frame processing was still using a
hardcoded cipher suite (CCMP-128). Extend it to support GCMP-128,
GCMP-256, and CCMP-256 as well.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This previously reserved bit is now used in FTM to help select the
appropriate replay counter. Silence the warning about use of a reserved
bit for this. wlantest does not yet support the actual replay counter
processing for FTM.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use the TKs from the PTK file (-T command line argument) to try to
decrypt encrypted Management frames if no BSS/STA key can be found based
on addresses.
Signed-off-by: Jouni Malinen <j@w1.fi>
Extend the fils_pmk_to_ptk() to also derive Key Derivation
Key (KDK) which can later be used for secure LTF measurements.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Extend the wpa_pmk_r1_to_ptk() to also derive Key Derivation
Key (KDK), which can later be used for secure LTF measurements.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Verify that RSNE, MDE, and FTE have valid information in FT
Reassociation Response frames. In addition, decrypt GTK, IGTK, and BIGTK
from the frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
It is expected for the STA entry on the target AP to move directly from
State 1 to State 3 when performing FT over-the-DS (i.e., FT Action
Request/Response frame exchange through the old AP followed by
Reassociation Request/Response frame exchange with the target AP).
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, missing CCMP protection on Robust Management frames was
reported based on the STA having indicated MFPC=1. That is not accurate
since the AP/BSS may have MFPC=0. Report this failure only if both the
AP and STA have indicated MFPC=1, i.e., when PMF has been negotiated for
the association.
Signed-off-by: Jouni Malinen <j@w1.fi>
If no Beacon or Probe Response frame has been seen in the capture, use
the IEs from EAPOL-Key msg 3/4 to set up BSS information.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous implementation tried to update STA IE information based on
EAPOL-Key msg 2/4 to be able to handle captures that do not include the
(Re)Association Request frame. This was not sufficient (OSEN was not
included) and was done too late (the parsed information is needed for
PMK-to-PTK derivation).
Move the IE update step to happen before trying to derive the PTK if no
(Re)Association Request frame has been seen.
Signed-off-by: Jouni Malinen <j@w1.fi>
Fetch the BIGTK from EAPOL-Key msg 3/4 and use it to validate MME in
Beacon frames when the AP uses Beacon protection.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Track PMK-R0/PMK-R0-Name from the initial mobility domain association
and derive PMK-R1/PTK when the station uses FT protocol. This allows
frames from additional roaming cases to be decrypted.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
