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>
As per RFC 8110 (Opportunistic Wireless Encryption), if the AP has the
PMK identified by the PMKID and wishes to perform PMK caching, it will
include the PMKID in the Association Response frame RSNE but does not
include the Diffie-Hellman Parameter element.
This was already addressed for most cases with owe_process_assoc_req()
not setting sta->owe_ecdh in case PMKSA caching is used. However, it was
possible to an old STA entry to maintain the initial sta->owe_ecdh value
if reassociation back to the same AP was used to initiate the PMKSA
caching attempt. Cover that case by adding an explicit check for the
time when the Association Response frame is being generated.
Signed-off-by: Chittur Subramanian Raman <craman@maxlinear.com>
Modify the check for VHT to include an option for HE in
hostapd_eid_wb_chsw_wrapper() and its callers to allow the Channel
Switch Wrapper element with the Wide Bandwidth Channel Switch subelement
to be included in Beacon and Probe Response frames when AP is operating
in HE mode without VHT.
Signed-off-by: Muna Sinada <msinada@codeaurora.org>
Move hostapd_eid_wb_chsw_wrapper() from VHT specific ieee802_11_vht.c to
ieee802_11.c since this can be used for both HE and VHT. This commit
does not change any functionality to enable the HE use case, i.e., the
function is just moved as-is.
Signed-off-by: Muna Sinada <msinada@codeaurora.org>
Operation in the 6 GHz band mandates valid HE capabilities element in
station negotiation. Reject association request upon receiving invalid
or missing HE elements.
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
This was clarified in the draft specification to not be a mandatory
requirement for the AP and STA to enforce, i.e., matching security level
is a recommendation for AP configuration rather than a protocol
requirement.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new sae_commit_status and sae_pk_omit configuration parameters and
an extra key at the end of sae_password pk argument can be used to
override SAE-PK behavior for testing purposes.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This maintains knowledge of whether H2E or PK was used as part of the
SAE authentication beyond the removal of temporary state needed during
that authentication. This makes it easier to use information about which
kind of SAE authentication was used at higher layer functionality.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This adds AP side functionality for SAE-PK. The new sae_password
configuration parameters can now be used to enable SAE-PK mode whenever
SAE is enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This adds core SAE functionality for a new mode of using SAE with a
specially constructed password that contains a fingerprint for an AP
public key and that public key being used to validate an additional
signature in SAE confirm from the AP.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add the OCV-FAILURE control interface event to notify upper layers of
OCV validation issues in FT and FILS (Re)Association Request frames.
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>
Process HE 6 GHz band capabilities in (Re)Association Request frames and
pass the information to the driver.
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Construct HE 6 GHz Band Capabilities element (IEEE 802.11ax/D6.0,
9.4.2.261) from HT and VHT capabilities and add it to Beacon, Probe
Response, and (Re)Association Response frames when operating on the 6
GHz band.
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
It is possible for drivers to report received Management frames while AP
is going through initial setup (e.g., during ACS or DFS CAC). hostapd
and the driver is not yet ready for actually sending out responses to
such frames at this point and as such, it is better to explicitly ignore
such received frames rather than try to process them and have the
response (e.g., a Probe Response frame) getting dropped by the driver as
an invalid or getting out with some incorrect information.
Signed-off-by: Jouni Malinen <j@w1.fi>
"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>
Discard the FT Reassociation Request frame instead of rejecting it
(i.e., do not send Reassociation Response frame) if RSNXE Used is
indicated in FTE, but no RSNXE is included even though the AP is
advertising RSNXE.
While there is not really much of a difference between discarding and
rejecting the frame, this discarding behavior is what the standard says
for this type of an error case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Allow STA entry to be removed and re-added to the driver with PMF is
used with FT. Previously, this case resulted in cfg80211 rejecting STA
entry update after successful FT protocol use if the association had not
been dropped and it could not be dropped for the PMF case in
handle_auth().
Signed-off-by: Jouni Malinen <j@w1.fi>
The new hostapd configuration parameter dpp_pfs can be used to specify
how PFS is applied to associations. The default behavior (dpp_pfs=0)
remains same as it was previously, i.e., allow the station to decide
whether to use PFS. PFS use can now be required (dpp_pfs=1) or rejected
(dpp_pfs=2).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
hostapd (and wpa_supplicant in AP mode) was internally updating the STA
flags on disconnection cases to remove authorization and association.
However, some cases did not result in immediate update of the driver STA
entry. Update all such cases to send out the update to the driver as
well to reduce risk of race conditions where new frames might be
accepted for TX or RX after the port authorization or association has
been lost and configured keys are removed.
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 Response frame so
that a STA not supporting RSNXE can still validate the FTE MIC
correctly.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Check whether an error is reported from any of the functions that could
in theory fail and if so, do not proceed with the partially filled SAE
commit buffer.
Signed-off-by: Jouni Malinen <j@w1.fi>
In theory, hmac_sha256() might fail, so check for that possibility
instead of continuing with undetermined index value that could point to
an arbitrary token entry.
Signed-off-by: Jouni Malinen <j@w1.fi>
send_auth_reply() could be called with sta == NULL in certain error
conditions. While that is not applicable for this special test
functionality for SAE, the inconsistent checks for the sta pointer could
result in warnings from static analyzers. Address this by explicitly
checking the sta pointer here.
Signed-off-by: Jouni Malinen <j@w1.fi>
IEEE P802.11az/D2.0 renamed the FILS Wrapped Data element,
removing the FILS prefix. Change the code accordingly.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
WEP should not be used for anything anymore. As a step towards removing
it completely, move all WEP related functionality to be within
CONFIG_WEP blocks. This will be included in builds only if CONFIG_WEP=y
is explicitly set in build configuration.
Signed-off-by: Jouni Malinen <j@w1.fi>
Hardcoded CONFIG_IEEE80211N to be included to clean up implementation.
More or less all new devices support IEEE 802.11n (HT) and there is not
much need for being able to remove that functionality from the build.
Included this unconditionally to get rid of one more build options and
to keep things simpler.
Signed-off-by: Jouni Malinen <j@w1.fi>
In the function owe_assoc_req_process(), values assigned to the reason
argument imply that it should be renamed to status. Rename 'reason' to
'status' and modify the uses of owe_assoc_req_process() accordingly.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
(Re)Association Response frames should include radio measurement
capabilities in order to let stations know if they can, e.g., use
neighbor requests.
I tested this commit with a Samsung S8, which does not send neighbor
requests without this commit and sends them afterwards.
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
The new sae_pwe=3 mode can be used to test non-compliant behavior with
SAE Password Identifiers. This can be used to force use of
hunting-and-pecking loop for PWE derivation when Password Identifier is
used. This is not allowed by the standard and as such, this
functionality is aimed at compliance testing.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Only one peer-commit-scalar value was stored for a specific STA (i.e.,
one per MAC address) and that value got replaced when the next SAE
Authentication exchange was started. This ended up breaking the check
against re-use of peer-commit-scalar from an Accepted instance when
anti-clogging token was requested. The first SAE commit message (the one
without anti-clogging token) ended up overwriting the cached
peer-commit-scalar value while leaving that instance in Accepted state.
The second SAE commit message (with anti-clogging token) added ended up
getting rejected if it used the same value again (and re-use is expected
in this particular case where the value was not used in Accepted
instance).
Fix this by using a separate pointer for storing the peer-commit-scalar
value that was used in an Accepted instance. There is no need to
allocate memory for two values, i.e., it is sufficient to maintain
separate pointers to the value and move the stored value to the special
Accepted state pointer when moving to the Accepted state.
This fixes issues where a peer STA ends up running back-to-back SAE
authentication within couple of seconds, i.e., without hostapd timing
out the STA entry for a case where anti-clogging token is required.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
IEEE P802.11-REVmd was modified to use a container IE for anti-clogging
token whenver H2E is used so that parsing of the SAE Authentication
frames can be simplified.
See this document for more details of the approved changes:
https://mentor.ieee.org/802.11/dcn/19/11-19-2154-02-000m-sae-anti-clogging-token.docx
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add the new set_key() parameter "key_flag" to provide more specific
description of what type of a key is being configured. This is needed to
be able to add support for "Extended Key ID for Individually Addressed
Frames" from IEEE Std 802.11-2016. In addition, this may be used to
replace the set_tx boolean eventually once all the driver wrappers have
moved to using the new key_flag.
The following flag are defined:
KEY_FLAG_MODIFY
Set when an already installed key must be updated.
So far the only use-case is changing RX/TX status of installed
keys. Must not be set when deleting a key.
KEY_FLAG_DEFAULT
Set when the key is also a default key. Must not be set when
deleting a key. (This is the replacement for set_tx.)
KEY_FLAG_RX
The key is valid for RX. Must not be set when deleting a key.
KEY_FLAG_TX
The key is valid for TX. Must not be set when deleting a key.
KEY_FLAG_GROUP
The key is a broadcast or group key.
KEY_FLAG_PAIRWISE
The key is a pairwise key.
KEY_FLAG_PMK
The key is a Pairwise Master Key (PMK).
Predefined and needed flag combinations so far are:
KEY_FLAG_GROUP_RX_TX
WEP key not used as default key (yet).
KEY_FLAG_GROUP_RX_TX_DEFAULT
Default WEP or WPA-NONE key.
KEY_FLAG_GROUP_RX
GTK key valid for RX only.
KEY_FLAG_GROUP_TX_DEFAULT
GTK key valid for TX only, immediately taking over TX.
KEY_FLAG_PAIRWISE_RX_TX
Pairwise key immediately becoming the active pairwise key.
KEY_FLAG_PAIRWISE_RX
Pairwise key not yet valid for TX. (Only usable with Extended Key ID
support.)
KEY_FLAG_PAIRWISE_RX_TX_MODIFY
Enable TX for a pairwise key installed with KEY_FLAG_PAIRWISE_RX.
KEY_FLAG_RX_TX
Not a valid standalone key type and can only used in combination
with other flags to mark a key for RX/TX.
This commit is not changing any functionality. It just adds the new
key_flag to all hostapd/wpa_supplicant set_key() functions without using
it, yet.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
This is in preparation for adding support to use a single WLAN netdev
with VLAN operations offloaded to the driver. No functional changes are
included in this commit.
Signed-off-by: Gurumoorthi Gnanasambandhan <gguru@codeaurora.org>
sae_confirm_immediate=2 can now be used in CONFIG_TESTING_OPTIONS=y
builds to minimize the latency between SAE Commit and SAE Confirm by
postponing transmission of SAE Commit until the SAE Confirm frame is
generated. This does not have significant impact, but can get the frames
tiny bit closer to each other over the air to increase testing coverage.
The only difference between sae_confirm_immediate 1 and 2 is in the
former deriving KCK, PMK, PMKID, and CN between transmission of the
frames (i.e., a small number of hash operations).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Merge hostapd_drv_send_mlme_csa() functionality into
hostapd_drv_send_mlme() to get a single driver ops handler function for
hostapd. In addition, add a new no_encrypt parameter in preparation for
functionality that is needed to get rid of the separate send_frame()
driver op.
Signed-off-by: Jouni Malinen <j@w1.fi>
ieee802_11_allowed_address() did not really do anything useful for the
call from handle_probe_req(), so replace that with a direct call to
hostapd_allowed_address() and make ieee802_11_allowed_address() a static
function.
Signed-off-by: Jouni Malinen <j@w1.fi>
When returning from handle_auth() after ieee802_11_allowed_address()
returned HOSTAPD_ACL_ACCEPT, but before ieee802_11_set_radius_info() has
been called, identity, radius_cui, and psk might not have been consumed.
Fix this by avoiding the need to free these variables at all.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Previously, this case was ignored silently in AP mode. While that could
be a reasonable approach for an unexpected condition, it would be fine
to reject this case explicitly as well. This makes it somewhat easier to
test unexpected SAE H2E vs. looping behavior.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
check_sae_rejected_groups() returns 1, not -1, in case an enabled group
is rejected. The previous check for < 0 could not have ever triggered.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Previously, this case was ignored silently in AP mode. While that could
be a reasonable approach for an unexpected condition, it would be fine
to reject this case explicitly as well. This makes it somewhat easier to
test unexpected SAE H2E vs. looping behavior.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Previously, nonzero sae_h2e parameter values were used to perform SAE
H2E specific operations (deriving PT, adding RSNXE, adding H2E-only BSS
membership selector) in AP mode even if SAE was not enabled for the
network. This could result in unexpected behavior if sae_pwe=1 or
sae_pwe=2 were set in the configuration. Fix this by making the SAE
operations conditional on SAE being actually enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If hostapd had existing STA SAE state, e.g., from a previously completed
SAE authentication, a new start of a separate SAE authentication (i.e.,
receiving of a new SAE commit) ended up using some of the previous
state. This is problematic for determining whether to H2E vs. looping
since the STA is allowed (even if not really expected to) to change
between these two alternatives. This could result in trying to use H2E
when STA was using looping to derive PWE and that would result in SAE
confirm failing.
Fix this by determining whether to use H2E or looping for the restarted
authentication based on the Status Code in the new SAE commit message
instead of previously cached state information.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If a STA indicates support for SAE H2E in RSNXE and H2E is enabled in
the AP configuration, require H2E to be used.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is needed to be able to compare the received RSNXE to a protected
version in EAPOL-Key msg 2/4.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>