aboutsummaryrefslogtreecommitdiffstats
path: root/src/common/wpa_common.h
Commit message (Collapse)AuthorAgeFilesLines
* FT-SAE: Add RSNXE into FT MICJouni Malinen2019-10-181-1/+5
| | | | | | | 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-181-0/+54
| | | | | | | | 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>
* Remove CONFIG_IEEE80211W build parameterJouni Malinen2019-09-081-8/+0
| | | | | | | | | 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>
* wlantest: Derive PMK-R1 and PTK for FT protocol casesJouni Malinen2019-08-221-0/+2
| | | | | | | | 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>
* FT: Reject over-the-DS response with MFPC=0 if PMF is requiredJouni Malinen2019-08-161-0/+1
| | | | | | | | | | | 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>
* DPP2: Extend wpa_pmk_to_ptk() to support extra Z.x component in contextJouni Malinen2019-03-171-1/+2
| | | | | | | | | | 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>
* Fix cipher suite selector default value in RSNE for DMGLior David2019-02-211-0/+3
| | | | | | | | | | | | | | | | | | | | 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>
* OCV: Parse all types of OCI information elementsMathy Vanhoef2018-12-161-0/+4
| | | | | | Add functionality to parse all variations of the OCI element. Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
* OCV: Protocol definitionsMathy Vanhoef2018-12-161-1/+4
| | | | | | | Define protocol identifiers for Operating Channel Verification (OCV) based on IEEE P802.11-REVmd/D2.0. 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: FTE parsing for SHA384-based AKMJouni Malinen2018-06-051-1/+10
| | | | | | | 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-051-1/+2
| | | | Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: Support variable length keysJouni Malinen2018-06-051-3/+4
| | | | | | 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-041-3/+2
| | | | | | | 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>
* FILS: Add more complete support for FT-FILS use casesJouni Malinen2018-03-261-0/+4
| | | | | | | | | | | | | 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>
* SAE: Fix EAPOL-Key integrity and key-wrap algorithm selectionJouni Malinen2018-03-161-0/+3
| | | | | | | | | | | | | | | | 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>
* Remove all PeerKey functionalityJouni Malinen2017-10-151-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Prevent installation of an all-zero TKMathy Vanhoef2017-10-151-0/+1
| | | | | | | | | | | | | | 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 ad00d64e7d8827b3cebd665a0ceb08adabf15e1e ('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>
* Prevent reinstallation of an already in-use group keyMathy Vanhoef2017-10-151-0/+11
| | | | | | | | | | 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>
* Add group_mgmt network parameter for PMF cipher selectionJouni Malinen2017-09-261-0/+3
| | | | | | | | | | 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>
* FILS: Add DHss into FILS-Key-Data derivation when using FILS SK+PFSJouni Malinen2017-09-131-1/+2
| | | | | | | | | | | | | | | | | 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>
* FILS: Update PMKID derivation rules for ERP key hierarchy establishmentJouni Malinen2017-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* DPP: Add new AKMJouni Malinen2017-06-191-4/+5
| | | | | | | | | | 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>
* FILS: Implement FILS-FT derivationJouni Malinen2017-05-071-1/+3
| | | | | | | | 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>
* OWE: Process Diffie-Hellman Parameter element in AP modeJouni Malinen2017-03-121-1/+3
| | | | | | | | This adds AP side processing for OWE Diffie-Hellman Parameter element in (Re)Association Request frame and adding it in (Re)Association Response frame. Signed-off-by: Jouni Malinen <j@w1.fi>
* OWE: Define and parse OWE AKM selectorJouni Malinen2017-03-121-0/+1
| | | | | | This adds a new RSN AKM "OWE". Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: Check key derivation results explicitly in AP operationsJouni Malinen2017-02-141-9/+9
| | | | | | | Previously, any potential (even if very unlikely) local operation error was ignored. Now these will result in aborting the negotiation. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* Define all RSN_CIPHER_SUITE_* valuesJouni Malinen2017-01-281-0/+8
| | | | | | | | This adds the cipher suite selector values for ciphers that are not really used with RSN, but are needed to be able to replace WLAN_CIPHER_SUITE_* definitions with RSN_CIPHER_SUITE_*. Signed-off-by: Jouni Malinen <j@w1.fi>
* Remove unnecessary ifdef from RSN_AUTH_KEY_MGMT_* definitionsJouni Malinen2017-01-281-2/+0
| | | | | | | These FT AKM suite selectors might be needed in code even if CONFIG_IEEE80211R is not defined. Signed-off-by: Jouni Malinen <j@w1.fi>
* FILS: Fix PMK and PMKID derivation from ERPJouni Malinen2017-01-131-0/+5
| | | | | | | | | | | 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>
* Fix wpa_cipher_to_alg() return typeJoel Cunningham2016-12-211-1/+1
| | | | | | | | | | | | | | | | wpa_cipher_to_alg() returns enumerated values from enum wpa_alg and all uses of the return value treat it as enum wpa_alg (by either assigning it to a variable of type enum wpa_alg or passing to a function that expects enum wpa_alg). This commit updates the return value to match the expected usage (enum wpa_alg) rather than int. This ensures the return value is of the proper type and eliminates the following compiler warnings: ARM RVCT (2.2): 'Warning: #188-D: enumerated type mixed with another type' Signed-off-by: Joel Cunningham <joel.cunningham@me.com>
* FILS: Fix hashed realm name derivationJouni Malinen2016-12-171-1/+1
| | | | | | | P802.11ai/D7.0 changed from CRC32 to SHA256 as the hash algorithm for the FILS realm name. Update the implementation to match that change. Signed-off-by: Jouni Malinen <j@w1.fi>
* FILS: Key-Auth derivation function for FILS SKJouni Malinen2016-10-221-0/+6
| | | | | | | | This implements Key-Auth derivation for (Re)Association Request frames (see P802.11ai/D11.0 12.12.2.6.2) and (Re)Association Response frames (see P802.11ai/D11.0 12.12.2.6.3). Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* FILS: PMK-to-PTK key derivation for FILS authenticationJouni Malinen2016-10-221-0/+4
| | | | | | | This is the PTKSA key derivation used as part of the FILS authentication exchange. See P802.11ai/D11.0 12.12.2.5.3. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* Make struct wpa_eapol_key easier to use with variable length MICJouni Malinen2016-10-101-18/+3
| | | | | | | | | | | | | | | | | | Suite B 192-bit addition from IEEE Std 802.11ac-2013 replaced the previous fixed length Key MIC field with a variable length field. That change was addressed with an addition of a new struct defined for the second MIC length. This is not really scalable and with FILS coming up with a zero-length MIC case for AEAD, a more thorough change to support variable length MIC is needed. Remove the Key MIC and Key Data Length fields from the struct wpa_eapol_key and find their location based on the MIC length information (which is determined by the AKMP). This change allows the separate struct wpa_eapol_key_192 to be removed since struct wpa_eapol_key will now include only the fixed length fields that are shared with all EAPOL-Key cases in IEEE Std 802.11. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* FILS: Advertise ERP domain in FILS Indication elementJouni Malinen2016-10-101-0/+1
| | | | | | | | Calculate the hashed realm from hostapd erp_domain configuration parameter and add this to the FILS Indication element when ERP is enabled. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* FILS: Add AKM definitionsJouni Malinen2016-10-101-1/+5
| | | | | | This adds definitions for the new AKM suite values from P802.11ai/D11.0. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* FT: Allow PMK-R0 and PMK-R1 for FT-PSK to be generated locallyMichael Braun2016-10-091-0/+2
| | | | | | | | | | | | | | | | | | Station should be able to connect initially without ft_pmk_cache filled, so the target AP has the PSK available and thus the same information as the origin AP. Therefore neither caching nor communication between the APs with respect to PMK-R0 or PMK-R1 or VLANs is required if the target AP derives the required PMKs locally. This patch introduces the generation of the required PMKs locally for FT-PSK. Additionally, PMK-R0 is not stored (and thus pushed) for FT-PSK. So for FT-PSK networks, no configuration of inter-AP communication is needed anymore when using ft_psk_generate_local=1 configuration. The default behavior (ft_psk_generate_local=0) remains to use the pull/push protocol. Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
* FT: Fix FTIE generation for 4-way handshake after FT protocol runJouni Malinen2015-12-091-1/+1
| | | | | | | | | | | | | wpa_insert_pmkid() did not support cases where the original RSN IE included any PMKIDs. That case can happen when PTK rekeying through 4-way handshake is used after FT protocol run. Such a 4-way handshake used to fail with wpa_supplicant being unable to build the EAPOL-Key msg 2/4. Fix this by extending wpa_insert_pmkid() to support removal of the old PMKIDs, if needed. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
* Fix Suite B 192-bit AKM to use proper PMK lengthJouni Malinen2015-10-141-0/+2
| | | | | | | | | | | | | 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>
* FT: Allow CCMP-256 and GCMP-256 as group ciphersJouni Malinen2015-07-071-0/+1
| | | | | | | | | | The FT-specific check for valid group cipher in wpa_ft_gen_req_ies() was not up-to-date with the current list of supported ciphers. Fix this by using a generic function to determine validity of the cipher. In practice, this adds support for using CCMP-256 and GCMP-256 as the group cipher with FT. Signed-off-by: Jouni Malinen <j@w1.fi>
* Remove WEP40/WEP104 cipher suite support for WPA/WPA2Jouni Malinen2015-06-201-9/+2
| | | | | | | | | As far as IEEE 802.11 standard is concerned, WEP is deprecated, but at least in theory, allowed as a group cipher. This option is unlikely to be deployed anywhere and to clean up the implementation, we might as well remove all support for this combination. Signed-off-by: Jouni Malinen <j@w1.fi>
* FT: Check FT, MD, and Timeout Interval length in the parserJouni Malinen2015-04-221-2/+0
| | | | | | | | All the existing users of these elements were already validating the element length. However, it is clearer to validate this already at the parser for extra layer of protection for any future changes. Signed-off-by: Jouni Malinen <j@w1.fi>
* Replace WPA_MAX_SSID_LEN with SSID_MAX_LENJouni Malinen2015-04-221-2/+0
| | | | | | This makes the source code more consistent. Signed-off-by: Jouni Malinen <j@w1.fi>
* Add Suite B 192-bit AKMJouni Malinen2015-01-261-5/+31
| | | | | | | WPA-EAP-SUITE-B-192 can now be used to select 192-bit level Suite B into use as the key management method. Signed-off-by: Jouni Malinen <j@w1.fi>
* Preparations for variable length KCK and KEKJouni Malinen2015-01-261-24/+26
| | | | | | | | 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>
* Suite B: Select EAPOL-Key integrity and key-wrap algorithms based on AKMJouni Malinen2014-11-161-2/+2
| | | | | | | | | This adds support for AKM 00-0F-AC:11 to specify the integrity and key-wrap algorithms for EAPOL-Key frames using the new design where descriptor version is set to 0 and algorithms are determined based on AKM. Signed-off-by: Jouni Malinen <j@w1.fi>
* Suite B: PMKID derivation for AKM 00-0F-AC:11Jouni Malinen2014-11-161-0/+10
| | | | | | | | | The new AKM uses a different mechanism of deriving the PMKID based on KCK instead of PMK. hostapd was already doing this after the KCK had been derived, but wpa_supplicant functionality needs to be moved from processing of EAPOL-Key frame 1/4 to 3/4 to have the KCK available. Signed-off-by: Jouni Malinen <j@w1.fi>
* Add RSN cipher/AKM suite attributes into RADIUS messagesJouni Malinen2014-07-311-0/+1
| | | | | | | | | This adds hostapd support for the new WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, and WLAN-Group-Mgmt-Pairwise-Cipher attributes defined in RFC 7268. These attributes are added to RADIUS messages when the station negotiates use of WPA/RSN. Signed-off-by: Jouni Malinen <j@w1.fi>
* Allow management group cipher to be configuredJouni Malinen2014-03-141-3/+4
| | | | | | | | | | This allows hostapd to set a different management group cipher than the previously hardcoded default BIP (AES-128-CMAC). The new configuration file parameter group_mgmt_cipher can be set to BIP-GMAC-128, BIP-GMAC-256, or BIP-CMAC-256 to select one of the ciphers defined in IEEE Std 802.11ac-2013. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>