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
(Re)Association Response frame.
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>
Do not try to reconfigure the same TPK-TK to the driver after it has
been successfully configured. This is an explicit check to avoid issues
related to resetting the TX/RX packet number. There was already a check
for this for TPK M2 (retries of that message are ignored completely), so
that behavior does not get modified.
For TPK M3, the TPK-TK could have been reconfigured, but that was
followed by immediate teardown of the link due to an issue in updating
the STA entry. Furthermore, for TDLS with any real security (i.e.,
ignoring open/WEP), the TPK message exchange is protected on the AP path
and simple replay attacks are not feasible.
As an additional corner case, make sure the local nonce gets updated if
the peer uses a very unlikely "random nonce" of all zeros.
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>
sm->pmk_len was not set when deriving the PMK as part of OWE key
generation. This depending on wpa_sm_set_pmk_from_pmksa() call resetting
the value to the default. While this worked for many cases, this is not
correct and can have issues with network profile selection based on
association information. For example, the OWE transition mode cases
would hit an issue here.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Update these comments based on IEEE Std 802.11-2016 to get rid of the
already resolved TODO comment regarding duplicated N_KEY use. The
implementation does not need any changes since it was already following
the fixed version in the current standard.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This part is missing from IEEE Std 802.11ai-2016, but the lack of DHss
here means there would not be proper PFS for the case where PMKSA
caching is used with FILS SK+PFS authentication. This was not really the
intent of the FILS design and that issue was fixed during REVmd work
with the changes proposed in
https://mentor.ieee.org/802.11/dcn/17/11-17-0906-04-000m-fils-fixes.docx
that add DHss into FILS-Key-Data (and PTK, in practice) derivation for
the PMKSA caching case so that a unique ICK, KEK, and TK are derived
even when using the same PMK.
Note: This is not backwards compatible, i.e., this breaks PMKSA caching
with FILS SK+PFS if only STA or AP side implementation is updated.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
IEEE Std 802.11ai-2016 had missed a change in the Pairwise key hierarchy
clause (12.7.1.3 in IEEE Std 802.11-2016) and due to that, the previous
implementation ended up using HMAC-SHA-1 -based PMKID derivation. This
was not really the intent of the FILS design and that issue was fixed
during REVmd work with the changes proposed in
https://mentor.ieee.org/802.11/dcn/17/11-17-0906-04-000m-fils-fixes.docx
that change FILS cases to use HMAC-SHA-256 and HMAC-SHA-384 based on the
negotiated AKM.
Update the implementation to match the new design. This changes the
rsn_pmkid() function to take in the more generic AKMP identifier instead
of a boolean identifying whether SHA256 is used.
Note: This is not backwards compatible, i.e., this breaks PMKSA caching
based on the initial ERP key hierarchy setup if only STA or AP side
implementation is updated. PMKSA caching based on FILS authentication
exchange is not impacted by this, though.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
pmksa_cache_add_entry() may actually free old_entry if the PMKSA cache
is full. This can result in the PMKSA cache containing entries with
corrupt expiration times.
Signed-off-by: Andrew Elble <aweits@rit.edu>
This new AKM is used with DPP when using the signed Connector to derive
a PMK. Since the KCK, KEK, and MIC lengths are variable within a single
AKM, this needs number of additional changes to get the PMK length
delivered to places that need to figure out the lengths of the PTK
components.
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>
This extends fils_pmk_to_ptk() to allow FILS-FT to be derived. The
callers do not yet use that capability; i.e., actual use will be added
in separate commits.
Signed-off-by: Jouni Malinen <j@w1.fi>
The conditional gSTA and gAP (DH public keys) were not previously
included in Key-Auth derivation, but they are needed for the PFS case.
Signed-off-by: Jouni Malinen <j@w1.fi>
While responding to EAPOL-Key message 1/2 with EAPOL-Key message 2/2
when using FILS AKM suites the ENCRYPTED bit is not set in key info of
2/2 which causes AP to drop 2/2. Fix this by setting the ENCRYPTED bit
since FILS AKM based connection uses AEAD encryption/decryption.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
GTK rekeying was rejected if a prior 4-way handshake is not done.
Fix this by allowing GTK rekey to happen in case of a FILS connection
since it does not involve a 4-way handshake.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add a new PMKSA cache entry within wpa_supplicant if a driver event from
offloaded FILS shared key authentication indicates a new PMKSA entry was
created.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Update the internal fils_completed state when offloading FILS shared key
authentication to the driver.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
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>
When using FILS for FT initial mobility domain association, add MDE to
the Authentication frame from the STA to indicate this special case for
FILS authentication.
Signed-off-by: Jouni Malinen <j@w1.fi>
This change fixes the following compilation error:
wpa.c:2465: error: undefined reference to 'crypto_ecdh_deinit'
in builds where CONFIG_ECC does not get defined.
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>
draft-harkins-owe-07.txt does not specify these parameters, so need to
pick something sensible to use for the experimental implementation. The
Suite B 128-bit level AKM 00-0F-AC:11 has reasonable parameters for the
DH group 19 case (i.e., SHA256 hash), so use it for now. This can be
updated if the OWE RFC becomes clearer on the appropriate parameters
(KEK/KCK/MIC length, PRF/KDF algorithm, and key-wrap algorithm).
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 leads to cleaner code overall, and also reduces the size
of the hostapd and wpa_supplicant binaries (in hwsim test build
on x86_64) by about 2.5 and 3.5KiB respectively.
The mechanical conversions all over the code were done with
the following spatch:
@@
expression SIZE, SRC;
expression a;
@@
-a = os_malloc(SIZE);
+a = os_memdup(SRC, SIZE);
<...
if (!a) {...}
...>
-os_memcpy(a, SRC, SIZE);
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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 RSN supplicant implementation needs to be updated to use the new
BSSID whenever doing FILS authentication. Previously, this was only done
when notifying association and that was too late for the case of
reassociation. Fix this by providing the new BSSID when calling
fils_process_auth(). This makes PTK derivation use the correct BSSID.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This debug print can include GTK and IGTK, so use wpa_hexdump_key()
instead of wpa_hexdump() for it to avoid undesired exposure of keys in
debug log.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
While the FILS authentication cases were already using the proper PMK
length (48 octets instead of the old hardcoded 32 octet), the initial
association case had not yet been updated to cover the new FILS SHA384
AKM and ended up using only a 32-octet PMK. Fix that to use 48-octet PMK
when using FILS SHA384 AKM.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
While the key derivation steps are not expected to fail, this was
already done on the AP side, so do the same in the STA side.
Signed-off-by: Jouni Malinen <j@w1.fi>
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>
The new wpa_supplicant control interface commands FILS_HLP_REQ_FLUSH and
FILS_HLP_REQ_ADD can now be used to request FILS HLP requests to be
added to the (Re)Association Request frame whenever FILS authentication
is used.
FILS_HLP_REQ_ADD parameters use the following format:
<destination MAC address> <hexdump of payload starting from ethertype>
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>
Commit c93b7e1888 ('RSN: Check result of
EAPOL-Key frame send request') forgot to update two PeerKey users of
EAPOL-Key TX functions. That resulted in STK handshake failing since
message 2/4 and 4/4 TX calls were assumed to have failed when the return
value was changed from 0 to a positive value for success case. This
resulted in not updating nonce information properly and hitting
following error when processing STK 4-way handshake message 3/4:
RSN: INonce from message 1 of STK 4-Way Handshake differs from 3 of STK
4-Way Handshake - drop packet (src=<addr>)
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit 6d014ffc6e ('Make struct
wpa_eapol_key easier to use with variable length MIC') forgot to update
number of EAPOL-Key processing steps for SMK and STK exchanges and broke
PeerKey. Fix this by updating the Key Data field pointers to match the
new style with variable length Key MIC field.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds new wpa_supplicant control interface commands PMKSA_GET and
PMKSA_ADD that can be used to store PMKSA cache entries in an external
persistent storage when terminating a wpa_supplicant process and then
restore those entries when starting a new process. The previously added
PMKSA-CACHE-ADDED/REMOVED events can be used to help in synchronizing
the external storage with the memory-only volatile storage within
wpa_supplicant.
"PMKSA_GET <network_id>" fetches all stored PMKSA cache entries bound to
a specific network profile. The network_id of the current profile is
available with the STATUS command (id=<network_id). In addition, the
network_id is included in the PMKSA-CACHE-ADDED/REMOVED events. The
output of the PMKSA_GET command uses the following format:
<BSSID> <PMKID> <PMK> <reauth_time in seconds> <expiration in seconds>
<akmp> <opportunistic>
For example:
02:00:00:00:03:00 113b8b5dc8eda16594e8274df4caa3d4 355e98681d09e0b69d3a342f96998aa765d10c4459ac592459b5efc6b563eff6 30240 43200 1 0
02:00:00:00:04:00 bbdac8607aaaac28e16aacc9152ffe23 e3dd6adc390e685985e5f40e6fe72df846a0acadc59ba15c208d9cb41732a663 30240 43200 1 0
The PMKSA_GET command uses the following format:
<network_id> <BSSID> <PMKID> <PMK> <reauth_time in seconds> <expiration
in seconds> <akmp> <opportunistic>
(i.e., "PMKSA_ADD <network_id> " prefix followed by a line of PMKSA_GET
output data; however, the reauth_time and expiration values need to be
updated by decrementing them by number of seconds between the PMKSA_GET
and PMKSA_ADD commands)
For example:
PMKSA_ADD 0 02:00:00:00:03:00 113b8b5dc8eda16594e8274df4caa3d4 355e98681d09e0b69d3a342f96998aa765d10c4459ac592459b5efc6b563eff6 30140 43100 1 0
PMKSA_ADD 0 02:00:00:00:04:00 bbdac8607aaaac28e16aacc9152ffe23 e3dd6adc390e685985e5f40e6fe72df846a0acadc59ba15c208d9cb41732a663 30140 43100 1 0
This functionality is disabled be default and can be enabled with
CONFIG_PMKSA_CACHE_EXTERNAL=y build configuration option. It should be
noted that this allows any process that has access to the wpa_supplicant
control interface to use PMKSA_ADD command to fetch keying material
(PMK), so this is for environments in which the control interface access
is restricted.
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>
