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>
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>
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>
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>
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>
There is no help from seeing 32 lines of debug prints about clearing
AP's RSNE/RSNXE information for each potential link when such
information has not been set in the first place. These were printed even
when there is no use of MLO whatsoever, so get rid of the prints for any
case where the value has not yet been set.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add support for group rekeying in MLO connection. Parse per link MLO
GTK/IGTK/BIGTK KDEs from Group Key msg 1/2 and configure to the driver.
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Use AP MLD address as the destination address for EAPOL-Key 4-way
handshake frames since authenticator/supplicant operates above MLD. The
driver/firmware will use RA/TA based on the link used for transmitting
the EAPOL frames.
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Validate new KDEs defined for MLO connection in EAPOL-Key msg 1/4 and
3/4 and reject the 4-way handshake frames if any of the new KDE data is
not matching expected key data.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Process EAPOL-Key msg 3/4 and configure PTK and per-link GTK/IGTK/BIGTK
keys to the driver when MLO is used.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Add support to specify a Link ID for set key operation for MLO
connection. This does not change the existing uses and only provides the
mechanism for extension in following commits.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Configure TK to the driver with AP MLD address with MLO is used. Current
changes are handling only EAPOL-Key 4-way handshake and FILS
authentication cases, i.e., FT protocol case needs to be addressed
separately.
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Use the AP MLD address instead of the BSSID of a link as the
authenticator address in the PMKSA entry.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Use AP MLD address to derive pairwise keys for MLO connection. Current
changes are handling only PTK derivation during EAPOL-Key 4-way
handshake and FILS authentication, i.e., FT protocol case needs to be
addressed separately.
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Add new KDEs introduced for MLO connection as specified in
12.7.2 EAPOL-Key frames, IEEE P802.11be/D2.2.
- Add MAC and MLO Link KDE for each own affliated link (other than the
link on which association happened) in EAPOL-Key msg 2/4.
- Add MAC KDE in 4/4 EAPOL frame.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Update the following MLO connection information to wpa_sm:
- AP MLD address and link ID of the (re)association link.
- Bitmap of requested links and accepted links
- Own link address for each requested link
- AP link address, RSNE and RSNXE for each requested link
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Store PMKSA cache entry in wpas_pasn and remove wpa_sm dependency to add
an entry to PMKSA cache. This is a step towards allowing the PASN
implementation to be used outside the context of wpa_supplicant.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow PMKSA caching functionality to be used even if sm, current_cb, and
free_cb are uninitialized. This makes RSN supplicant state machine
independent PMKSA caching possible for other modules, enabling
functional reuse.
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>
Provide key length instead of SHA384/SHA256 selection to the helper
function so that the new SHA512 option can be covered for
FT-SAE-EXT-KEY.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Do not try to use variables that are not defined without
CONFIG_IEEE80211R=y and add the forgotten "inline" for the function
wrapper.
Fixes: 5c65ad6c0b ("PASN: Support PASN with FT key derivation")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
