DPP: Allow AP/Relay to be configured to listed for new TCP connections
This extends Relay functionality to allow a Controller to intitiate a
new DPP exchange in addition to the previously supported case where the
exchange was initiated through a DPP Public Action frame.
DPP3: Allow external configuration to be specified on AP for PB
While the most likely production use case for DPP push button is to
provision the AP's current configuration, there might be some use cases
for providing different configuration. Add possibility for doing this by
extending the DPP_PUSH_BUTTON command to accept an optional set of
parameters similarly to the other DPP commands for the Configurator.
Add support to use a push button -based bootstrap mechanism with DPP.
The new DPP_PUSH_BUTTON control interface command enables this mode on
the AP/hostapd and station/wpa_supplicant. This goes through the
following sequence of events: a suitable peer in active push button mode
is discovered with session overlap detection, PKEX is executed with
bootstrap key hash validation, DPP authentication and configuration
exchanges are performed.
Add AP and STA specific P802.11az security capabilities (vendor command)
Add feature capability indication for P802.11az security for the drivers
to advertise capabilities such as secure LTF support, secure RTT
measurement exchange support, and protection of range negotiation and
measurement management frames for station and AP interfaces
independently. This allows a more fine-tuned capability indication as an
alternative to the upstream nl80211 mechanism that is not specific to
the operating mode.
Yu Wang [Tue, 24 May 2022 10:10:23 +0000 (18:10 +0800)]
QCA vendor command for CoAP offload processing
Add vendor command QCA_NL80211_VENDOR_SUBCMD_COAP_OFFLOAD to
enable/disable offload processing in firmware for CoAP messages
(RFC7252: The Constrained Application Protocol) or fetch the
CoAP messages cached during offload processing.
Jingxiang Ge [Wed, 15 Jun 2022 03:22:18 +0000 (11:22 +0800)]
Add QCA vendor attribute for TIM beacon statistics
Add the following two vendor attributes to send TIM beacon
statistics to userspace which can be used for power saving:
QCA_WLAN_VENDOR_ATTR_LL_STATS_TIM_BEACON
QCA_WLAN_VENDOR_ATTR_LL_STATS_TIM_BEACON_ERR
Signed-off-by: Jingxiang Ge <quic_jge@quicinc.com>
Vinay Gannevaram [Mon, 13 Jun 2022 11:43:50 +0000 (17:13 +0530)]
Add QCA vendor interface for PASN offload to userspace
Define QCA vendor interface for PASN offload to userspace from the driver.
The driver can send this command as an event to a userspace component to
perform PASN authentication with a list of peers with which the driver
needs to do ranging. The userspace component, if capable of performing
PASN handshake, can perform PASN handshake with all the peer devices and
set the relevant keys by sending the
QCA_NL80211_VENDOR_SUBCMD_SECURE_RANGING_CONTEXT command for each peer
to the driver.
Once PASN handshake is completed with all requested peers, the userspace
component sends consolidated status for all the peers to the driver. The
consolidated report is required for the driver to understand that the
PASN handshake process is complete and whether it succeeded/failed for
each of the peers it was requested for. The secure ranging context is
configured only for the peers with which the PASN handshake succeeded.
When the driver requests PASN keys, the userspace component can set the
keys from its cache if those keys have not already expired and were
derived with the same source MAC address that is requested by the driver
instead of doing the full PASN handshake again.
If the driver detects that current keys of a peer are not valid anymore,
it sends a notification to userspace using the
QCA_NL80211_VENDOR_SUBCMD_PASN command and setting the action to
QCA_WLAN_VENDOR_PASN_ACTION_DELETE_SECURE_RANGING_CONTEXT. The userspace
component should delete the corresponding keys from its cache.
Add a vendor attribute to configure concurrency policy for AP interface
Add a new QCA vendor attribute
QCA_WLAN_VENDOR_ATTR_CONCURRENT_POLICY_AP_CONFIG to
QCA_NL80211_VENDOR_SUBCMD_CONCURRENT_POLICY sub command to set the
concurrency policy for AP interface.
QCA_WLAN_VENDOR_ATTR_CONCURRENT_POLICY_AP_CONFIG uses the values
defined in enum qca_wlan_concurrent_ap_policy_config to specify
concurrency policy.
Rename QCA_NL80211_VENDOR_SUBCMD_CONCURRENT_MULTI_STA_POLICY to
QCA_NL80211_VENDOR_SUBCMD_CONCURRENT_POLICY to allow extension for other
interface type(s). A subsequent commit will extend the renamed
definitions in a manner that is inconsistent with the current naming.
This is a precursor for AP/P2P concurrency policy configuration support
via updated vendor command QCA_NL80211_VENDOR_SUBCMD_CONCURRENT_POLICY.
Move CHANWIDTH_* definitions from ieee80211_defs.h to defs.h
Move most of CHANWIDTH_* definitions from ieee80211_defs.h to defs.h as
the definitions are getting used mostly for internal purpose only. Also
change prefix of the definitions to CONF_OPER_CHWIDTH_* and update in
all the files accordingly.
Leave the couple of VHT-specific exceptions to use the old defines (the
reason why they were originally added as VHT values), to avoid use of
clearly marked configuration values in information elements. In
addition, use the defines instead of magic values where appropriate.
Jouni Malinen [Thu, 16 Jun 2022 17:26:11 +0000 (20:26 +0300)]
tests: Make OCV negative test error cases more robust
Try to avoid an exception while processing an exception that indicates
the test case failed. Explicit DISCONNECT command here can avoid the
undesired FAIL-BUSY from cleanup SCAN.
Add QCA vendor event to indicate driver recovery after internal failures
Add QCA vendor event to indicate user space that the driver recovery is
completed after the internal failure reported with
QCA_NL80211_VENDOR_SUBCMD_HANG.
Xinyue Ling [Mon, 13 Jun 2022 06:29:56 +0000 (14:29 +0800)]
Set current_ssid before changing state to ASSOCIATING
For hidden GBK encoding of a Chinese SSID, both the UTF-8 and GBK
encoding profiles are added into wpa_supplicant to make sure the
connection succeeds. In this situation, wpa_supplicant_select_network()
will not be called so current_ssid is NULL when association begins.
Android monitors the WPA_EVENT_STATE_CHANGE event to get the SSID and
BSSID. When connecting to a Chinese SSID, in case of association
rejection happens, Android will report null SSID to OEM APP because
current_ssid is updated after wpa_supplicant_set_state(wpa_s,
WPA_ASSOCIATING), which may cause confusion.
Fix this by setting the current_ssid before changing state to
ASSOCIATING.
QCA vendor attribute to configure direct data path for audio traffic
Add a new QCA vendor attribute
QCA_WLAN_VENDOR_ATTR_CONFIG_AUDIO_DATA_PATH to
QCA_NL80211_VENDOR_SUBCMD_SET_WIFI_CONFIGURATION to configure audio data
path.
Possible audio data paths are defined in enum qca_wlan_audio_data_path.
QCA vendor command support to get WLAN radio combinations
Vendor command to get the WLAN radio combinations matrix supported by
the device which provides the device simultaneous radio configurations
such as standalone, dual band simultaneous, and single band
simultaneous.
Jouni Malinen [Tue, 14 Jun 2022 14:19:27 +0000 (17:19 +0300)]
OCV: Check the Frequency Segment 1 Channel Number only on 80+80 MHz
The initial OCV implementation validating this field in the OCI element
for both the 80+80 MHz and 160 MHz cases. However, IEEE Std 802.11-2020,
12.2.9 ("Requirements for Operating Channel Validation") limitis that
verification step for the 80+80 MHz case: "Verifying that, if operating
an 80+80 MHz operating class, the frequency segment 1 channel number ...
is equal to the Frequency Segment 1 Channel Number field of the OCI."
Remove this check for the 160 MHz case since there has been incorrect
interpretation on how the Frequency Segment 1 Channel Number field of
the OCI element is set in this case (using VHT rules for CCFS2). The
modified validation step is meets the real need here, is compliant with
the standard, and avoids potential interoperability issues when using
contiguous 160 MHz channels.
P2P: Use weighted preferred channel list for channel selection
Previously, the driver could optionally (using QCA vendor command)
provide a preferred channel list to wpa_supplicant for channel selection
during the GO negotiation. Channel selection process can be more
efficient with the information of weights and flags of the preferred
channel list that can be provided by the driver. Use a weighted
preferred channel list provided by the driver for channel selection
during GO negotiation if such a list is available.
Jianmin Zhu [Wed, 18 May 2022 14:32:26 +0000 (22:32 +0800)]
QCA vendor attribute to configure RX link speed threshold for roaming
Add QCA_ATTR_ROAM_CONTROL_RX_LINKSPEED_THRESHOLD value as the RX link
speed threshold to disable roaming. If the current link speed is above
the threshold, there is no need to roam.
Add QCA vendor attribute for DO_ACS to allow using existing scan entries
Add a new QCA vendor attribute
QCA_WLAN_VENDOR_ATTR_ACS_LAST_SCAN_AGEOUT_TIME to
QCA_NL80211_VENDOR_SUBCMD_DO_ACS and opportunistically optimize time
taken for ACS scan. Avoid scanning the channels which were scanned
within last QCA_WLAN_VENDOR_ATTR_ACS_LAST_SCAN_AGEOUT_TIME milliseconds
and use scan results from the scan results cache for ACS scoring. For
other channels, perform ACS scan and use the received scan results.
Qiwei Cai [Mon, 9 May 2022 05:16:37 +0000 (13:16 +0800)]
P2P: Filter 6 GHz channels if peer doesn't support them
When 6 GHz channels are included in channel list of P2P Action frames
but some peer devices don't support the 6 GHz feature and cannot parse
P2P IE data correctly, P2P handshake will fail.
Remove 6 GHz channels from the P2P Action frames if the peer doesn't
support 6 GHz feature to avoid such failures.
A few of the comments in the QCA vendor commands have a space
character before a tab. That is pointless, and some code style
checkers may complain about it, so remove the spaces.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Jouni Malinen [Tue, 31 May 2022 08:53:05 +0000 (11:53 +0300)]
ProxyARP: Clear bridge parameters on deinit only if hostapd set them
Skip the x_snoop_deinit() operations if hostapd did not actually
configure the parameters in the first place. While clearing these
specific parameters is unlikely to change how they were set outside the
scope of hostapd, it is better to leave them as-is to avoid surprises if
hostapd was not configured to use ProxyARP.
Jouni Malinen [Thu, 26 May 2022 20:40:09 +0000 (23:40 +0300)]
FIPS PRF: Avoid duplicate SHA1Init() functionality
The initialization values used for the FIPS 186-2 PRF are identical to
the ones used in SHA1Init(), so use that internal function instead of
maintaining a duplicate set of values here. fips186_2_prf() was already
using an internal SHA1Transform() function so using another internal
function does not make this any worse.
Jouni Malinen [Thu, 26 May 2022 20:35:16 +0000 (23:35 +0300)]
OpenSSL: Use internal FIPS 186-2 PRF with OpenSSL 3.0
OpenSSL 3.0 has deprecated the low-level SHA1 functions and does not
include an upper layer interface that could be used to use the
SHA1_Transform() function. Use the internal SHA-1 implementation instead
as a workaround.
While this type of duplicate implementation of SHA-1 is not really
ideal, this PRF is needed only for EAP-SIM/AKA and there does not seem
to be sufficient justification to try to get this working more cleanly
with OpenSSL 3.0.
Use imsi_privacy_cert as the name of the configuration parameter for the
X.509v3 certificate that contains the RSA public key needed for IMSI
privacy. The only allowed format for this information is a PEM-encoded
X.509 certificate, so the previous name was somewhat confusing.
Jouni Malinen [Mon, 23 May 2022 20:46:37 +0000 (23:46 +0300)]
Do not try to use network profile with invalid imsi_privacy_key
Disable a network profile that has set the imsi_privacy_key if a valid
key cannot be read from the specified file. Previously, this check was
done only after having associated, but there is no point in associating
just to see EAP authentication fail in such a case. This is needed for
avoiding connection attempts if the X.509 certificate for IMSI privacy
has expired.
Jouni Malinen [Sun, 22 May 2022 14:01:35 +0000 (17:01 +0300)]
OpenSSL: Drop security level to 0 with OpenSSL 3.0 when using TLS 1.0/1.1
Commit 9afb68b03976 ("OpenSSL: Allow systemwide secpolicy overrides for
TLS version") with commit 58bbcfa31b18 ("OpenSSL: Update security level
drop for TLS 1.0/1.1 with OpenSSL 3.0") allow this workaround to be
enabled with an explicit network configuration parameter. However, the
default settings are still allowing TLS 1.0 and 1.1 to be negotiated
just to see them fail immediately when using OpenSSL 3.0. This is not
exactly helpful especially when the OpenSSL error message for this
particular case is "internal error" which does not really say anything
about the reason for the error.
It is is a bit inconvenient to update the security policy for this
particular issue based on the negotiated TLS version since that happens
in the middle of processing for the first message from the server.
However, this can be done by using the debug callback for printing out
the received TLS messages during processing.
Drop the OpenSSL security level to 0 if that is the only option to
continue the TLS negotiation, i.e., when TLS 1.0/1.1 are still allowed
in wpa_supplicant default configuration and OpenSSL 3.0 with the
constraint on MD5-SHA1 use.
Johannes Berg [Sun, 22 May 2022 08:46:09 +0000 (11:46 +0300)]
tests: Work around reentrant logging issues due to __del__ misuse
Unfortunately, some objects (WlantestCapture, WpaSupplicant
and wpaspy.Ctrl) use __del__ and actually have some logic
there. This is more or less wrong, and we should be using
context managers for it. However, cleaning that up is a
pretty large task.
Unfortunately, __del__ can cause reentrant logging which is
wrong too, because it might be invoked while in the middle
of a logging call, and the __del__ of these objects closes
connections and logs while doing that.
Since we're (likely) using cpython, we can work around this
by explicitly calling gc.collect() in a context where the
logging and close is fine, not only ensuring that all the
connections are closed properly before the next test, but
also fixing the issue with reentrant logging.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Jouni Malinen [Sun, 22 May 2022 08:43:38 +0000 (11:43 +0300)]
tests: Clean up failed test list in parallel-vm.py
Instead of printing a very long line of the failed tests, print the test
case names on separate lines up to the number of available lines at the
bottom of the screen. This avoids some issues with curses and overlong
lines. Furthermore, display the last failed test cases instead of
somewhat confusing sequence of test case names from the VMs.
Jouni Malinen [Mon, 16 May 2022 16:39:57 +0000 (19:39 +0300)]
EHT: Do not check HE PHY capability info reserved fields
Only use the bandwidth bits that are applicable for the current
operating band. This avoids use of reserved bits when determining the
length of the Support EHT-MCS And NSS Set field length.
Jouni Malinen [Mon, 16 May 2022 16:06:47 +0000 (19:06 +0300)]
tests: Update ap_wpa2_psk_ext_delayed_ptk_rekey to match implementation
This test case was checking the exact key info bits in EAPOL-Key frames
during PTK rekeying as such, needs to be updated to match the
implementation change on the Secure bit setting.
Jouni Malinen [Mon, 16 May 2022 14:34:12 +0000 (17:34 +0300)]
Use Secure=1 in PTK rekeying EAPOL-Key msg 1/4 and 2/4
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.
Jouni Malinen [Mon, 9 May 2022 08:45:33 +0000 (11:45 +0300)]
tests: Wait for request before responding in dscp_response
There was a possible race condition here between the hostapd request
transmission and wpa_supplicant response command. Wait for the
wpa_supplicant event that indicates reception of the request before
issuing the DSCP_RESP command to avoid failures.
Jouni Malinen [Sun, 8 May 2022 14:18:58 +0000 (17:18 +0300)]
FST: More robust bounds checking of local data in fst_dump_mb_ies()
Check the full MBIE length against the buffer length explicitly before
the debug print. This is for locally generated data, so the bounds
checking is not critical here, but it is better to use proper checking
anyway to avoid static analyzer complaints.
Jouni Malinen [Sun, 8 May 2022 09:02:40 +0000 (12:02 +0300)]
GAS: Limit maximum comeback delay value
Limit the GAS comeback delay to 60000 TUs, i.e., about 60 seconds. This
is mostly to silence static analyzers that complain about unbounded
value from external sources even though this is clearly bounded by being
a 16-bit value.
Jouni Malinen [Sun, 8 May 2022 09:19:42 +0000 (12:19 +0300)]
WNM: Try to make bounds checking easier for static analyzers
The length of the URL, i.e., pos[0], is verified here to be within the
bounds of the recieved message, but that seemed to be done in a manner
that might bee too complex for static analyzers to understand.
Jouni Malinen [Sat, 7 May 2022 21:39:20 +0000 (00:39 +0300)]
Check he_cap pointer in hostapd_set_freq_params() consistently
The EHT changes made this checking inconsistent. If he_cap can be NULL
in case of EHT being enabled, better make sure it does not get
dereferenced without an explicit check.
Jouni Malinen [Sat, 7 May 2022 21:27:51 +0000 (00:27 +0300)]
FST: Make sure get_hw_modes() callback is set for hostapd
It looks like fst_wpa_obj::get_hw_modes would have been left
uninitialized in hostapd. It is not obviously clear why this would not
have caused issues earlier, but in any case, better make this set
properly to allow unexpected behavior should that function pointer ever
be used.
Jouni Malinen [Sat, 7 May 2022 20:58:03 +0000 (23:58 +0300)]
P2P: Explicit nul termination of the generated passphrase
Nul terminate the struct p2p_go_neg_results::passphrase explicitly to
keep static analyzers happier. This was already nul terminated in
practice due to the full array being cleared to zero on initialization,
but that was apparently not clear enough for some analyzers.
Ilan Peer [Sun, 24 Apr 2022 09:57:53 +0000 (12:57 +0300)]
scan: Add option to disable 6 GHz collocated scanning
Add a parameter (non_coloc_6ghz=1) to the manual scan command to disable
6 GHz collocated scanning.
This option can be used to disable 6 GHz collocated scan logic. Note
that due to limitations on Probe Request frame transmissions on the 6
GHz band mandated in IEEE Std 802.11ax-2021 it is very likely that
non-PSC channels would be scanned passively and this can take a
significant amount of time.
nl80211: Set NL80211_SCAN_FLAG_COLOCATED_6GHZ in scan
Set NL80211_SCAN_FLAG_COLOCATED_6GHZ in the scan parameters to enable
scanning for co-located APs discovered based on neighbor reports from
the 2.4/5 GHz bands when not scanning passively. Do so only when
collocated scanning is not disabled by higher layer logic.
Signed-off-by: Tova Mussai <tova.mussai@intel.com> Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Avraham Stern <avraham.stern@intel.com>
MeiChia Chiu [Fri, 6 May 2022 03:02:36 +0000 (11:02 +0800)]
hostapd: Add the destination address of unsolicited Probe Response frame
Without this, hostapd generates Probe Response frames with the null
destination address when hostapd enables unsolicited Probe Response
frame transmission. Fix this to use the broadcast address instead.
Jouni Malinen [Sat, 7 May 2022 15:10:17 +0000 (18:10 +0300)]
Discard unencrypted EAPOL/EAP when TK is set and PMF is enabled (AP)
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-Start and
EAPOL-Logoff are potential candidate for such attacks since those frames
could be used to terminate an authentication or initiate a new EAP
authentication. Such an attack could result in the station ending up
disconnecting or at minimum, getting into somewhat mismatching state
with the AP.
Drop EAPOL-Start/Logoff/EAP frames on the AP/Authenticator 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.
Jouni Malinen [Sat, 7 May 2022 14:42:51 +0000 (17:42 +0300)]
Discard unencrypted EAPOL-EAP when TK is set and PMF is enabled
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. EAP-Request is one
potential candidate for such attacks since that frame could be used to
initiate a new EAP authentication and the AP/Authenticator might not
allow that to complete or a large number of EAP-Request frames could be
injected to exceed the maximum number of EAP frames. Such an attack
could result in the station ending up disconnecting or at minimum,
getting into somewhat mismatching state with the AP.
Drop EAPOL-EAP frames 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.
Jouni Malinen [Sat, 7 May 2022 08:54:16 +0000 (11:54 +0300)]
Discard unencrypted EAPOL-Key msg 1/4 when TK is set and PMF is enabled
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.
Jouni Malinen [Sat, 7 May 2022 08:14:50 +0000 (11:14 +0300)]
Do not prevent Michael MIC error report based on disallowed PTK0 rekey
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.
Jouni Malinen [Fri, 6 May 2022 21:38:35 +0000 (00:38 +0300)]
Provide information about the encryption status of received EAPOL frames
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.
Jouni Malinen [Sat, 7 May 2022 17:34:07 +0000 (20:34 +0300)]
FILS: Set pairwise_set when configuring TK after association
sm->pairwise_set needs to be set whenever the TK has been configured to
the driver to request following EAPOL frames to be encrypted (or more
specifically, not to request them to not be encrypted). The FILS case
missed this setting and that could result in rekeying or
reauthentication in an associated started with FILS not working
correctly.
Fixes: da24c5aa1c47 ("FILS: Set TK after association (AP)") Signed-off-by: Jouni Malinen <j@w1.fi>
Jouni Malinen [Fri, 6 May 2022 21:58:41 +0000 (00:58 +0300)]
Fix no_encrypt flag in control port TX for rekeying
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: a79ed0687197 ("Add no_encrypt flag for control port TX") Signed-off-by: Jouni Malinen <j@w1.fi>
Domien Schepers [Thu, 5 May 2022 19:53:26 +0000 (21:53 +0200)]
WPA: Discard EAPOL-Key msg 1/4 with corrupted information elements
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).
projects / thirdparty / hostap.git / log
