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>
wpa_parse_kde_ies(), i.e., the only caller to wpa_parse_generic(),
verifies that there is room for KDE Length field and pos[1] (that
length) octets of payload in the Key Data buffer. The PMKID KDE case
within wpa_parse_generic() was doing an unnecessary separate check for
there being room for the Length, OUI, and Data Type fields. This is
covered by the check in the calling function with the combination of
verifying that pos[1] is large enough to contain RSN_SELECTOR_LEN +
PMKID_LEN octets of payload.
This is confusing since no other KDE case was checking remaining full
buffer room within wpa_parse_generic(). Clean this up by removing the
unnecessary check from the PMKID KDE case so that all KDEs are handled
consistently.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_parse_generic() can now recognize the Key ID KDE that will be needed
to deliver the Key ID of the pairwise key when Extended Key ID is used.
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>
WEP should not be used for anything anymore. As a step towards removing
it completely, move all WEP related functionality to be within
CONFIG_WEP blocks. This will be included in builds only if CONFIG_WEP=y
is explicitly set in build configuration.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previous implementation was hardcoding use of SHA256 PMK-to-PTK
derivation for all groups. Replace that with hash algorithm selection
based on the length of the prime similarly to the way this was done for
other derivation steps in OWE.
This breaks backwards compatibility when using group 20 or 21; group 19
behavior remains same.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The case where the old RSNE included one or more PMKIDs and that RSNE
was followed by another IE was handled incorrectly since the
os_memmove() to move the end of the buffer when removing old PMKIDs was
stopping copying at the end of the RSNE, not the end of the IE buffer.
This could result in corrupting the IE that followed the RSNE. In
practice, this broke FT-SAE with H2E by corrupting the RSNXE that is in
the buffer after the RSNE.
Fix this by copying the full end of the buffer (i.e., including the
following RSNXE in the visible error case) when removing the old PMKIDs.
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>
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>
Track PMK-R0/PMK-R0-Name from the initial mobility domain association
and derive PMK-R1/PTK when the station uses FT protocol. This allows
frames from additional roaming cases to be decrypted.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
This is not used only with FT, so make the comments less confusing and
include the function in all builds to make it available for
non-FT/non-FILS builds.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
These SAE, OWE, DPP, and OSEN AKM suite selectors were covered in the
reverse conversion in rsn_key_mgmt_to_bitfield(), but were missing from
wpa_akm_to_suite(). Add them to make AKM suite selector reporting more
accurate in RADIUS Accounting messages (and future users of this
function).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The offset update for copying KEK2 from the extended PTK was overriding
the offset instead of incrementing it (a likely copy-paste error from
the first offset assignment based on KCK). This resulted in KEK2 being
set to incorrect segment of PTK. Fix this by updating the offset
properly so that KEK2 is copied from the correct place at the end of the
PTK.
Fixes: 2f37387812 ("FILS: Add more complete support for FT-FILS use 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>
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>
Parse the OSEN IE from the AP to determine values used in the AssocReq
instead of using hardcoded cipher suites. This is needed to be able to
set the group cipher based on AP advertisement now that two possible
options exists for this (GTK_NOT_USED in separate OSEN BSS; CCMP or
GTK_NOT_USED in shared BSS case). Furthermore, this is a step towards
allowing other ciphers than CCMP to be used with OSEN.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
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>
While it is unlikely that FILS would be used without PMF or SAE in the
build, it is possible to generate such a build and as such, it would be
good for the KDF selection to work properly. Add CONFIG_FILS as an
independent condition for the SHA256-based KDF. Previously, this
combination would have resulted in failure to derive keys and terminated
key management exchange.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
The previous implementation ended up defaulting to using PRF-SHA1 for
deriving PTK from PMK when SAE was used. This is not correct since the
SAE AKM is defined to be using SHA-256 -based KDF instead. Fix that.
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>
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>
There should be no wpa_pmk_to_ptk() calls with the cipher argument
indicating a cipher that is not allowed as a pairwise cipher. However,
it looks like that was possible to happen with wlantest. Check for this
corner case explicitly to avoid generating confusing debug logs.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
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 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 Key MIC field value got truncated for all cases and incorrect HMAC
hash algorithm was used for the SHA512 cases.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This extends the helper functions for determining OWE key lengths and
Key MIC values to support other DH curves beyond the mandatory group 19.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new wpa_supplicant network parameter group_mgmt can be used to
specify which group management ciphers (AES-128-CMAC, BIP-GMAC-128,
BIP-GMAC-256, BIP-CMAC-256) are allowed for the network. If not
specified, the current behavior is maintained (i.e., follow what the AP
advertises). The parameter can list multiple space separate ciphers.
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>
