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>
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>
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 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 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This new mechanism allows P2P Client to request an IPv4 address from the
GO as part of the 4-way handshake to avoid use of DHCP exchange after
4-way handshake. If the new mechanism is used, the assigned IP address
is shown in the P2P-GROUP-STARTED event on the client side with
following new parameters: ip_addr, ip_mask, go_ip_addr. The assigned IP
address is included in the AP-STA-CONNECTED event on the GO side as a
new ip_addr parameter. The IP address is valid for the duration of the
association.
The IP address pool for this new mechanism is configured as global
wpa_supplicant configuration file parameters ip_addr_go, ip_addr_mask,
ip_addr_star, ip_addr_end. For example:
ip_addr_go=192.168.42.1
ip_addr_mask=255.255.255.0
ip_addr_start=192.168.42.2
ip_addr_end=192.168.42.100
DHCP mechanism is expected to be enabled at the same time to support P2P
Devices that do not use the new mechanism. The easiest way of managing
the IP addresses is by splitting the IP address range into two parts and
assign a separate range for wpa_supplicant and DHCP server.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
WPA_CIPHER_* and CIPHER_* are used for the exact same set of cipher
suites with the main difference being that the WPA_CIPHER_* version is
suitable to be used as a bitfield. Similarly, WPA_KEY_MGMT_* and
KEY_MGMT_* have similar design for AKMs. There is no need to maintain
two separate copies of the definitions since the bitfield compatible
version can be used for both needs. Get rid of the CIPHER_* and
KEY_MGMT_* versions to clean up the implementation by getting rid of
unnecessary mapping functions.
Signed-hostap: Jouni Malinen <j@w1.fi>
This prepares wpa_supplicant for accepting cases where the AP does not
use group addressed frames.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This adds initial parts for supporting the new GCMP-256, CCMP-256,
BIP-GMAC-128, BIP-GMAC-256, and BIP-CMAC-256 cipher suites.
Signed-hostap: Jouni Malinen <j@w1.fi>
