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>
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>
Derive the library name from the directory name, and let each
library Makefile only declare the objects that are needed.
This reduces duplicate code for the ar call. While at it, also
pretty-print that call.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is something I hadn't previously done, but there are
cases where it's needed, e.g., building 'wlantest' and then
one of the tests/fuzzing/*/ projects, they use a different
configuration (fuzzing vs. not fuzzing).
Perhaps more importantly, this gets rid of the last thing
that was dumped into the source directories, apart from
the binaries themselves.
Note that due to the use of thin archives, this required
building with absolute paths.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of building in the source tree, put most object
files into the build/ folder at the root, and put each
thing that's being built into a separate folder.
This then allows us to build hostapd and wpa_supplicant
(or other combinations) without "make clean" inbetween.
For the tests keep the objects in place for now (and to
do that, add the build rule) so that we don't have to
rewrite all of that with $(call BUILDOBJS,...) which is
just noise there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
D-Bus clients can call CreateInterface() once and use the resulting
Interface object to connect multiple times to different networks.
However, if the network interface gets added to a bridge, clients
currently have to remove the Interface object and create a new one.
Improve this by supporting the change of the BridgeIfname property of
an existing Interface object.
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
Enhance the return values of ocv_verify_tx_params with enum to indicate
different OCI verification failures to caller.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
If reassoc_same_bss_optim=1 is used to optimize reassociation back to
the same BSS, it was possible for sm->pmk_len to be 0 due to a
disconnection event getting processed after sending out the
reassociation request. This resulted in wpa_sm_rx_eapol() calling
wpa_mic_len() with incorrect PMK length when PMKSA caching was being
attempted. That resulted in incorrect mic_len getting determined and not
finding the correct Key Data Length field value. This could result in
failing to complete 4-way handshake successfully.
Fix this by updating the current PMK length based on the selected PMKSA
cache entry if sm->pmk_len is not set when processing EAPOL-Key msg 1/4.
Signed-off-by: Jouni Malinen <j@w1.fi>
Add override parameters to use the specified channel while populating
OCI element in EAPOL-Key group msg 2/2, FT reassoc request, FILS assoc
request and WNM sleep request frames.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Set the SAE-PK capability bit in RSNXE when sending out (Re)Association
Request frame for a network profile that allows use of SAE-PK.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
wpa_supplicant disables PMKSA caching with FT-EAP by default due to
known interoperability issues with APs. This is allowed only if the
network profile is explicitly enabling caching with
ft_eap_pmksa_caching=1. However, the PMKID for such PMKSA cache entries
was still being configured to the driver and it was possible for the
driver to build an RSNE with the PMKID for SME-in-driver cases. This
could result in hitting the interop issue with some APs.
Fix this by skipping PMKID configuration to the driver fot FT-EAP AKM if
ft_eap_pmksa_caching=1 is not used in the network profile so that the
driver and wpa_supplicant behavior are in sync for this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Convert the previously used text log entries to use the more formal
OCV-FAILURE prefix and always send these as control interface events to
allow upper layers to get information about unexpected operating channel
mismatches.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Make reporting of OCV validation failure reasons more flexible by
removing the fixed prefix from ocv_verify_tx_params() output in
ocv_errorstr so that the caller can use whatever prefix or encapsulation
that is most appropriate for each case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
To support the STA testbed role, the STA has to use specified channel
information in OCI element sent to the AP in EAPOL-Key msg 2/4, SA Query
Request, and SA Query Response frames. Add override parameters to use
the specified channel while populating OCI element in all these frames.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
It was possible for the RSN state machine to maintain old PMKSA cache
selection (sm->cur_pmksa) when roaming to another BSS based on
driver-based roaming indication. This could result in mismatching state
and unexpected behavior, e.g., with not generating a Suite B PMKSA cache
entry.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
"SET dpp_version_override <ver>" can now be used to request
wpa_supplicant and hostapd to support a subset of DPP versions. In
practice, the only valid case for now is to fall back from DPP version 2
support to version 1 in builds that include CONFIG_DPP2=y.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Do not allow association to continue if the local configuration enables
PFS and the station indicates it supports PFS, but PFS was not
negotiated for the association.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new "dpp_pfs=1" entry can be used to determine whether PFS was used
during derivation of PTK when DPP AKM is negotiated for an association.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Check AP's DPP Protocol Version during network introduction and mark the
PMKSA cache as suitable for PFS use with version 2 or newer. This avoids
unnecessary attempt of negotiating PFS with version 1 APs.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Allow wpa_supplicant to be requested to override the RSNXE Used subfield
in FT reassociation case for testing purposes with "SET ft_rsnxe_used
<0/1/2>" where 0 = no override, 1 = override to 1, and 2 = override to
0.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Drivers that trigger roaming need to know the lifetime and reauth
threshold time of configured PMKSA so that they can trigger full
authentication to avoid unnecessary disconnection. To support this, send
dot11RSNAConfigPMKLifetime and dot11RSNAConfigPMKReauthThreshold values
configured in wpa_supplicant to the driver while configuring a PMKSA.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Check whether the Transition Disable KDE is received from an
authenticated AP and if so, whether it contains valid indication for
disabling a transition mode. If that is the case, update the local
network profile by removing the less secure options.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Support Extended Key ID in wpa_supplicant according to
IEEE Std 802.11-2016 for infrastructure (AP) associations.
Extended Key ID allows to rekey pairwise keys without the otherwise
unavoidable MPDU losses on a busy link. The standard is fully backward
compatible, allowing STAs to also connect to APs not supporting it.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
This was not supposed to be conditional on CONFIG_FILS.
Fixes: ecbf59e693 ("wpa_supplicant configuration for Beacon protection")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous design for adding RSNXE into FT was not backwards
compatible. Move to a new design based on 20/332r3 to avoid that issue
by not include RSNXE in the FT protocol Reassociation Request frame so
that an AP not supporting RSNXE can still validate the FTE MIC
correctly.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Verify that the AP included RSNXE in Beacon/Probe Response frames if it
indicated in FTE that RSNXE is used. This is needed to protect against
downgrade attacks based on the design proposed in 20/332r3.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is a workaround needed to keep FT protocol backwards compatible for
the cases where either the AP or the STA uses RSNXE, but the other one
does not. This commit adds setting of the new field to 1 in
Reassociation Request/Response frame during FT protocol when the STA/AP
uses RSNXE in other frames. This mechanism is described in 20/332r3.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
While 13.7.1 (FT reassociation in an RSN) in P802.11-REVmd/D3.0 did not
explicitly require this to be done, this is implied when describing the
contents of the fourth message in the FT authentication sequence (see
13.8.5). Furthermore, 20/332r2 is proposing an explicit validation step
to be added into 13.7.1.
Signed-off-by: Jouni Malinen <j@w1.fi>
While there may have initially been cases where the RSNE from
Beacon/Probe Response frames was not available from some drivers, it is
now more valuable to notice if such a case were to be hit with drivers
that are always expected to have such information available. As such,
make it a fatal error if the scan results for the current AP are not
available to check the RSNE/RSNXE in EAPOL-Key msg 3/4.
Signed-off-by: Jouni Malinen <j@w1.fi>
Avoid printing confusing FT debug entries from wpa_sm_set_ft_params()
when FT is not actually used for the connection.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use the same reason code to indicate that IE different in 4-way
handshake and also print a hexdump of RSNXE in both Beacon/ProbeResp and
EAPOL-Key msg 3/4 in the log.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_tdls_set_key() did set the key_id to -1 to avoid a useless
NL80211_CMD_SET_KEY call that the updated nl80211 driver no longer
carries out. Remove the no longer required workaround.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
The initial implementation of the PTK derivation workaround for
interoperability with older OWE implementations forced
WPA_KEY_MGMT_PSK_SHA256 to be used for all of PTK derivation. While that
is needed for selecting which hash algorithm to use, this was also
changing the length of the PTK components and by doing so, did not
actually address the backwards compatibility issue.
Fix this by forcing SHA256 as the hash algorithm in PTK derivation
without changing the PTK length calculation for OWE when
owe_ptk_workaround is enabled.
Fixes: 65a44e849a ("OWE: PTK derivation workaround in AP mode")
Fixes: 8b138d2826 ("OWE: PTK derivation workaround in STA mode")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
