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>
After the secure association and PTK derivation are completed, if the
device supports LTF keyseed, generate the LTF keyseed using KDK and set
the ranging context to the driver by using the command
QCA_NL80211_VENDOR_SUBCMD_SECURE_RANGING_CONTEXT.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Define new WPA_KEY_MGMT_* values for the new SAE AKM suite selectors
with variable length keys. This includes updates to various mapping and
checking of the SAE key_mgmt values.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
IEEE Std 802.11-2020 is ambiguous on how the Secure bit is set in
EAPOL-Key msg 1/4 and 2/4 in the case where 4-way handshake is use to
rekey the PTK. 12.7.2 describes this with "set to 1 once the initial key
exchange is complete" while 12.7.6 shows EAPOL-Key msg 1/4 and 2/4 using
Secure=0 without any consideration on whether the handshake is for
rekeying.
TGme seems to be moving towards clarifying this to use Secure=1 based on
there being a shared PTKSA between the Authenticator and the Supplicant.
In other words, this would use Secure=1 in EAPOL-Key msg 1/4 and 2/4 in
the case of rekeying. Change implementation to match that. This bit was
already practically ignored on the reception side, so this should not
have impact on actual functionality beyond this one bit changing its
value in the frame.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
RSN design is supposed to encrypt all Data frames, including EAPOL
frames, once the TK has been configured. However, there are deployed
implementations that do not really follow this design and there are
various examples from the older uses of EAPOL frame where those frames
were not encrypted. As such, strict filtering of unencrypted EAPOL
frames might results in undesired interoperation issues.
However, some of the most important cases of missing EAPOL frame
encryption should be possible to handle without causing too significant
issues. These are for cases where an attacker could potentially cause an
existing association to be dropped when PMF is used. EAPOL-Key msg 1/4
is one potential candidate for such attacks since that frame could be
used to initiate a 4-way handshake that the real AP might never complete
and the station might end up disconnecting because of that or at
minimum, getting into somewhat mismatching state with the AP.
Drop EAPOL-Key msg 1/4 when it is known that it was not encrypted but
should have been and when PMF is enabled. While it would be correct to
drop this even without PMF, that does not provide any significant
benefit since it is trivial to force disconnection in no-PMF cases. It
should also be noted that not all drivers provide information about the
encryption status of the EAPOL frames and this change has no impact with
drivers that do not indicate whether the frame was encrypted.
Signed-off-by: Jouni Malinen <j@w1.fi>
EAPOL-Key Request frame with Error=1 is not really a request for a new
key, so allow that frame to be sent even if PTK0 rekey is not allowed
since the supplicant is required to report Michael MIC errors to the
authenticator.
Signed-off-by: Jouni Malinen <j@w1.fi>
This information was already available from the nl80211 control port RX
path, but it was not provided to upper layers within wpa_supplicant and
hostapd. It can be helpful, so parse the information from the driver
event.
Signed-off-by: Jouni Malinen <j@w1.fi>
The wpa_supplicant check for whether a TK is configured into the driver
was broken during the time this information is needed for rekeying or
reauthenticating with another 4-way handshake. sm->ptk.installed is not
set at the point the EAPOL-Key msg 4/4 is sent and while that means the
initial 4-way handshake needs to prevent encryption, the consecutive
4-way handshake must not be doing that since the old key (TK) is still
in the driver. Fix this so that the EAPOL-Key msg 4/4 during rekeying
does not get transmitted without encryption.
Fixes: a79ed06871 ("Add no_encrypt flag for control port TX")
Signed-off-by: Jouni Malinen <j@w1.fi>
Currently a corrupted handshake message 1/4 causes the client to
disconnect from the network. This can lead to a denial-of-service
vulnerability allowing an adversary to forcibly disconnect a client from
protected networks even when Wi-Fi Management Frame Protection (MFP) is
enforced if the driver allows unencrypted EAPOL-Key frames to be
received after key configuration..
Fix this by discarding the corrupted handshake message 1/4.
This issue was discovered by Domien Schepers (Northeastern University)
and Mathy Vanhoef (imec-DistriNet, KU Leuven).
Signed-off-by: Domien Schepers <schepers.d@northeastern.edu>
To support the STA testbed role, the STA has to disable transmitting
EAPOL-Key group msg 2/2 of Group Key Handshake. Add test parameter to
disable sending EAPOL-Key group msg 2/2 of Group Key Handshake.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Commit b0f457b619 ("SAE: Do not expire the current PMKSA cache entry")
depends on sm->cur_pmksa to determine if it is the current PMKSA cache
entry, but sm->cur_pmksa was not always correct for SAE in the current
implementation.
Set sm->cur_pmksa in wpa_sm_set_pmk() (which is used with SAE), and skip
clearing of sm->cur_pmksa for SAE in wpa_find_assoc_pmkid(). This latter
case was added by commit c2080e8657 ("Clear current PMKSA cache
selection on association/roam") for driver-based roaming indication and
Suite B, so skipping it for SAE should be fine.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
There is no convenient mechanism for reauthenticating and generating a
new PMK during an association with SAE. As such, forced PMK update would
mean having to disassociate and reauthenticate which is not really
desired especially when the default PMKLifetime is only 12 hours.
Postpone PMKSA cache entry expiration of the currently used entry with
SAE until the association is lost. In addition, do not try to force the
EAPOL state machine to perform reauthentication for SAE since that won't
work.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Update PMKSA cache when interface is disabled and then enabled based on
the new MAC address. If the new MAC address is same as the previous MAC
address, the PMKSA cache entries are valid and hence update the PMKSA
cache entries to the driver. If the new MAC address is not same as the
previous MAC address, the PMKSA cache entries will not be valid anymore
and hence delete the PMKSA cache entries.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
While creating a cloned PMKSA entry for OKC both expiration and
reauth_time values are set to maximum values, but later only the
expiration time is copied from the old PMKSA entry to the new PMKSA
entry. Due to this there is a possibility of reauth_time becoming
greater than expiration time in some cloned entries. To avoid this copy
reauth_time also to the cloned entry.
Also, add check to reject control interface commands with reauth time
greater than expiration time.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Determine if the TDLS peer supports TDLS in 6 GHz band based on the HE 6
GHz Band Capabilities element received in the TDLS Setup Response frame.
Indicate the peer's HE 6 GHz capabilities to the driver through
sta_add().
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
External applications can store PMKSA entries persistently and
reconfigure them to wpa_supplicant after restart. This can result in
wpa_supplicant having a PMKSA for FILS authentication without having
matching ERP keys for it which would prevent the previously added
mechanism for dropping FILS PMKSA entries to recover from rejected
association attempts.
Fix this by clearing PMKSA entries configured by external applications
upon FILS connection failure even when ERP keys are not available.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
FILS authentication derives PMK differently from the EAP cases. The PMK
value 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
FILS AKM.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Indicate TDLS peer's capability to driver after processing TDLS setup
response frame. This information can be used by the driver to decide
whether to include HE operation IE in TLDS setup confirmation frame.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Simplify the implementation by using shared functions for parsing the
capabilities instead of using various similar but not exactly identical
checks throughout the implementation.
Signed-off-by: Jouni Malinen <j@w1.fi>
Need to get EAP state machine into a state where it is willing to
proceed with a new EAP-Request/Identity if PMKSA cache addition fails
after a successful EAP authentication before the initial 4-way handshake
can be completed.
Signed-off-by: Jouni Malinen <j@w1.fi>
sm->bssid is still the BSSID of the previous AP at this point in the FT
protocol, so need to show the target AP's BSSID instead in the failure
message.
Fixes: 8c1f61e820 ("OCV: Report OCI validation failures with OCV-FAILURE messages (STA)")
Signed-off-by: Jouni Malinen <j@w1.fi>
Determine if the TDLS peer is HE capable based on HE Capability element
received in the TDLS Setup Response frame. Indicate the peer's HE
capabilities to the driver through sta_add().
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
This is needed to avoid the corner case of local RSNXE aware station
being configured to behave as WPA(v1)-only STA when the AP might not
include RSNXE in EAPOL-Key msg 3/4.
Signed-off-by: Jouni Malinen <j@w1.fi>
Derive the KDK as part of PMK to PTK derivation if forced by
configuration or in case both the local station and the AP declare
support for secure LTF.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
IEEE P802.11az/D2.6 defines the following additional capabilities to
RSNXE:
- Secure LTF support
- Secure RTT support
- Protection of range negotiation and measurement management frames.
Add support for advertising the new capabilities.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Add support for PASN authentication with FT key derivation:
- As IEEE P802.11az/D2.6 states that wrapped data is optional and
is only needed for further validation of the FT security parameters,
do not include them in the first PASN frame.
- PASN with FT key derivation requires knowledge of the PMK-R1 and
PMK-R1-Name for the target AP. As the WPA state machine stores PMK-R1,
etc. only for the currently associated AP, store the mapping of
BSSID to R1KH-ID for each previous association, so the R1KH-ID
could be used to derive PMK-R1 and PMK-R1-Name. Do so instead
of storing the PMK-R1 to avoid maintaining keys that might not
be used.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
PASN requires to store the PTK derived during PASN authentication
so it can later be used for secure LTF etc. This is also true
for a PTK derived during regular connection.
Add an instance of a PTKSA cache for each wpa_supplicant
interface when PASN is enabled in build configuration.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
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>
Extend the wpa_pmk_to_ptk() to also derive Key Derivation
Key (KDK), which can later be used for secure LTF measurements.
Update the wpa_supplicant and hostapd configuration and the
corresponding WPA and WPA Auth state machine, to allow enabling of KDK
derivation. For now, use a testing parameter to control whether KDK is
derived.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
PASN authentication requires that group management cipher suite
would be set to 00-0F-AC:7 in the RSNE, so consider it as a valid
group management cipher and adjust the code accordingly.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
This extends the changes in commit c397eff828 ("Make GTK length
validation easier to analyze") to cover the RSN case as well as the WPA.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous fix did not actually address this testing functionality
case correctly. Clear the peer pointer to avoid double freeing.
Fixes: a86078c876 ("TDLS: Fix error path handling for TPK M1 send failures")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Local allocation error or failure to get a random number could have
resulted in the peer entry getting freed and couple of the error path
cases in callers could have tried to reference or delete the peer after
that. Fix this by tracking the errors where the peer is freed.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
We don't really need to duplicate more of this, so just
move the lib.rules include to the end and do more of the
stuff that's common anyway there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
