Enhance QCA_NL80211_VENDOR_SUBCMD_KEY_MGMT_ROAM_AUTH event for the
driver to indicate the information of the associated links of MLO
roaming.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
The initial timeout of 10 seconds for the first scan before knowing
whether the driver reports scan completion events may not be sufficient
in cases where the driver ends up scanning a large number of channels.
In particular, this could be hit with 6 GHz support. Increase this
timeout when the driver indicates support for 6 GHz channels.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The <openssl/buf.h> include is relevant in both OpenSSL and BoringSSL
because the file uses BUF_MEM (include what you use). OpenSSL just
happened to include it via another file. OpenSSL also spells it
<openssl/buffer.h>, not matching the type, so use the compatible
spelling.
Additionally all the CHECKED_CAST and manual STACK_OF(T) definitions
call into BoringSSL internals. The correct, public APIs are simply to
just use the same code as OpenSSL and call the DEFINE_STACK_OF macros.
Signed-off-by: David Benjamin <davidben@google.com>
Commit 74818ca63f ("Process
QCA_NL80211_VENDOR_SUBCMD_KEY_MGMT_ROAM_AUTH after NL80211_CMD_ROAM")
added workaround to hold the pending
QCA_NL80211_VENDOR_SUBCMD_KEY_MGMT_ROAM_AUTH event data for up to 100 ms
in case NL80211_CMD_ROAM is not received first. The 100 ms wait period
was sufficient for most of the cases but it's observed that some times
kernel is taking more than 100 ms to process and send NL80211_CMD_ROAM
to userspace.
If NL80211_CMD_ROAM takes more than 100 ms
QCA_NL80211_VENDOR_SUBCMD_KEY_MGMT_ROAM_AUTH event data getting ignored
though wpa_supplicant has it. To avoid this remove timeout for
QCA_NL80211_VENDOR_SUBCMD_KEY_MGMT_ROAM_AUTH event data since driver
always indicates NL80211_CMD_ROAM along with
QCA_NL80211_VENDOR_SUBCMD_KEY_MGMT_ROAM_AUTH.
In addition, clear the pending event data when marking the interface
disconnected since the roaming information is supposed to be used only
when reassociating without a disconnection.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Previously when chains of BT and WLAN 2.4 GHz are separated,
hybrid mode will be used for BTC. Now adding fixed FDD mode
to fulfill different BTC scenarios.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The Enrollee may report its supported curves in the bootstrapping URI.
If it does that, the Configurator may stop generating the Config Object
that would depend on the Enrollee using a curve that it did not indicate
as being supported. Check for this case while proessing the Config
Request and stop Configurator from building a configuration that is
known not to work.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Select the PMK length based on the used group (prime length) when using
the new AKM suites for SAE.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
SAE authentication needs to known which AKM suite is being used to be
able to determine the correct PMK length for the new AKM suite selectors
that use variable length keys.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The new SAE AKM suites are defined to use H2E, so ignore the sae_pwe
value when these AKM suites are used similarly to the way H2E gets
enabled when SAE Password Identifiers are used.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Update the AKM suite specific mapping of various EAPOL-Key key lengths
and algorithms to include the new SAE AKM suites with variable length
keys.
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>
Use the existing helper function instead of maintaining multiple copies
of lists of SAE key management suites.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The new DPP-RELAY-NEEDS-CONTROLLER control interface event can be used
to trigger mDNS discovery of a Controller to see if such a connection
can be established automatically at the time an Enrollee is trying to
initiate an operation.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The new control interface commands "DPP_RELAY_ADD_CONTROLLER <IP addr>
<PK hash>" and "DPP_RELAY_REMOVE_CONTROLLER <IP addr>" can now be used
to dynamically add and remove connections to Controllers for the cases
where the connection is initialized through a DPP Public Action frame
(i.e., Controller as the Responder).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Instead of requiring explicit configuration through
dpp_configurator_connectivity=1, advertise Configurator connectivity
automatically if a Relay is configured with a Controller that can
operate as a Responder.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Accept an incoming TCP connection from a Controller in a Relay that is
configured with dpp_relay_port even if that Controller is not configured
with a dpp_controller parameter. This allows more dynamic Controller
initiated operations, e.g., when using mDNS to discover a Relay.
This type of a dynamic Controller entry will not be used for exchanges
that are initiated by an Enrollee (i.e., based on a DPP Public Action
frame received by the Relay).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Verify that the peer does not change its bootstrapping key between the
PKEX exchange and the authentication exchange.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
When PKEX was started through the push button mechanism, the own
bootstrapping key was not bound correctly to the Authentication phase
information and that ended up in incorrectly generating a new
bootstrapping key for the Authentication exchange. Fix this by added the
needed own=<id> parameter into the cached parameters when using push
button.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The peer=<id> information about the specific boostrapping key provided
through PKEX was added for Public Action frame cases, but the TCP
variant did not do same. Add the same information there to maintain
knowledge of the specific peer bootstrapping key from PKEX to
Authentication exchange.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Extend DPP push button support in wpa_supplicant to allow the role of
the Configurator to be used. This provides similar functionality to the
way the DPP_PUSH_BUTTON command in hostapd worked when providing the
configuration parameters with that command (instead of building the
config object based on current AP configuration).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
It is possible for a Controller to receive a copy of its own PKEX
Exchange Request in the case where the Controller is initiating a PKEX
exchange through a Relay. The Configurator role in the device would have
a matching PKEX code in that case and the device might reply as a PKEX
responder which would result in going through the exchange with the
Controller device itself. That is clearly not desired, so recognize this
special case by checking whether the Encrypted Key attribute value
matches a pending locally generated one when processing a received PKEX
Exchange Request.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This gets the Controller (DPP-over-TCP) sequence closer to the one used
with Public Action frames and makes it easier for upper layer components
to share the same design for tracking operation status.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Relay will need to allow the PKEX Exchange Response message to be
handled similarly to the Authentication Response message to allow this
sequence to be completed successfully.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
We are not supposed to reuse these without being explicitly requested to
perform PKEX again. There is not a strong use case for being able to
provision an Enrollee multiple times with PKEX, so this should have no
issues on the Enrollee. For a Configurator, there might be some use
cases that would benefit from being able to use the same code with
multiple Enrollee devices, e.g., for guess access with a laptop and a
smart phone. That case will now require a new DPP_PKEX_ADD command on
the Configurator after each completion of the provisioning exchange.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add a privacy protecting variant of the peer introduction protocol to
allow the station device to hide its Connector from 3rd parties. The new
wpa_supplicant network profile parameter dpp_connector_privacy=1 can be
used to select this alternative mechanism to the peer introduction
protocol added in the initial release of DPP.
It should be noted that the new variant does not work with older DPP APs
(i.e., requires support for release 3). As such, this new variant is
disabled by default.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add support for HPKE base mode with single-shot API (see RFC 9180) using
OpenSSL. This is needed for DPP private introduction protocol.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This allows the DPP Configuration Object from a Configurator to be
extended with 3rd party information. This information can be provided as
a part of the existing configuration specification mechanisms with the
new extra_name=<string> and extra_value=<hexdump encoded JSON>.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This allows the DPP Configuration Request Object from an Enrollee to be
extended with 3rd party information. The new dpp_extra_conf_req_name and
dpp_extra_conf_req_value configuration parameters specify the name of
the added JSON node and its contents. For example:
dpp_extra_conf_req_name=org.example
dpp_extra_conf_req_value={"a":1,"b":"test"}
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add a new vendor subcommand QCA_NL80211_VENDOR_SUBCMD_SCS_RULE_CONFIG
for configuration event of Stream Classification Service (SCS) rule.
Also define the attributes present in this subcommand.
Signed-off-by: Harsh Kumar Bijlani <quic_hbijlani@quicinc.com>
Add a new vendor attribute QCA_WLAN_VENDOR_ATTR_CONFIG_DBAM to
configure Dedicated Bluetooth Antenna Mode (DBAM). It is used to
switch between dedicated antenna mode for BT and COEX shared
antenna mode for WLAN and BT.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Allow the Responder/Initiator hash values to be corrupted in Push Button
Presence Announcement messages for testing purposes.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Yu Wang <quic_yyuwang@quicinc.com>
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>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Purushottam Kushwaha <quic_pkushwah@quicinc.com>
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.
Signed-off-by: Purushottam Kushwaha <quic_pkushwah@quicinc.com>
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.
Signed-off-by: Aleti Nageshwar Reddy <quic_anageshw@quicinc.com>
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.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
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.
Signed-off-by: Purushottam Kushwaha <quic_pkushwah@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Sreeramya Soratkal <quic_ssramya@quicinc.com>
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.
Signed-off-by: Jianmin Zhu <quic_jianminz@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Jouni Malinen <j@w1.fi>
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.
Signed-off-by: Jouni Malinen <j@w1.fi>
The EVP_MAC context data needs to be freed on error paths.
Fixes: e31500adea ("OpenSSL: Implement HMAC using the EVP_MAC API")
Signed-off-by: Jouni Malinen <j@w1.fi>
The conversion to the new OpenSSL 3.0 API had forgotten to free the
context structure.
Fixes: bcd299b326 ("OpenSSL: Convert DH/DSA parameter loading to new API")
Signed-off-by: Jouni Malinen <j@w1.fi>
Extend IMSI privacy functionality to allow an attribute (in name=value
format) to be added using the new imsi_privacy_attr parameter.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This is an allocated resource so it needs to be free on the error path.
Fixes: 42871a5d25 ("EAP-SIM/AKA peer: IMSI privacy")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Commit 9afb68b039 ("OpenSSL: Allow systemwide secpolicy overrides for
TLS version") with commit 58bbcfa31b ("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.
Signed-off-by: Jouni Malinen <j@w1.fi>
tcp_addr=from-uri can now be used as a special case for initiating
DPP-over-TCP to the destination indicated in the peer bootstrapping URI.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Parse the host information, if present, in bootstrapping URI and allow
such information to be added when generating the URI.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
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.
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>
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.
Signed-off-by: Jouni Malinen <j@w1.fi>
Avoid the somewhat confusing mechanism of determining the bitfield index
from the assigned IP address to make this easier for static analyzers.
Signed-off-by: Jouni Malinen <j@w1.fi>
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.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use local variables and common checking of the selector (or vendor
specific IE header) to make the bounds checking easier to understand.
Signed-off-by: Jouni Malinen <j@w1.fi>
BIT(r) is not sufficient here since it does not cover 64 bit values.
Write this out with 1ULL to be large enough for the shift operation.
Signed-off-by: Jouni Malinen <j@w1.fi>
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.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is testing code, but it's better to check the return value
explicitly even if this were not really able to fail in practice.
Signed-off-by: Jouni Malinen <j@w1.fi>
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.
Signed-off-by: Jouni Malinen <j@w1.fi>
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.
Signed-off-by: Jouni Malinen <j@w1.fi>
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>
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.
Fixes: 024b4b2a29 ("AP: Unsolicited broadcast Probe Response configuration")
Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.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-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.
Signed-off-by: Jouni Malinen <j@w1.fi>
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.
Signed-off-by: Jouni Malinen <j@w1.fi>
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>
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: da24c5aa1c ("FILS: Set TK after association (AP)")
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>
wpa_validate_wpa_ie() might update sm->* values, so it should not be
allowed for an existing STA entry if that STA has negotiated MFP to be
used for the association. Fix this by first checking whether an SA Query
procedure needs to be initiated. In particular, this prevents a
potential bypass of the disconnection protection.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The driver can consider EHT specific parameters such as the puncture
pattern for ACS when this flag attribute is indicated by userspace.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Add a check to avoid sending VHT channel definition when EHT is enabled
in the 2.4 GHz band since the 2.4 GHz band isn't supposed to use VHT
operations. Also add EHT enabled info into debug prints.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Do not consider optional octets maximum lengths when validating EHT
fixed fields length. Furthermore, do not use the first two octets of the
PPE Thresholds field without explicitly confirming that these octets
were included in the element and fix PPE Thresholds field length
calculation.
Fixes: a6d1b4c46c ("EHT: Process (Re)Association Request frame capabilities")
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
enum macaddr_acl is forward declared in wpa_supplicant/ap.h.
c++ compiler doesn't allow forward declaration. So to fix the
compilation error, moved the enum macaddr_acl declaration out
of struct hostapd_bss_config.
Signed-off-by: Sunil Ravi <sunilravi@google.com>
The OCSP check here is specific to TLS 1.3 and the TLS1_3_VERSION value
is not available in older library versions. Comment this check out from
such cases since it is not applicable with such an old library.
Fixes: 10746875e2 ("OpenSSL: Allow no OCSP response when resuming a session with TLS 1.3")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
LibreSSL does not seem have SSL_CTX_set_num_tickets(), so comment out
these not really critical calls when building with that library.
Fixes: 81e2498889 ("OpenSSL: Limit the number of TLS 1.3 session tickets to one")
Fixes: decac7cd1e ("OpenSSL: Do not send out a TLS 1.3 session ticket if caching disabled")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
EVP_PKEY_CTX_set_rsa_oaep_md() does not seem to be available in
LibreSSL, so for now, comment out this functionality whenever building
with that library.
Fixes: 36b11bbcff ("OpenSSL: RSA-OAEP-SHA-256 encryption/decryption")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
SSL_CTX_set_num_tickets() is not available in boringSSL.
So protect the call to SSL_CTX_set_num_tickets() under
!defined(OPENSSL_IS_BORINGSSL) to fix the compilation error.
Fixes: decac7cd1e ("OpenSSL: Do not send out a TLS 1.3 session ticket if caching disabled")
Fixes: 81e2498889 ("OpenSSL: Limit the number of TLS 1.3 session tickets to one")
Signed-off-by: Sunil Ravi <sunilravi@google.com>
Add a notification message to indicate reason for TLS handshake failure
due to the server not supporting safe renegotiation (RFC 5746).
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The TLS protocol design for renegotiation was identified to have a
significant security flaw in 2009 and an extension to secure this design
was published in 2010 (RFC 5746). However, some old RADIUS
authentication servers without support for this are still used commonly.
This is obviously not good from the security view point, but since there
are cases where the user of a network service has no realistic means for
getting the authentication server upgraded, TLS handshake may still need
to be allowed to be able to use the network.
OpenSSL 3.0 disabled the client side workaround by default and this
resulted in issues connection to some networks with insecure
authentication servers. With OpenSSL 3.0, the client is now enforcing
security by refusing to authenticate with such servers. The pre-3.0
behavior of ignoring this issue and leaving security to the server can
now be enabled with a new phase1 parameter allow_unsafe_renegotiation=1.
This should be used only when having to connect to a network that has an
insecure authentication server that cannot be upgraded.
The old (pre-2010) TLS renegotiation mechanism might open security
vulnerabilities if the authentication server were to allow TLS
renegotiation to be initiated. While this is unlikely to cause real
issues with EAP-TLS, there might be cases where use of PEAP or TTLS with
an authentication server that does not support RFC 5746 might result in
a security vulnerability.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Some of the TLS library wrappers defined only an empty function for
tls_connection_set_success_data(). That could result in memory leaks in
TLS server cases, so update these to do the minimal thing and free the
provided buffer as unused.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
When a new session ticket is not issued to the peer, Phase 2 identity
request need to be sent out as a response to the Finished message from
the peer. Fix this to allow the TLS server to be configured to not send
out a new session ticket when using TLS 1.3.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
TLS 1.3 sends the OCSP response with the server Certificate message.
Since that Certificate message is not sent when resuming a session,
there can be no new OCSP response. Allow this since the OCSP response
was validated when checking the initial certificate exchange.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The internal flag prot_success_received was not cleared between the
sessions and that resulted in the resumed session not mandating the
protected success indication to be received. Fix this by clearing the
internal flag so that the EAP-TLS handshake using session resumption
with TLS 1.3 takes care of the required check before marking the
authentication successfully completed. This will make the EAP-TLS peer
reject an EAP-Success message should it be received without the
protected success indication.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The final message with NewSessionTicket and ApplicationData(0x00) was
already generated, but that was not sent out due the session considered
to be already completed. Fix this by actually sending out that message
to allow the peer to receive the new session ticket and protected
success indication when using resuming a session with TLS 1.3.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
One session ticket is sufficient for EAP-TLS, so do not bother
generating more than a single session ticket.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
A port of the trivial patch I wrote for FreeRADIUS to allow TLS decoding
in Wireshark for hostapd/wpa_supplicant:
df0eb0a884
Signed-off-by: Alexander Clouter <alex@coremem.com>
This may fail with FIPS builds because the FIPS requirement is that the
password must be at least 14 characters.
Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
pbkdf2_sha1() may return errors and this should be checked in calls.
This is especially an issue with FIPS builds because the FIPS
requirement is that the password must be at least 14 characters.
Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
Some API is not available when using FIPS. We need to allocate memory
and initialize the structs directly.
Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
Register a callback with wolfCrypt_SetCb_fips to inform the user of
errors in the wolfCrypt FIPS module.
Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
In some configurations the wc_Init*() functions may either allocate
memory or other system resources. These resources need to be freed.
Co-authored-by: JacobBarthelmeh <jacob@wolfssl.com>
Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
Add support for loading private keys and certificates in both PEM and
DER formats with wolfSSL.
Signed-off-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
Add support for IMSI privacy in the EAP-SIM/AKA peer implementation. If
the new wpa_supplicant network configuration parameter imsi_privacy_key
is used to specify an RSA public key in a form of a PEM encoded X.509v3
certificate, that key will be used to encrypt the permanent identity
(IMSI) in the transmitted EAP messages.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add support for IMSI privacy in the EAP-SIM/AKA server implementation.
If the new hostapd configuration parameter imsi_privacy_key is used to
specify an RSA private key, that key will be used to decrypt encrypted
permanent identity.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Add new crypto wrappers for performing RSA-OAEP-SHA-256 encryption and
decryption. These are needed for IMSI privacy.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Modify hostapd_set_freq_params() to include EHT parameters and update
the calling functions to match.
Signed-off-by: Muna Sinada <quic_msinada@quicinc.com>
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Set bit 21 in the neighbor report for an EHT AP as described in IEEE
P802.11be/D1.5, 9.4.2.36. Also move the check for HE outside the check
for HT as neither HT nor VHT are enabled in the 6 GHz band.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Add support for EHT capabilities in the addition of a new station entry
to the driver.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Parse EHT capabilities sent by a non-AP STA in (Re)Association Request
frames. Validate the length of the element, matching MCS rates between
AP TX and STA RX. Store the capabilities in the station info structure.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Parse and store pointers to EHT Capabilities and Operation elements
received in Management frames.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Add EHT Operation element in Beacon, Probe Response, and (Re)Association
Response frames using the format described in IEEE P802.11be/D1.5,
9.4.2.311.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Muna Sinada <quic_msinada@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Add new configuration options to configure EHT operating channel
width and center frequency.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Add compilation support for IEEE 802.11be along with options to enable
EHT support per radio and disable per interface.
Enabling HE is mandatory to enable EHT mode.
Tested-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Pass non-AP STA's EHT capabilities to the driver using the
NL80211_ATTR_EHT_CAPABILITY attribute.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Add nl80211 support to parse the EHT capabilities passed by the kernel
using new attributes added in NL80211_BAND_ATTR_IFTYPE_DATA.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
Define the following fields described in IEEE P802.11be/D1.5:
- 9.4.2.311 EHT Operation element
- 9.4.2.313 EHT Capabilities element
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com>
