Set the SAE-PK capability bit in RSNXE when sending out (Re)Association
Request frame for a network profile that allows use of SAE-PK.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
wpa_supplicant disables PMKSA caching with FT-EAP by default due to
known interoperability issues with APs. This is allowed only if the
network profile is explicitly enabling caching with
ft_eap_pmksa_caching=1. However, the PMKID for such PMKSA cache entries
was still being configured to the driver and it was possible for the
driver to build an RSNE with the PMKID for SME-in-driver cases. This
could result in hitting the interop issue with some APs.
Fix this by skipping PMKID configuration to the driver fot FT-EAP AKM if
ft_eap_pmksa_caching=1 is not used in the network profile so that the
driver and wpa_supplicant behavior are in sync for this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
To support the STA testbed role, the STA has to use specified channel
information in OCI element sent to the AP in EAPOL-Key msg 2/4, SA Query
Request, and SA Query Response frames. Add override parameters to use
the specified channel while populating OCI element in all these frames.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Allow wpa_supplicant to be requested to override the RSNXE Used subfield
in FT reassociation case for testing purposes with "SET ft_rsnxe_used
<0/1/2>" where 0 = no override, 1 = override to 1, and 2 = override to
0.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Drivers that trigger roaming need to know the lifetime and reauth
threshold time of configured PMKSA so that they can trigger full
authentication to avoid unnecessary disconnection. To support this, send
dot11RSNAConfigPMKLifetime and dot11RSNAConfigPMKReauthThreshold values
configured in wpa_supplicant to the driver while configuring a PMKSA.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Check whether the Transition Disable KDE is received from an
authenticated AP and if so, whether it contains valid indication for
disabling a transition mode. If that is the case, update the local
network profile by removing the less secure options.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Support Extended Key ID in wpa_supplicant according to
IEEE Std 802.11-2016 for infrastructure (AP) associations.
Extended Key ID allows to rekey pairwise keys without the otherwise
unavoidable MPDU losses on a busy link. The standard is fully backward
compatible, allowing STAs to also connect to APs not supporting it.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
Rekeying a pairwise key using only keyid 0 (PTK0 rekey) has many broken
implementations and should be avoided when using or interacting with
one. The effects can be triggered by either end of the connection and
range from hardly noticeable disconnects over long connection freezes up
to leaking clear text MPDUs.
To allow affected users to mitigate the issues, add a new configuration
option "wpa_deny_ptk0_rekey" to replace all PTK0 rekeys with fast
reconnects.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
Add a new wpa_supplicant network profile configuration parameter
beacon_prot=<0/1> to allow Beacon protection to be enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Initial OWE implementation used SHA256 when deriving the PTK for all OWE
groups. This was supposed to change to SHA384 for group 20 and SHA512
for group 21. The new owe_ptk_workaround=1 network parameter can be used
to enable older behavior mainly for testing purposes. There is no impact
to group 19 behavior, but if enabled, this will make group 20 and 21
cases use SHA256-based PTK derivation which will not work with the
updated OWE implementation on the AP side.
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>
Add the new RSNXE into (Re)Association Request frames and EAPOL-Key msg
2/4 when using SAE with hash-to-element mechanism enabled. This allows
the AP to verify that there was no downgrade attack when both PWE
derivation mechanisms are enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If the AP advertises RSN Extension element, it has to be advertised
consistently in the unprotected (Beacon and Probe Response) and
protected (EAPOL-Key msg 3/4) frames. Verify that this is the case.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
These cases are for the IEEE 802.11 Status Code and Reason Code and
those fields are unsigned 16 bit values, so use the more appropriate
type consistently. This is mainly to document the uses and to make the
source code easier to understand.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no PMK/PMKID when going through 4-way handshake during an
association started with FT protocol, so need to allow the operation to
proceed even if there is no selected PMKSA cache entry in place.
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>
This adds the necessary functions and callbacks to make the channel_info
driver API available to the supplicant state machine that implements the
4-way and group key handshake. This is needed for OCV.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
This was originally added to allow the IEEE 802.11 protocol to be
tested, but there are no known fully functional implementations based on
this nor any known deployments of PeerKey functionality. Furthermore,
PeerKey design in the IEEE Std 802.11-2016 standard has already been
marked as obsolete for DLS and it is being considered for complete
removal in REVmd.
This implementation did not really work, so it could not have been used
in practice. For example, key configuration was using incorrect
algorithm values (WPA_CIPHER_* instead of WPA_ALG_*) which resulted in
mapping to an invalid WPA_ALG_* value for the actual driver operation.
As such, the derived key could not have been successfully set for the
link.
Since there are bugs in this implementation and there does not seem to
be any future for the PeerKey design with DLS (TDLS being the future for
DLS), the best approach is to simply delete all this code to simplify
the EAPOL-Key handling design and to get rid of any potential issues if
these code paths were accidentially reachable.
Signed-off-by: Jouni Malinen <j@w1.fi>
The driver is expected to not report a second association event without
the station having explicitly request a new association. As such, this
case should not be reachable. However, since reconfiguring the same
pairwise or group keys to the driver could result in nonce reuse issues,
be extra careful here and do an additional state check to avoid this
even if the local driver ends up somehow accepting an unexpected
Reassociation Response frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
Properly track whether a PTK has already been installed to the driver
and the TK part cleared from memory. This prevents an attacker from
trying to trick the client into installing an all-zero TK.
This fixes the earlier fix in commit
ad00d64e7d ('Fix TK configuration to the
driver in EAPOL-Key 3/4 retry case') which did not take into account
possibility of an extra message 1/4 showing up between retries of
message 3/4.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
This extends the protection to track last configured GTK/IGTK value
separately from EAPOL-Key frames and WNM-Sleep Mode frames to cover a
corner case where these two different mechanisms may get used when the
GTK/IGTK has changed and tracking a single value is not sufficient to
detect a possible key reconfiguration.
Signed-off-by: Jouni Malinen <j@w1.fi>
Track the current GTK and IGTK that is in use and when receiving a
(possibly retransmitted) Group Message 1 or WNM-Sleep Mode Response, do
not install the given key if it is already in use. This prevents an
attacker from trying to trick the client into resetting or lowering the
sequence counter associated to the group key.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
This extends OWE support in wpa_supplicant to allow DH groups 20 and 21
to be used in addition to the mandatory group 19 (NIST P-256). The group
is configured using the new network profile parameter owe_group.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Derive PMK-R0 and the relevant key names when using FILS authentication
for initial FT mobility domain association. Fill in the FT IEs in
(Re)Association Request frame for this.
Signed-off-by: Jouni Malinen <j@w1.fi>
Add support for setting and deleting PMKSA cache entries based on FILS Cache
Identifer. Also additionally add support for sending PMK as part of
SET_PMKSA to enable driver to derive keys in case of FILS shared key
offload using PMKSA caching.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds an option to configure wpa_supplicant to use the perfect
forward secrecy option in FILS shared key authentication. A new build
option CONFIG_FILS_SK_PFS=y can be used to include this functionality. A
new runtime network profile parameter fils_dh_group is used to enable
this by specifying which DH group to use. For example, fils_dh_group=19
would use FILS SK PFS with a 256-bit random ECP group.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds STA side addition of OWE Diffie-Hellman Parameter element into
(Re)Association Request frame and processing it in (Re)Association
Response frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows PMKSA cache entries for FILS-enabled BSSs to be shared
within an ESS when the BSSs advertise the same FILS Cache Identifier
value.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new FILS-HLP-RX control interface event is now used to report
received FILS HLP responses from (Re)Association Response frame as a
response to the HLP requests configured with FILS_HLP_REQ_ADD.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds helper functions for deriving PMK and PMKID from ERP exchange
in FILS shared key authentication as defined in IEEE Std 802.11ai-2016,
12.12.2.5.2 (PMKSA key derivation with FILS authentication). These
functions is used to fix PMK and PMKID derivation which were previously
using the rMSK directly as PMK instead of following the FILS protocol to
derive PMK with HMAC from nonces and rMSK.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
These allow external program to monitor PMKSA cache updates in
preparation to enable external persistent storage of PMKSA cache.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Decrypt the AES-SIV protected elements and verify Key-Auth. Parse and
configure keys to the driver.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If a PMKSA cache entry for the target AP is available, try to use FILS
with PMKSA caching.
If an ERP key for the target AP is available, try to use FILS with
EAP-Initiate/Re-auth added as Wrapper Data element.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This will be needed to be able to implement AEAD cipher support from
FILS that will need to use KEK to protect the frame.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new wpa_supplicant control interface command "TEST_ASSOC_IE
<hexdump>" can now be used to override the WPA/RSN IE for Association
Request frame and following 4-way handshake to allow protocol testing of
AP side processing of WPA/RSN IE.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_sm_key_mgmt_set_pmk() was checking for proactive_key_caching to be
enabled before setting the PMK to the driver. This check is not required
and would mandate configuration setting of okc or proactive_key_caching
for cases which were not necessary.
Signed-off-by: Amarnath Hullur Subramanyam <amarnath@qca.qualcomm.com>
Some APs may send RSC octets in EAPOL-Key message 3 of 4-Way Handshake
or in EAPOL-Key message 1 of Group Key Handshake in the opposite byte
order (or by some other corrupted way). Thus, after a successful
EAPOL-Key exchange the TSC values of received multicast packets, such as
DHCP, don't match the RSC one and as a result these packets are dropped
on replay attack TSC verification. An example of such AP is Sapido
RB-1732.
Work around this by setting RSC octets to 0 on GTK installation if the
AP RSC value is identified as a potentially having the byte order issue.
This may open a short window during which older (but valid)
group-addressed frames could be replayed. However, the local receive
counter will be updated on the first received group-addressed frame and
the workaround is enabled only if the common invalid cases are detected,
so this workaround is acceptable as not decreasing security
significantly. The wpa_rsc_relaxation global configuration property
allows the GTK RSC workaround to be disabled if it's not needed.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Provide information on whether EAPOL-Key frame was sent successfully to
kernel for transmittion. wpa_eapol_key_send() will return
>= 0 on success and < 0 on failure. After receiving EAPOL-Key msg 3/4,
wpa_supplicant sends EAPOL-Key msg 4/4 and shows CTRL-EVENT-CONNECTED
only after verifying that the msg 4/4 was sent to kernel for
transmission successfully.
Signed-off-by: Avichal Agarwal <avichal.a@samsung.com>
Signed-off-by: Kyeong-Chae Lim <kcya.lim@samsung.com>
In addition to the PTK length increasing, the length of the PMK was
increased (from 256 to 384 bits) for the 00-0f-ac:12 AKM. This part was
missing from the initial implementation and a fixed length (256-bit) PMK
was used for all AKMs.
Fix this by adding more complete support for variable length PMK and use
384 bits from MSK instead of 256 bits when using this AKM. This is not
backwards compatible with the earlier implementations.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 7d711541dc ('Clear TK part of PTK
after driver key configuration') started clearing TK from memory
immediately after having configured it to the driver when processing
EAPOL-Key message 3/4. While this covered the most common case, it did
not take into account the possibility of the authenticator having to
retry EAPOL-Key message 3/4 in case the first EAPOL-Key message 4/4
response is lost. That case ended up trying to reinstall the same TK to
the driver, but the key was not available anymore.
Fix the EAPOL-Key message 3/4 retry case by configuring TK to the driver
only once. There was no need to try to set the same key after each
EAPOL-Key message 3/4 since TK could not change. If actual PTK rekeying
is used, the new TK will be configured once when processing the new
EAPOL-Key message 3/4 for the first time.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, it would have been possible to complete RSN connection by
skipping the msg 3/4 and 4/4 completely. This would have resulted in
pairwise key not being configured. This is obviously not supposed to
happen in practice and could result in unexpected behavior, so reject
group key message before the initial 4-way handshake has been completed.
Signed-off-by: Jouni Malinen <j@w1.fi>
This modifies struct wpa_ptk to allow the length of KCK and KEK to be
stored. This is needed to allow longer keys to be used, e.g., with
Suite B 192-bit level.
Signed-off-by: Jouni Malinen <j@w1.fi>
The supplicant code does not try to control the actual channel of the
radio at any point. It simply passes the target peer and channel
parameters to the driver. It's the driver's responsibility to
periodically initiate TDLS channel-switch operations when TDLS
channel-switching is enabled.
Allow enable/disable operations to be invoked via the control interface.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Mark an appropriate sm flag when TDLS switch is prohibited by the AP.
Populate the flag upon association with the AP.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
