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 Request frame so
that an AP not supporting RSNXE can still validate the FTE MIC
correctly.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Verify that the AP included RSNXE in Beacon/Probe Response frames if it
indicated in FTE that RSNXE is used. This is needed to protect against
downgrade attacks based on the design proposed in 20/332r3.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is a workaround needed to keep FT protocol backwards compatible for
the cases where either the AP or the STA uses RSNXE, but the other one
does not. This commit adds setting of the new field to 1 in
Reassociation Request/Response frame during FT protocol when the STA/AP
uses RSNXE in other frames. This mechanism is described in 20/332r3.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
While 13.7.1 (FT reassociation in an RSN) in P802.11-REVmd/D3.0 did not
explicitly require this to be done, this is implied when describing the
contents of the fourth message in the FT authentication sequence (see
13.8.5). Furthermore, 20/332r2 is proposing an explicit validation step
to be added into 13.7.1.
Signed-off-by: Jouni Malinen <j@w1.fi>
While there may have initially been cases where the RSNE from
Beacon/Probe Response frames was not available from some drivers, it is
now more valuable to notice if such a case were to be hit with drivers
that are always expected to have such information available. As such,
make it a fatal error if the scan results for the current AP are not
available to check the RSNE/RSNXE in EAPOL-Key msg 3/4.
Signed-off-by: Jouni Malinen <j@w1.fi>
Avoid printing confusing FT debug entries from wpa_sm_set_ft_params()
when FT is not actually used for the connection.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use the same reason code to indicate that IE different in 4-way
handshake and also print a hexdump of RSNXE in both Beacon/ProbeResp and
EAPOL-Key msg 3/4 in the log.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_tdls_set_key() did set the key_id to -1 to avoid a useless
NL80211_CMD_SET_KEY call that the updated nl80211 driver no longer
carries out. Remove the no longer required workaround.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
The initial implementation of the PTK derivation workaround for
interoperability with older OWE implementations forced
WPA_KEY_MGMT_PSK_SHA256 to be used for all of PTK derivation. While that
is needed for selecting which hash algorithm to use, this was also
changing the length of the PTK components and by doing so, did not
actually address the backwards compatibility issue.
Fix this by forcing SHA256 as the hash algorithm in PTK derivation
without changing the PTK length calculation for OWE when
owe_ptk_workaround is enabled.
Fixes: 65a44e849a ("OWE: PTK derivation workaround in AP mode")
Fixes: 8b138d2826 ("OWE: PTK derivation workaround in STA mode")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
Since SAE PMK can be updated only by going through a new SAE
authentication instead of being able to update it during an association
like EAP authentication, do not allow PMKSA entries to be used for
caching after the reauthentication threshold has been reached. This
allows the PMK to be updated without having to force a disassociation
when the PMK expires if the station roams between the reauthentication
threshold and expiration timeout.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Since SAE PMK can be updated only by going through a new SAE
authentication instead of being able to update it during an association
like EAP authentication, do not allow PMKSA entries to be used for OKC
after the reauthentication threshold has been reached. This allows the
PMK to be updated without having to force a disassociation when the PMK
expires if the station roams between the reauthentication threshold and
expiration timeout.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
SAE authentication derives PMKID differently from the EAP cases. The
value comes from information exchanged during SAE authentication and
does not bind in the MAC addresses of the STAs. As such, the same PMKID
is used with different BSSIDs. Fix both the hostapd and wpa_supplicant
to use the previous PMKID as is for OKC instead of deriving a new PMKID
using an incorrect derivation method when using an SAE AKM.
This fixes use of opportunistic key caching with SAE.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
In order to correctly encrypt rekeying frames, wpa_supplicant now checks
if a PTK is currently installed and sets the corresponding encrypt
option for tx_control_port().
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
Add PMKSA candidates from scan results only if they advertise an AKMP
that is used with RSN pre-authentication. Previously, candidates were
added but then ignored later if the AKMP was not suitable.
Signed-off-by: Jouni Malinen <j@w1.fi>
This buffer was getting corrupted, so add more details to make it
clearer what causes the corruption should this type of regression show
up again.
Signed-off-by: Jouni Malinen <j@w1.fi>
Protect RSNXE, if present, in FT Reassociation Request/Response frames.
This is needed for SAE H2E with FT.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use a single struct definition and a single shared implementation for
parsing EAPOL-Key KDEs and IEs instead of maintaining more or less
identical functionality separately for wpa_supplicant and hostapd.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
Commit e820cf952f ("MFP: Add MFPR flag into station RSN IE if 802.11w
is mandatory") added indication of MFPR flag in non-FT cases and was
further extended to cover FT protocol in commit ded56f2faf ("FT: Fix
MFPR flag in RSNE during FT protocol"). Similar fix is needed for
FILS+FT as well.
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>
If FT over-the-DS case is enforced through the "FT_DS <BSSID>" control
interface command, the PMF capability check during BSS selection is not
used and that could have allowed PMF to be disabled in the over-the-DS
case even if the local network profile mandated use of PMF. Check
against this explicitly to avoid unexpected cases if the APs within the
same mobility domain are not configured consistently.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Commit e820cf952f ("MFP: Add MFPR flag into station RSN IE if 802.11w
is mandatory") added indication of MFPR flag in non-FT cases, but forgot
to do so for the FT protocol cases where a different function is used to
build the RSNE. Do the same change now for that FT specific case to get
consistent behavior on indicating PMF configuration state with MFPR.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
gcc 8.3.0 was apparently clever enough to optimize away the previously
used os_memset() to explicitly clear a stack buffer that contains keys
when that clearing happened just before returning from the function.
Since memset_s() is not exactly portable (or commonly available yet..),
use a less robust mechanism that is still pretty likely to prevent
current compilers from optimizing the explicit clearing of the memory
away.
Signed-off-by: Jouni Malinen <j@w1.fi>
IEEE Std 802.11ai-2016 requires the FILS STA to do this check, but this
was missing from the initial implementation. The AP side behavior was
not described properly in 802.11ai due to a missing change in the
(Re)Association Response frame format tables which has resulted in some
deployed devices not including the RSNE.
For now, use an interoperability workaround to ignore the missing RSNE
and only check the payload of the element if it is present in the
protected frame. In other words, enforce this validation step only with
an AP that implements FILS authentication as described in REVmd while
allowing older implementations to skip this check (and the protection
against downgrade attacks). This workaround may be removed in the future
if it is determined that most deployed APs can be upgraded to add RSNE
into the (Re)Association Response frames.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This allows supplicant side to complete FT initial mobility domain
association using FT-EAP with PMKSA caching.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
When completing FT initial mobility domain association with EAP, store
XXKey/MPMK in the PMKSA cache instead of MSK. The previously stored MSK
was of no use since it could not be used as the XXKey for another FT
initial mobility domain association using PMKSA caching.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
There are number of deployed APs with broken PMF implementation where
the IGTK KDE uses swapped bytes in the KeyID field (0x0400 and 0x0500
instead of 4 and 5). Such APs cannot be trusted to implement BIP
correctly or provide a valid IGTK, so do not try to configure this key
with swapped KeyID bytes. Instead, continue without configuring the IGTK
so that the driver can drop any received group-addressed robust
management frames due to missing keys.
Normally, this error behavior would result in us disconnecting, but
there are number of deployed APs with this broken behavior, so as an
interoperability workaround, allow the connection to proceed.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Previously wpa_supplicant_key_neg_complete() was called before the
attempt to configure the IGTK received from the authenticator. This
could resulted in somewhat surprising sequence of events if IGTK
configuration failed since completion event would be followed by
immediate disconnection event. Reorder these operations so that
completion is reported only if GTK and IGTK are configurated
successfully.
Furthermore, check for missing GTK KDE in case of RSN and handle that
with an explicit disconnection instead of waiting for the AP to deliver
the GTK later.
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>
DPP allows Diffie-Hellman exchange to be used for PFS in PTK derivation.
This requires an additional Z.x (x coordinate of the DH shared secret)
to be passed to wpa_pmk_to_ptk(). This commit adds that to the function
and updates all the callers to pass NULL,0 for that part in preparation
of the DPP specific changes to start using this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Verify that the AP uses matching PMKR1Name in (Re)Association Response
frame when going through FT initial mobility domain association using
FILS. Thise step was missing from the initial implementation, but is
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>
ext_supp_rates_len would be 0 here, so decrementing it by 2 will result
in unsigned integer overflow even if that result is not actually used
anywhere. Avoid that to get rid of the UBSan warning.
tdls.c:1597:27: runtime error: unsigned integer overflow: 0 - 2 cannot be represented in type 'unsigned long'
Signed-off-by: Jouni Malinen <j@w1.fi>
Add test-eapol program that can be used for fuzzing the EAPOL-Key
Supplicant and Authenticator implementations. This tool can write
Supplicant or Authenticator messages into a file as an initialization
step and for the fuzzing step, that file (with potential modifications)
can be used to replace the internally generated message contents.
The TEST_FUZZ=y build parameter is used to make a special build where a
hardcoded random number generator and hardcoded timestamp are used to
force deterministic behavior for the EAPOL-Key operations. This will
also make the implementation ignore Key MIC and AES keywrap errors to
allow processing of modified messages to continue further.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no need to schedule the postponed RSN preauthentication start
if there are no candidates. Avoid wasting eloop resources for this.
This is most useful for fuzz testing of the 4-way handshake
implementation to avoid getting stuck waiting for this unnecessary one
second time when using eloop to coordinate the Authenticator and
Supplicant state machines.
Signed-off-by: Jouni Malinen <j@w1.fi>
Include and verify the the OCI element in (Re)Association Request and
Response frames of the FT handshake. In case verification fails, the
handshake message is silently ignored.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
Verify the received OCI element in the 4-way and group key handshakes.
If verification fails, the handshake message is silently dropped.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
If Operating Channel Verification is negotiated, include the OCI KDE
element in EAPOL-Key msg 2/4 and 3/4 of the 4-way handshake and both
messages of the group key handshake.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
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>
PMKID derivation with the Suite B AKMs is a special case compared to
other AKMs since that derivation uses KCK instead of PMK as an input.
This means that the PMKSA cache entry can be added only after KCK has
been derived during 4-way handshake. This also means that PMKID would
change every time 4-way handshake is repeated even when maintaining the
same PMK (i.e., during PTK rekeying and new associations even if they
use PMKSA caching).
wpa_supplicant was previously replacing the PMKSA cache entry whenever a
new PMKID was derived. This did not match hostapd expectations on the AP
side since hostapd did not update the PMKSA cache entry after it was
created. Consequently, PMKSA caching could be used only once (assuming
no PTK rekeying happened before that). Fix this by making wpa_supplicant
behave consistently with hostapd, i.e., by adding the Suite B PMKSA
cache entries with the PMKID from the very first 4-way handshake
following PMK derivation and then not updating the PMKID.
IEEE Std 802.11-2016 is somewhat vague in this area and it seems to
allow both cases to be used (initial PMKID or any consecutive PMKID
derived from the same PMK). While both cases could be supported that
would result in significantly more complex implementation and need to
store multiple PMKID values. It looks better to clarify the standard to
explicitly note that only the first PMKID derived after PMK derivation
is used (i.e., match the existing hostapd implementation).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Ignore unauthenticated encrypted EAPOL-Key data in supplicant
processing. When using WPA2, these are frames that have the Encrypted
flag set, but not the MIC flag.
When using WPA2, EAPOL-Key frames that had the Encrypted flag set but
not the MIC flag, had their data field decrypted without first verifying
the MIC. In case the data field was encrypted using RC4 (i.e., when
negotiating TKIP as the pairwise cipher), this meant that
unauthenticated but decrypted data would then be processed. An adversary
could abuse this as a decryption oracle to recover sensitive information
in the data field of EAPOL-Key messages (e.g., the group key).
(CVE-2018-14526)
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
The AKM 00-0F-AC:13 is supposed to use cryptographic algorithms
consistently, but the current IEEE 802.11 standard is not doing so for
the key names: PMKID (uses SHA-1), PMKR0Name/PMKR1Name (uses SHA-256).
The PMKID case was already implemented with SHA-384 and this commit
replaces use of SHA-256 with SHA-384 for PMKR0Name/PMKR1Name derivation
to be consistent in SHA-384. While this is not compliant with the
current IEEE 802.11 standard, this is clearly needed to meet CNSA Suite
requirements. Matching change is being proposed in REVmd to get the IEEE
802.11 standard to meet the use case requirements.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
wpa_supplicant was hardcoded to use BIP-CMAC-128 in FT protocol if PMF
was enabled. Extend that to allow the other BIP algorithms to be used as
well.
Signed-off-by: Jouni Malinen <j@w1.fi>
When support for KCK2 and KEK2 was added, both keys were derived for
FT-FILS cases, but only KCK2 was actually used. Add similar changes to
use KEK2 to protect GTK/IGTK in FTE with using FT-FILS AKMs.
This fixes AES key wrapping to use the correct key. The change is not
backwards compatible.
Fixes: 2f37387812 ("FILS: Add more complete support for FT-FILS use cases")
Signed-off-by: Jouni Malinen <j@w1.fi>
The MIC field is now a variable length field, so make FTE generation in
wpa_supplicant aware of the two different field lengths.
Signed-off-by: Jouni Malinen <j@w1.fi>
This defines key lengths for SHA384-based FT AKM and handles writing and
parsing for RSNE AKMs with the new value.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows a single BSS/SSID to be used for both data connection and
OSU. In wpa_supplicant configuration, the current proto=OSEN
key_mgmt=OSEN combination is now allowing both the old separate OSEN
BSS/IE and the new RSN-OSEN to be used.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add MDE (mobility domain element) to Association Request frame IEs in
the driver assoc params. wpa_supplicant will add MDE only if the network
profile allows FT, the selected AP supports FT, and the mobility domain
ID matches.
Signed-off-by: Ahmad Masri <amasri@codeaurora.org>
pmksa_cache stubs have not been updated when function prototypes have
been modified in commit 852b2f2738 (SAE: Only allow SAE AKMP for PMKSA
caching attempts). Add new function parameter int akmp to stubs of
pmksa_cache_get() and pmksa_cache_set_current() as well to fix build.
Fixes: 852b2f2738 ("SAE: Only allow SAE AKMP for PMKSA caching attempts")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Explicitly check the PMKSA cache entry to have matching SAE AKMP for the
case where determining whether to use PMKSA caching instead of new SAE
authentication. Previously, only the network context was checked, but a
single network configuration profile could be used with both WPA2-PSK
and SAE, so should check the AKMP as well.
Signed-off-by: Jouni Malinen <j@w1.fi>
This gives more protection against unexpected behavior if RSN supplicant
code ends up trying to use sm->pmk[] with a stale value. Couple of the
code paths did not clear sm->pmk_len explicitly in cases where the old
PMK is being removed, so cover those cases as well to make sure these
will result in PMK-to-PTK derivation failures rather than use of
incorrect PMK value if such a code path could be reached somehow.
Signed-off-by: Jouni Malinen <j@w1.fi>
This extends the original IEEE Std 802.11ai-2016 functionality with the
changes added in REVmd to describe how additional keys are derived to
protect the FT protocol using keys derived through FILS authentication.
This allows key_mgmt=FT-FILS-SHA256 to be used with FT protocol since
the FTE MIC can now be calculated following the changes in REVmd. The
FT-FILS-SHA384 case is still unsupported (it needs support for variable
length MIC field in FTE).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Previously, matching PMKSA cache entry ended up clearing XXKey. However,
that XXKey is needed in the specific case where FT-SAE goes through the
initial mobility domain association with SAE authentication. FT-SAE
worked previously since the hostapd side generation of the particular
PMKID value in msg 1/4 was broken, but once that PMKID is fixed,
wpa_supplicant will need this fix to allow FT-SAE to be used.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The SAE AKM 00-0F-AC:8 is supposed to use EAPOL-Key Key Descriptor
Version 0 (AKM-defined) with AES-128-CMAC and NIST AES Key Wrap.
However, the previous implementation ended up using Key Descriptor
Version 2 (HMAC-SHA-1-128 and NIST AES Key Wrap). Fix this by using the
appropriate Key Descriptor Version and integrity algorithm. Use helper
functions to keep the selection clearer and more consistent between
wpa_supplicant and hostapd uses.
Note: This change is not backwards compatible. Both the AP and station
side implementations will need to be updated at the same time to
maintain functionality.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This fixes a corner case where RSN pre-authentication candidate from
scan results was ignored if the station was associated with that BSS
just before running the new scan for the connection.
Signed-off-by: Jouni Malinen <j@w1.fi>
Verify that TK, KCK, and KEK lengths are set to consistent values within
struct wpa_ptk before using them in supplicant. This is an additional
layer of protection against unexpected states.
Signed-off-by: Jouni Malinen <j@w1.fi>
Instead of setting the default PMK length for the cleared PMK, set the
length to 0 and explicitly check for this when deriving PTK to avoid
unexpected key derivation with an all-zeroes key should it be possible
to somehow trigger PTK derivation to happen before PMK derivation.
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes it easier to understand the cases where PMK gets configured
based on information from upper layer call (e.g., a PSK).
Signed-off-by: Jouni Malinen <j@w1.fi>
Currently, reinstallations of the PTK are prevented by (1) assuring the
same TPTK is only set once as the PTK, and (2) that one particular PTK
is only installed once. This patch makes it more explicit that point (1)
is required to prevent key reinstallations. At the same time, this patch
hardens wpa_supplicant such that future changes do not accidentally
break this property.
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
(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>
Jouni Malinen