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>
When operating on the 6 GHz band, add 6 GHz Operation Information inside
the HE Operation element and don't publish HT/VHT IEs.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
- Replace HOSTAPD_MODE_IEEE80211AX mode checks with is_6ghz_op_class()
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
If hostapd is configured to enable only the hash-to-element version of
SAE PWE derivation (sae_pwe=1), advertise BSS membership selector to
indicate this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
hostapd is by default waiting STA to send SAE Confirm before sending the
SAE Confirm. This can now be configured with sae_confirm_immediate=1
resulting in hostapd sending out SAE Confirm immediately after sending
SAE Commit.
These are the two different message sequences:
sae_confirm_immediate=0
STA->AP: SAE Commit
AP->STA: SAE Commit
STA->AP: SAE Confirm
AP->STA: SAE Confirm
STA->AP: Association Request
AP->STA: Association Response
sae_confirm_immediate=1
STA->AP: SAE Commit
AP->STA: SAE Commit
AP->STA: SAE Confirm
STA->AP: SAE Confirm
STA->AP: Association Request
AP->STA: Association Response
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use the same rules for dropping driver notifications for Data frames
from unassociated stations as were added for Management frame reception.
This results in more consistent behavior in sending out Deauthentication
frames with Reason Code 6/7.
This case was already checking for unexpected multicast addresses, so
there was no issue for the PMF protections for unexpected disconnection.
Anyway, better avoid unnecessary Deauthentication frames consistently.
Signed-off-by: Jouni Malinen <j@w1.fi>
Do not process any received Management frames with unexpected/invalid SA
so that we do not add any state for unexpected STA addresses or end up
sending out frames to unexpected destination. This prevents unexpected
sequences where an unprotected frame might end up causing the AP to send
out a response to another device and that other device processing the
unexpected response.
In particular, this prevents some potential denial of service cases
where the unexpected response frame from the AP might result in a
connected station dropping its association.
Signed-off-by: Jouni Malinen <j@w1.fi>
Hardcode this to be defined and remove the separate build options for
PMF since this functionality is needed with large number of newer
protocol extensions and is also something that should be enabled in all
WPA2/WPA3 networks.
Signed-off-by: Jouni Malinen <j@w1.fi>
Even though the station is not supposed to include Hotspot 2.0
Indication element in the Association Request frame when connecting to
the open OSU BSS, some station devices seem to do so. With the strict
PMF-required-with-Hotspot-2.0-R2 interpretation, such connection
attempts were rejected. Relax this to only perform the PMF check if the
local AP configuration has PMF enabled, i.e., for the production BSS.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The HE capabilities are no longer per PHY but per iftype on this
specific PHY. It is therefore no longer enough to just parse the AP
capabilities.
The he_capabilities are now duplicated to store all information for
IEEE80211_MODE_* which hostap cares about. The nl80211 driver fills in
this information when the iftype supports HE. The rest of the code still
only uses the IEEE80211_HE_AP portion but can be extended later to also
use other HE capabilities.
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
This implements the required functionality in hostapd to facilitate OWE
connection with the AP SME-in-driver cases. Stations can either send DH
IE or PMKID (in RSNE) (or both) in Association Request frame during the
OWE handshake. The drivers that use this offload mechanism do not
interpret this information and instead, pass the same to hostapd for
further processing. hostapd will either validate the PMKID obtained from
the STA or generate DH IE and further indicate the same to the driver.
The driver further sends this information in the Association Response
frame.
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>
Signed-off-by: Liangwei Dong <liangwei@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
External auth status to the driver includes the PMKID derived as part of
SAE authentication, but this is not valid if PMKSA caching is disabled.
Drivers might not be expecting PMKID when it is not valid. Do not send
the PMKID to the driver in such cases.
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>
When a new station is added, let it have some supported rates
(they're empty without this change), using the basic rates
that it must support to connect.
This, together with the kernel-side changes for client-side,
lets us finish the complete auth/assoc handshake with higher
rates than the mandatory ones, without any further config.
However, the downside to this is that a broken station that
doesn't check the basic rates are supported before it tries
to connect will possibly not get any response to its auth
frame.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Process HE information in (Re)Association Request frames and add HE
elements into (Re)Association Response frames when HE is enabled in the
BSS.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
This copying attempt was added incorrectly since that element is never
actually present in (Re)Association Request frames. It is only valid to
copy that element from the mesh peering frames.
Signed-off-by: Jouni Malinen <j@w1.fi>
This AP behavior was missing from IEEE Std 802.11ai-2016, but it is
needed for the RSNE validation to work correctly and for a FILS STA to
be able to perform the mandatory check for RSNE matching when processing
the (Re)Association Response frame (as described in 802.11ai). REVmd
will be updating the standard to cover this AP case, so prepare the
implementation to match that. Without this, a FILS STA might reject
association whenever using FILS authentication.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Logs involving IEEE 802.11 Status Codes output the Status Code value,
but do not provide any explanation of what the value means. This change
provides a terse explanation of each status code using the latter part
of the Status Code #define names.
Signed-off-by: Alex Khouderchah <akhouderchah@chromium.org>
The PMK and PMKID information from FILS ERP and FILS PMKSA caching needs
to be stored within struct wpa_state_machine for PTK to work. Without
this, PTK derivation would fail and attempt to go through rekeying would
result in disconnection. Furthermore, wpa_rekey_ptk() timer needs to be
started at the completion of FILS association since the place where it
was done for non-FILS cases at the end of 4-way handshake is not reached
when FILS authentication is used.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
It is possible for the SAE state machine to remove the STA and free the
sta pointer in the mesh use cases. handle_auth_sae() could have
dereferenced that pointer and used freed memory in some cases. Fix that
by explicitly checking whether the STA was removed.
Fixes: bb598c3bdd ("AP: Add support for full station state")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
ap_free_sta() frees the sta entry, so sta->addr cannot be used after
that call. Fix the sequence of these two calls to avoid use of freed
memory to determine which PMKSA cache entry to remove.
Fixes: 9f2cf23e2e ("mesh: Add support for PMKSA caching")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The external authentication command and event does not need to copy the
BSSID/SSID values into struct external_auth since those values are used
before returning from the call. Simplify this by using const u8 * to
external data instead of the array with a copy of the external data.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Extend commit 5ff39c1380 ("SAE: Support external authentication
offload for driver-SME cases") to support external authentication
with drivers that implement AP SME by notifying the status of
SAE authentication to the driver after SAE handshake as the
driver acts as a pass through for the SAE Authentication frames.
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>
This code was after the FILS handling that would have encrypted the
frame. While FILS and OWE are never used together, the OWE handling
should really be before the FILS handling since no IEs can be added
after the FILS encryption step. In addition, the Diffie-Hellman
Parameter element is not a Vendor Specific element, so it should be
before some of the Vendor Specific elements even though it is not
defined in IEEE 802.11.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use Diffie-Hellman key exchange to derivate additional material for
PMK-to-PTK derivation to get PFS. The Diffie-Hellman Parameter element
(defined in OWE RFC 8110) is used in association frames to exchange the
DH public keys. For backwards compatibility, ignore missing
request/response DH parameter and fall back to no PFS in such cases.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The queue_len * 50 ms wait time was too large with the retransmission
timeouts used in the mesh case for SAE. The maximum wait of 750 ms was
enough to prevent successful completion of authentication after having
hit the maximum queue length. While the previous commit is enough to
allow this to complete successfully in couple of retries, it looks like
a smaller wait time should be used here even if it means potentially
using more CPU.
Drop the processing wait time to queue_len * 10 ms so that the maximum
wait time is 150 ms if the queue is full.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous design of simply queuing all SAE commit messages was not
exactly good at allowing recovery from a flooding state if the valid
peer used frequent retransmissions of the SAE message. This could
happen, e.g., with mesh BSSs using SAE. The frequent retransmissions and
restarts of SAE authentication combined with SAE confirm messages
bypassing the queue ended up in not being able to finish SAE exchange
successfully.
Fix this by modifying the queuing policy to queue SAE confirm messages
if there is a queued SAE commit message from the same peer so that the
messages within the same exchange do not get reordered. In addition,
replace queued SAE commit/confirm message if a new matching message is
received from the same peer STA. This is useful for the case where the
peer restarts SAE more quickly than the local end has time to process
the queued messages.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Derive PMKR1Name during the FILS authentication step, verify that the
station uses matching PMKR1Name in (Re)Association Request frame, and
add RSNE[PMKR1Name] into (Re)Association Response frame when going
through FT initial mobility domain association using FILS. These steps
were missed from the initial implementation, but are needed to match the
IEEE 802.11ai requirements for explicit confirmation of the FT key
hierarchy (similarly to what is done in FT 4-way handshake when FILS is
not used).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This gets rid of a confusing error message "FILS: Failed to add PMKSA
cache entry based on ERP" for cases where PMKSA caching is disabled in
hostapd (disable_pmksa_caching=1). Functionality remains unchanged,
i.e., no cache entry was added before this change either.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Copy the Finite Cyclic Group field value from the request to the
response Authentication frame if we end up rejecting the request due to
unsupported group.
IEEE Std 802.11-2016 has conflicting statements about this behavior.
Table 9-36 (Presence of fields and elements in Authentication frames)
indicates that the Finite Cyclic Group field is only included with
status code values 0 (success) and 76 (anti-clogging token request)
while SAE protocol description implying that the Finite Cyclic Group
field is set to the rejected group (12.4.8.6.3 and 12.4.8.6.4).
The standard language needs to cleaned up to describe this
unambiguously, but since it looks safe to add the field into the
rejection case and since there is desire to have the field present to be
able to implement what exactly is stated in 12.4.8.6.4, it looks
reasonable to move ahead with the AP mode implementation change. There
is no change in wpa_supplicant for now to modify its behavior based on
whether this field is present, i.e., wpa_supplicant will continue to
work with both the old and new hostapd behavior for SAE group
negotiation.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Do not start SAE authentication from scratch if a STA starts a new
attempt for the same group while we still have previously generated PWE
available. Instead, use the previously generated PWE as-is and skip
anti-clogging token exchange since the heavy processing is already
completed. This saves unnecessary processing on the AP side in case the
STA failed to complete authentication on the first attempt (e.g., due to
heavy SAE load on the AP causing a timeout) and makes it more likely for
a valid STA to be able to complete SAE authentication during a DoS
attack.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add a 16-bit token index into the anti-clogging token. This can be used
to enforce only a single use of each issued anti-clogging token request.
The token value is now token-index |
last-30-octets-of(HMAC-SHA256(sae_token_key, STA-MAC-address |
token-index)), i.e., the first two octets of the SHA256 hash value are
replaced with the token-index and token-index itself is protected as
part of the HMAC context data.
Track the used 16-bit token index values and accept received tokens only
if they use an index value that has been requested, but has not yet been
used. This makes it a bit more difficult for an attacker to perform DoS
attacks against the heavy CPU operations needed for processing SAE
commit since the attacker cannot simply replay the same frame multiple
times and instead, needs to request each token separately.
While this does not add significant extra processing/CPU need for the
attacker, this can be helpful in combination with the queued processing
of SAE commit messages in enforcing more delay during flooding of SAE
commit messages since the new anti-clogging token values are not
returned before the new message goes through the processing queue.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This allows better control of processing new SAE sessions so that other
operations can be given higher priority during bursts of SAE requests,
e.g., during a potential DoS attack. The receive commit messages are
queued (up to maximum of 15 entries) and processed from eloop callback.
If the queue has multiple pending entries, more wait time is used to go
through the each new entry to reduce heavy CPU load from SAE processing.
Enable anti-clogging token use also based on the pending commit message
queue and not only based on the already started sessions.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Change the AP mode default for SAE to enable only the group 19 instead
of enabling all ECC groups that are supported by the used crypto library
and the SAE implementations. The main reason for this is to avoid
enabling groups that are not as strong as the mandatory-to-support group
19 (i.e., groups 25 and 26). In addition, this disables heavier groups
by default.
In addition, add a warning about MODP groups 1, 2, 5, 22, 23, and 24
based on "MUST NOT" or "SHOULD NOT" categorization in RFC 8247. All the
MODP groups were already disabled by default and would have needed
explicit configuration to be allowed.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
According to IEEE Std 802.11-2016, 9.4.2.25 when fields of an RSNE are
not included, the default values are used. The cipher suite defaults
were hardcoded to CCMP in the previous implementation, but the default
is actually different for DMG: GCMP (per 9.4.2.25.2).
It is not possible to find out from the RSNE if the network is non-DMG
or DMG, so callers of wpa_parse_wpa_ie_rsn() need to handle this case
based on context, which can be different for each caller.
In order to fix this issue, add flags to the wpa_ie_data indicating
whether pairwise/group ciphers were included in the RSNE. Callers can
check these flags and fill in the appropriate ciphers. The
wpa_parse_wpa_ie_rsn() function still initializes the ciphers to CCMP by
default so existing callers will not break. This change also fixes some
callers which need to handle the DMG network case.
Signed-off-by: Lior David <liord@codeaurora.org>
The Multi-AP specification only specifies that information elements have
to be added to the Association Request and Association Response frame;
it doesn't specify anything about what should be done in case they are
missing. Previously, we rejected non-backhaul associations on a
backhaul-only BSS, and non-fronthaul associations on a fronthaul-only
BSS.
However, this makes WPS fail when fronthaul and backhaul are separate
SSIDs. Indeed, WPS for the backhaul link is performed on the *fronthaul*
SSID. Thus, the Association Request frmae used for WPS *will* contain
the Multi-AP IE indicating a backhaul STA. Rejecting that association
makes WPS fail.
Therefore, accept a multi-AP backhaul STA Association Request frame on a
fronthaul-only BSS. Still issue a warning about it, but only at level
DEBUG intead of INFO. Also change the condition checking to make it
clearer.
While we're at it, also fix the handling of unexpected bits in the
Multi-AP IE. 4 bits are reserved in the specification, so these
certainly have to be ignored. The specification also doesn't say that
setting one of the other bits is not allowed. Therefore, only report
unexpected values in the Multi-AP IE, don't reject because of it. Note
that a malformed IE (containing more than one byte) still triggers a
rejection.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The new sae_password parameter [|vlanid=<VLAN ID>] can now be used to
assign stations to a specific VLAN based on which SAE Password
Identifier they use. This is similar to the WPA2-Enterprise case where
the RADIUS server can assign stations to different VLANs and the
WPA2-Personal case where vlanid parameter in wpa_psk_file is used.
Signed-off-by: Jouni Malinen <j@w1.fi>
FT-over-the-DS has a special case where the STA entry (and as such, the
TK) has not yet been configured to the driver depending on which driver
interface is used. For that case, allow add-STA operation to be used
(instead of set-STA). This is needed to allow mac80211-based drivers to
accept the STA parameter configuration. Since this is after a new
FT-over-DS exchange, a new TK has been derived after the last STA entry
was added to the driver, so key reinstallation is not a concern for this
case.
Fixes: 0e3bd7ac68 ("hostapd: Avoid key reinstallation in FT handshake")
Signed-off-by: Jouni Malinen <j@w1.fi>
Try to make RSSI-based rejection of associating stations a bit less
likely to trigger false rejections by considering RSSI from the last
received Authentication frame. Association is rejected only if both the
Authentication and (Re)Association Request frames are below the RSSI
threshold.
Signed-off-by: Jouni Malinen <j@w1.fi>
An AP might reject a STA association request due to low RSSI. In such
case, the AP informs the STA the desired RSSI improvement and a retry
timeout. The STA might retry to associate even if the RSSI hasn't
improved if the retry timeout expired.
Signed-off-by: Beni Lev <beni.lev@intel.com>
The purpose of Multi-AP specification is to enable inter-operability
across Wi-Fi access points (APs) from different vendors.
This patch introduces one new configuration parameter 'multi_ap' to
enable Multi-AP functionality and to configure the BSS as a backhaul
and/or fronthaul BSS.
Advertise vendor specific Multi-AP capabilities in (Re)Association
Response frame, if Multi-AP functionality is enabled through the
configuration parameter.
A backhaul AP must support receiving both 3addr and 4addr frames from a
backhaul STA, so create a VLAN for it just like is done for WDS, i.e.,
by calling hostapd_set_wds_sta(). Since Multi-AP requires WPA2 (never
WEP), we can safely call hostapd_set_wds_encryption() as well and we can
reuse the entire WDS condition.
To parse the Multi-AP Extension subelement, we use get_ie(): even though
that function is meant for parsing IEs, it works for subelements.
Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Include an OCI element in SA Query Request and Response frames if OCV
has been negotiated.
On Linux, a kernel patch is needed to let clients correctly handle SA
Query Requests that contain an OCI element. Without this patch, the
kernel will reply to the SA Query Request itself, without verifying the
included OCI. Additionally, the SA Query Response sent by the kernel
will not include an OCI element. The correct operation of the AP does
not require a kernel patch.
Without the corresponding kernel patch, SA Query Requests sent by the
client are still valid, meaning they do include an OCI element.
Note that an AP does not require any kernel patches. In other words, SA
Query frames sent and received by the AP are properly handled, even
without a kernel patch.
As a result, the kernel patch is only required to make the client properly
process and respond to a SA Query Request from the AP. Without this
patch, the client will send a SA Query Response without an OCI element,
causing the AP to silently ignore the response and eventually disconnect
the client from the network if OCV has been negotiated to be used.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
APs and mesh peers use the VHT Operation element to advertise certain
channel properties (e.g., the bandwidth of the channel). Save this
information element so we can later access this information.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
It is better not to process a new (most likely repeated) FILS HLP
request if a station retransmits (Re)Association Request frame before
the previous HLP response has either been received or timed out. The
previous implementation ended up doing this and also ended up
rescheduling the fils_hlp_timeout timer in a manner that prevented the
initial timeout from being reached if the STA continued retransmitting
the frame. This could result in failed association due to a timeout on
the station side.
Make this more robust by processing (and relaying to the server) the HLP
request once and then ignoring any new HLP request while the response
for the relayed request is still pending. The new (Re)Association
Request frames are otherwise processed, but they do not result in actual
state change on the AP side before the HLP process from the first
pending request is completed.
This fixes hwsim test case fils_sk_hlp_oom failures with unmodified
mac80211 implementation (i.e., with a relatively short retransmission
timeout for (Re)Association Request frame).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If association failed for any non-OWE specific reason, the previous
implementation tried to add the OWE related IEs into the (Re)Association
Response frame. This is not needed and could actually result in
dereferencing a NULL pointer. Fix this by adding those OWE related IEs
only for successful association and only if the RSN state machine has
been initialized.
Signed-off-by: Jouni Malinen <j@w1.fi>
Both handle_action() and hostapd_action_rx() are used for processing
received Action frames depending on what type of driver architecture is
used (MLME in hostapd vs. driver) and which build options were used to
build hostapd. These functions had a bit different sequence for checking
the frame and printing debug prints. Make those more consistent by
checking that the frame includes the category-specific action field and
some payload. Add a debug print for both functions to make it easier to
see which path various Action frames use.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previous implementation ended up triggering PMF check for previous
association and SA Query procedure incorrectly in cases where there is a
STA entry in hostapd, but that STA is not in associated state. This
resulted in undesired temporary rejection of the association with status
code 30.
This ended up breaking OWE group negotiation when PMF is in use since
the check for the OWE group would have happened only after this earlier
PMF check and rejection (i.e., the station got status code 30 instead of
the expected 77).
For example, when the AP is configured with OWE group 21 and a station
tries groups 19, 20, and 21 (in this sequence), the first two
Association Request frames should be rejected with status code 77.
However, only the first one got that status code while the second one
got status code 30 due to that issue with PMF existing association
check.
Furthermore, hostapd was continuing with SA Query procedure with
unencrypted Action frames in this type of case even though there was no
existing association (and obviously, not an encryption key either).
Fix this by checking that the STA entry is in associated state before
initiating SA Query procedure based on the PMF rules.
Signed-off-by: Ashok Kumar <aponnaia@codeaurora.org>
This message was printed and MSG_INFO level which would be more
reasonable for error cases where hostapd has accepted authentication.
However, this is not really an error case for the cases where
authentication was rejected (e.g., due to MAC ACL). Drop this to use
MSG_DEBUG level.
Signed-off-by: Jouni Malinen <j@w1.fi>
When Probe Request frame handling was extended to use MAC ACL through
ieee802_11_allowed_address(), the MSG_INFO level log print ("Station
<addr> not allowed to authenticate") from that function ended up getting
printed even for Probe Request frames. That was not by design and it can
result in excessive logging and MSG_INFO level if MAC ACL is used.
Fix this by printing this log entry only for authentication and
association frames. In addition, drop the priority of that log entry to
MSG_DEBUG since this is not really an unexpected behavior in most MAC
ACL use cases.
Fixes: 92eb00aec2 ("Extend ACL check for Probe Request frames")
Signed-off-by: Jouni Malinen <j@w1.fi>
If you modify the WLAN-STA-AUTHORIZED bit in sta->flags, you have to
call the ap_sta_set_authorized() function to make sure the corresponding
event is sent over the control interface. Otherwise we leak entries in
the event history.
Signed-off-by: Andreas Tobler <andreas.tobler@cloudguard.ch>
In the infrastructure BSS case, the AP needs to clear pending SAE state
if a new Commit message is received when already in Committed state.
This allows the non-AP STA to negotiate a new group if it ends up trying
to go through SAE authentication again before the AP side has removed
the previous STA entry.
This fixes an issue where a kernel update changed something in SAE
timing or authentication sequence and started failing the
sae_bignum_failure hwsim test case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
A new SAE Commit message should not be allowed to drop an existing STA
entry since the sender of that Commit message cannot be authenticated
before receiving the Confirm message. This is important in particular
when PMF is used since this would provide a potential new path for
forcing a connection to be dropped.
Fix this by allowing a new SAE Authentication instance to be started
when the old instance is in Accepted state and the new Commit message
does not use the same peer-scalar value (checked in
sae_parse_commit_scalar()). When PMF is used, the AP will use SA Query
procedure when receiving the (Re)Association Request frame. In theory,
that step could be skipped in case of SAE Authentication since the
non-AP STA is demonstrating knowledge of the password. Anyway, there is
no allowance for that exception in the IEEE 802.11 standard, so at least
for now, leave this using SA Query procedure just like any other PMF
case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Instead of sending out a partially completed frame, abort the
association process if something unexpected happens and remove the STA
entry.
Signed-off-by: Jouni Malinen <j@w1.fi>
The MIC field is now a variable length field, so make FTE generation in
hostapd aware of the two different field lengths.
Signed-off-by: Jouni Malinen <j@w1.fi>
This extends the SAE implementation in both infrastructure and mesh BSS
cases to allow an optional Password Identifier to be used. This uses the
mechanism added in P802.11REVmd/D1.0. The Password Identifier is
configured in a wpa_supplicant network profile as a new string parameter
sae_password_id. In hostapd configuration, the existing sae_password
parameter has been extended to allow the password identifier (and also a
peer MAC address) to be set. In addition, multiple sae_password entries
can now be provided to hostapd to allow multiple per-peer and
per-identifier passwords to be set.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This extends hostapd processing of (Re)Association Request frames to
store a local copy of the Consortium OI within the Roaming Consortium
Selection element, if present, and then add that in HS 2.0 Roaming
Consortium attribute into RADIUS Access-Request messages.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is needed to allow the remaining session time to be computed for FT
(when sending PMK-R1 to another AP).
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
ieee802_11_set_radius_info() might be called with a STA entry that has
already stored identity and/or radius_cui information, so make sure the
old values get freed before being replaced by the new ones.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Previously, the association that used SAE authentication ended up
recalculating the PMKID for EAPOL-Key msg 1/4 using incorrect
PMK-to-PMKID derivation instead of using the previously derived PMKID
from SAE. The correct PMKID was used only when going through PMKSA
caching exchange with a previously derived PMKSA from SAE.
Fix this by storing the SAE PMKID into the state machine entry for the
initial SAE authentication case when there is no explicit PMKSA entry
attached to the station.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This makes it easier to understand what kind of information a STA is
reporting about 20/40 MHz coexistence requirements.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Check wpa_auth_write_assoc_resp_owe() return value to keep static
analyzers happier. The code path where this could happen is not really
reachable due to the separate hapd->conf->own_ie_override check and
wpa_auth_write_assoc_resp_owe() returning NULL only in an error case in
the override path. Furthermore, clean up the pointer return value to use
a proper pointer (NULL vs. 0).
Signed-off-by: Ashok Ponnaiah <aponnaia@codeaurora.org>
Extend ACL check to deny Probe Request frames for the client which does
not pass ACL check. Skip this check for the case where RADIUS ACL is
used to avoid excessive load on the RADIUS authentication server due to
Probe Request frames. This patch add wpa_msg event for auth and assoc
rejection due to acl reject.
Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org>
Check for the fi parameter to be non-NULL before trying to fetch the
ssi_signal information similarly to how the fi->freq was already
handled. While the meta information is supposed to be available, it
looks like there is at least one corner case where fi == NULL could be
used (Authentication frame reprocessing after RADIUS-based ACL).
Signed-off-by: Jouni Malinen <j@w1.fi>
This function is used to process a (Re)Association Request frame, so
rename it appropriately to mention assoc_req instead of auth_req.
Signed-off-by: Ashok Ponnaiah <aponnaia@codeaurora.org>
Verify that the STA has ECDH data available before trying to use this
data to add the OWE DH Params element.
Signed-off-by: Ashok Ponnaiah <aponnaia@codeaurora.org>
This was already the case with the hostapd-based SME/MLME
implementation, but the OWE DH Param element construction for the
driver-based SME/MLME needed a matching change to set the group
properly.
Signed-off-by: Ashok Ponnaiah <aponnaia@codeaurora.org>
If a matching PMKSA cache entry is present for an OWE client, use it and
do not go through DH while processing Association Rquest frame.
Association Response frame will identify the PMKID in such a case and DH
parameters won't be present.
Signed-off-by: Ashok Ponnaiah <aponnaia@codeaurora.org>
Use "cipher out of policy" value instead of invalid group cipher (which
is for the group data frame cipher) and management frame policy
violation (which is used for MFPC/MFPR mismatch).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Not all code paths for management frame RX reporting delivered the
correct frequency for offchannel RX cases. This is needed mainly for
Public Action frame processing in some special cases where AP is
operating, but an exchange is done on a non-operational channel. For
example, DPP Initiator role may need to do this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Set Sc to 2^16-1 when moving to Accepted state per IEEE Std 802.11-2016,
12.4.8.6.5 (Protocol instance behavior - Confirmed state). This allows
the peer in Accepted state to silently ignore unnecessary
retransmissions of the Confirm message.
Signed-off-by: Jouni Malinen <j@w1.fi>
This implements the behavior described in IEEE Std 802.11-2016,
12.4.8.6.6 (Protocol instance behavior - Accepted state) to silently
discard received Confirm message in the Accepted state if the new
message does not use an incremented send-confirm value or if the special
2^16-1 value is used. This avoids unnecessary processing of
retransmitted Confirm messages.
Signed-off-by: Jouni Malinen <j@w1.fi>
The new hostapd.conf parameter sae_sync (default: 5) can now be used to
configure the dot11RSNASAESync value to specify the maximum number of
synchronization errors that are allowed to happen prior to
disassociation of the offending SAE peer.
Signed-off-by: Jouni Malinen <j@w1.fi>
If fils_decrypt_assoc() were to fail on the AP side, the previous
implementation could have continued through the response generation
using left = -1. That could have resulted in unexpected processing if
this value were to be used as the length of the remaining (unencrypted)
IEs. Fix this by not updating left in the failure case.
Fixes: 78815f3dde ("FILS: Decrypt Association Request elements and check Key-Auth (AP)")
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The previously used WLAN_REASON_MICHAEL_MIC_FAILURE (14) value as a
response to Authentication frame or (Re)Association Request frame is not
correct since the resp value is encoded in the Status Code (not Reason
Code) field. Status Code 14 is WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION
which is really what this value would have meant in the response frames.
There is no Michael MIC failure status code, so have to use the generic
"Unspecified failure" (1) reason code for these cases.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
