path: root/src/rsn_supp
Commit message (Collapse)AuthorAgeFilesLines
* Fix a typo in a commentJouni Malinen6 days1-1/+1
| | | | | | Spell NULL correctly. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* FT-SAE: Add RSNXE into FT MICJouni Malinen2019-10-181-1/+20
| | | | | | | 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>
* Merge wpa_supplicant and hostapd EAPOL-Key KDE parsersJouni Malinen2019-10-182-313/+0
| | | | | | | | 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>
* SAE: Add RSNXE in Association Request and EAPOL-Key msg 2/4Jouni Malinen2019-10-175-26/+137
| | | | | | | | | 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>
* RSN: Verify RSNXE match between Beacon/ProbeResp and EAPOL-Key msg 3/4Jouni Malinen2019-10-155-2/+60
| | | | | | | | 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>
* FILS+FT: Fix MFPR flag in RSNE during FILS exchange for FTJouni Malinen2019-10-011-1/+3
| | | | | | | | | | Commit e820cf952f29 ("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 ded56f2fafb0 ("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>
* Remove CONFIG_IEEE80211W build parameterJouni Malinen2019-09-086-53/+3
| | | | | | | | | 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>
* FT: Reject over-the-DS response with MFPC=0 if PMF is requiredJouni Malinen2019-08-161-0/+8
| | | | | | | | | | | 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>
* FT: Fix MFPR flag in RSNE during FT protocolJouni Malinen2019-08-161-4/+3
| | | | | | | | | | Commit e820cf952f29 ("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>
* More forceful clearing of stack memory with keysJouni Malinen2019-05-262-20/+22
| | | | | | | | | | | | 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>
* FILS: Verify RSNE match between Beacon/Probe Response and (Re)AssocRespJouni Malinen2019-05-221-0/+20
| | | | | | | | | | | | | | | | | | | 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>
* FT: Allow cached XXKey/MPMK to be used if new XXKey is not availableJouni Malinen2019-04-281-3/+12
| | | | | | | 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>
* FT: Store XXKey/MPMK in PMKSA cache instead of MSK (supplicant)Jouni Malinen2019-04-281-15/+36
| | | | | | | | | 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>
* Replace int status/reason_code with u16 variableJouni Malinen2019-04-222-2/+2
| | | | | | | | | 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>
* FT: Allow 4-way handshake for PTK rekeying to continue without PMK/PMKIDJouni Malinen2019-04-182-2/+12
| | | | | | | | 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>
* RSN: Ignore IGTK configuration errors with swapped KeyID valuesJouni Malinen2019-04-161-3/+21
| | | | | | | | | | | | | | | | 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>
* RSN: Report completion only after IGTK configurationJouni Malinen2019-04-161-4/+9
| | | | | | | | | | | | | | | | 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>
* Add AKM info in the debug message noting PMKSA caching entry additionJouni Malinen2019-03-271-1/+2
| | | | | | | This is useful for debugging issues where an expected PMKSA cache entry is not found. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* DPP2: PFS for PTK derivationJouni Malinen2019-03-183-1/+30
| | | | | | | | | | 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>
* DPP2: Extend wpa_pmk_to_ptk() to support extra Z.x component in contextJouni Malinen2019-03-171-1/+1
| | | | | | | | | | 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>
* FILS+FT: STA mode validation of PMKR1Name in initial MD associationJouni Malinen2019-03-131-2/+22
| | | | | | | | | | | 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>
* UBSan: Avoid an unsigned integer overflow warningJouni Malinen2019-02-251-1/+1
| | | | | | | | | | 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>
* tests: EAPOL-Key fuzzing toolJouni Malinen2019-02-111-0/+27
| | | | | | | | | | | | | | | | 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>
* RSN: Do not start preauthentication timer without candidatesJouni Malinen2019-02-111-1/+3
| | | | | | | | | | | | 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>
* OCV: Include and verify OCI in the FILS handshakeMathy Vanhoef2018-12-171-0/+39
| | | | | | | Include and verify the OCI element in FILS (Re)Association Request and Response frames. Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
* OCV: Include and verify OCI in the FT handshakeMathy Vanhoef2018-12-171-0/+41
| | | | | | | | 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>
* OCV: Verify OCI in 4-way and group key handshakeMathy Vanhoef2018-12-171-0/+40
| | | | | | | 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>
* OCV: Parse all types of OCI information elementsMathy Vanhoef2018-12-162-0/+15
| | | | | | Add functionality to parse all variations of the OCI element. Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
* OCV: Insert OCI in 4-way and group key handshakeMathy Vanhoef2018-12-162-2/+76
| | | | | | | | 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>
* OCV: Advertise OCV capability in RSN capabilities (STA)Mathy Vanhoef2018-12-165-1/+12
| | | | | | | Set the OCV bit in RSN capabilities (RSNE) based on station mode configuration. Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
* Make channel_info available to the supplicant state machineMathy Vanhoef2018-12-162-0/+10
| | | | | | | | 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>
* Fix indentation levelJouni Malinen2018-11-301-5/+5
| | | | | | This gets rid of smatch warnings about inconsistent indenting. Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
* RSN: Use COMPACT_MACSTR to match MAC2STRJohannes Berg2018-10-161-1/+1
| | | | | | We shouldn't open-code the %02x... when we have COMPACT_MACSTR. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* RSN: Do not replace existing Suite B PMKSA on 4-way handshakeJouni Malinen2018-09-271-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* WPA: Ignore unauthenticated encrypted EAPOL-Key dataMathy Vanhoef2018-08-081-0/+11
| | | | | | | | | | | | | | | | | 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>
* FT: Derive PMKR0Name/PMKR1Name using SHA-384 with AKM 00-0F-AC:13Jouni Malinen2018-06-061-1/+1
| | | | | | | | | | | | | | 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>
* FT: Support BIP-CMAC-256, BIP-GMAC-128, BIP-GMAC-256 in STA caseJouni Malinen2018-06-051-11/+36
| | | | | | | | 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>
* FILS: Fix KEK2 use in FT-FILS use casesJouni Malinen2018-06-051-4/+22
| | | | | | | | | | | | 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: 2f37387812a5 ("FILS: Add more complete support for FT-FILS use cases") Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: FTE generation for SHA384-based AKM on STAJouni Malinen2018-06-051-11/+26
| | | | | | | 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>
* FT: FTE parsing for SHA384-based AKMJouni Malinen2018-06-052-28/+74
| | | | | | | The MIC field is now a variable length field, so make the FTE parser aware of the two different field lengths. Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: PMK-R0 derivation using SHA384-based AKMJouni Malinen2018-06-052-4/+9
| | | | Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: XXKey derivation for SHA384-based AKMJouni Malinen2018-06-051-2/+9
| | | | | | XXKey is the first 384 bits of MSK when using the SHA384-based FT AKM. Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: Support variable length keysJouni Malinen2018-06-053-22/+37
| | | | | | This is a step in adding support for SHA384-based FT AKM. Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: SHA384-based AKM in RSNE processingJouni Malinen2018-06-042-2/+10
| | | | | | | 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>
* HS 2.0: Allow OSEN connection to be used in an RSN BSSJouni Malinen2018-05-291-0/+4
| | | | | | | | | 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>
* FT: Add MDE to assoc request IEs in connect paramsAhmad Masri2018-04-193-8/+55
| | | | | | | | | 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>
* Fix wpa_supplicant build with CONFIG_NO_WPADaniel Golle2018-04-131-2/+3
| | | | | | | | | | 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>
* SAE: Only allow SAE AKMP for PMKSA caching attemptsJouni Malinen2018-04-094-19/+28
| | | | | | | | | | 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>
* Clear pmk_len more consistently for extra protectionJouni Malinen2018-04-081-1/+5
| | | | | | | | | | | 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>
* FILS: Fix CONFIG_FILS=y build without CONFIG_IEEE80211R=yJouni Malinen2018-03-261-0/+2
| | | | Signed-off-by: Jouni Malinen <jouni@codeaurora.org>