Use a single location in wpa_sm_rx_eapol() for preparing the pointer to
the Key Data field and to its validated length instead of fetching that
information in number of processing functions separately.
Signed-off-by: Jouni Malinen <j@w1.fi>
Re-order wpa_sm_rx_eapol() to first go through all EAPOL (802.1X) header
validation steps using the original message buffer and re-allocate and
copy the frame only if this is a valid EAPOL frame that contains an
EAPOL-Key. This makes the implementation easier to understand and saves
unnecessary memory allocations and copying should other types of EAPOL
frames get here.
Signed-off-by: Jouni Malinen <j@w1.fi>
The additional eight octet field was removed from keydatalen without
proper validation of the Key Data Length field. It would have been
possible for an invalid EAPOL-Key frame to be processed in a way that
ends up reading beyond the buffer. In theory, this could have also
resulted in writing beyond the EAPOL-Key frame buffer, but that is
unlikely to be feasible due to the AES key wrap validation step on
arbitrary memory contents.
Signed-off-by: Jouni Malinen <j@w1.fi>
If PMF was enabled, the validation step for EAPOL-Key descriptor version
ended up rejecting the message if GCMP had been negotiated as the
pairwise cipher. Fix this by making the GCMP check skipped similarly to
the CCMP case if a SHA256-based AKM is used.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Some of the buffers used to keep a copy of PTK/TPTK/GTK in the
supplicant implementation maintained a copy of the keys longer than
necessary. Clear these buffers to zero when the key is not needed
anymore to minimize the amount of time key material is kept in memory.
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>
Incorrect PTK length was used in PMK-to-PTK derivation and the Michael
MIC TX/RX key swapping code was incorrectly executed for these ciphers
on supplicant side.
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>
The earlier changes to buffer EAPOL frames when not associated to avoid
race conditions (especially commit
3ab35a6603 but maybe something even before
that) broke PeerKey 4-way handshake. Fix this by using a separate check
before the race condition workaround to process PeerKey 4-way handshake
EAPOL-Key messages differently.
Signed-hostap: Jouni Malinen <j@w1.fi>
PeerKey entries need to be removed on disassociation and this needs to
be done in a way that cancels the possibly pending eloop timeout.
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>
The GTK rekey offload information was sent to the driver immediately
after the 4-way handshake which ended up being before the initial group
key exchange in the case of WPA (v1). This could result in even that
initial GTK handshake being offloaded and wpa_supplicant being left in
WPA_GROUP_HANDSHAKE state. Fix this by postponing the operation to
happen only after the full set of initial EAPOL-Key exchanges have been
completed (i.e., in the existing location for WPA2 and a after the group
key handshake for WPA).
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
There is not much use for enabling WPA without WPA2 nowadays since most
networks have been upgraded to WPA2. Furthermore, the code size savings
from disabling just WPA2 are pretty small, so there is not much
justification for maintaining this build option. Remove it to get rid of
undesired complexity.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Define a proper event prefix and include additional information to allow
ESS Dissassociation Imminent event to be used in a wpa_cli action
script.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit c3fea27274 added a call to clear
all other PMKSA cache entries for the same network if the PMKSA cache
entry of the current AP changed. This was needed to fix OKC cases since
the other APs would likely use the new PMK in the future. However, this
ended up clearing entries in cases where that is not desired and this
resulted in needing additional full EAP authentication with networks
that did not support OKC if wpa_supplicant was configured to try to use
it.
Make PMKSA cache entry flushing more limited so that the other entries
are removed only if they used the old PMK that was replaced for the
current AP and only if that PMK had previously been used successfully
(i.e., opportunistic flag was already cleared back to 0 in
wpa_supplicant_key_neg_complete()). This is still enough to fix the
issue described in that older commit while not causing problems for
standard PMKSA caching operations even if OKC is enabled in
wpa_supplicant configuration.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Replace CONFIG_IEEE80211V with CONFIG_WNM to get more consistent build
options for WNM-Sleep Mode operations. Previously it was possible to
define CONFIG_IEEE80211V without CONFIG_WNM which would break the build.
In addition, IEEE 802.11v has been merged into IEEE Std 802.11-2012 and
WNM is a better term to use for this new functionality anyway.
Signed-hostap: Jouni Malinen <j@w1.fi>
These fields do not use AES keywrap. Instead, they are protected with
management frame protection (and not included if PMF is disabled).
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Expiry can always trigger a deauthentication, but otherwise,
deauthentication should only happen when the *current* cache entry is
removed and not being replaced. It should not happen when the current
PMK just happens to match the PMK of the entry being removed, since
multiple entries can have the same PMK when OKC is used and these
entries are often removed at different times.
This fixes an issue where eviction of the oldest inactive entry due to
adding a newer entry to a full cache caused a deauthentication when the
entry being removed had the same PMK as the current entry.
Signed-hostap: Dan Williams <dcbw@redhat.com>
Add pmf=1/2 to wpa_supplicant STATUS command output to indicate that PMF
was negotiated for the connect (1 = optional in this BSS, 2 = required
in this BSS).
Signed-hostap: Jouni Malinen <j@w1.fi>
Even though the standard currently describes disassociation to be used
for RSN element mismatch between Beacon/Probe Response frames and
EAPOL-Key msg 3/4, this is unnecessary difference from other cases that
deauthenticate. In addition, there is no point in leaving the 802.11
Authentication in place in this case. To keep things simpler, use
deauthentication here to get rid of the only use of
wpa_sm_disassociate().
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
These values are used with WAPI and CCX and reserving the definitions
here reduces the number of merge conflicts with repositories that
include these functions.
Signed-hostap: Jouni Malinen <j@w1.fi>
Try to share most of the cipher information like key and RSC lengths and
suite selector conversions, etc. in wpa_common.c to avoid having similar
code throughout the WPA implementation for handling cipher specific
behavior.
Signed-hostap: Jouni Malinen <j@w1.fi>
This allows both hostapd and wpa_supplicant to be used to derive and
configure keys for GCMP. This is quite similar to CCMP key
configuration, but a different cipher suite and somewhat different rules
are used in cipher selection. It should be noted that GCMP is not
included in default parameters at least for now, so explicit
pairwise/group configuration is needed to enable it. This may change in
the future to allow GCMP to be selected automatically in cases where
CCMP could have been used.
This commit does not included changes to WPS or P2P to allow GCMP to be
used.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
cur_pmksa was left to NULL during the initial association. This can
result in unexpected behavior, e.g., in expiring PMKSA cache entries
since the current entry is not locked in that case. Fix this by updated
cur_pmksa when adding the initial PMKSA entry during msg 1/4 processing.
Signed-hostap: Jouni Malinen <j@w1.fi>
intended-for: hostap-1
When looking for PMKSA cache entries to use with a new association, only
accept entries created with the same network block that was used to
create the cache entry.
Signed-hostap: Jouni Malinen <j@w1.fi>
If a network configuration block is removed or modified, flush
all PMKSA cache entries that were created using that network
configuration. Similarly, invalidate EAP state (fast re-auth).
The special case for OKC on wpa_supplicant reconfiguration
(network_ctx pointer change) is now addressed as part of the
PMKSA cache flushing, so it does not need a separate mechanism
for clearing the network_ctx values in the PMKSA cache.
Add support to wpa_supplicant for device-based GTK rekeying. In order to
support that, pass the KEK, KCK, and replay counter to the driver, and
handle rekey events that update the latter.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The change to use wpa_dbg() in wpa_sm_parse_own_wpa_ie() could result
in a NULL pointer dereference if the function were called when WPA
state machine has not been initialized. While this cannot really
happen in practice, it is better to be prepared for that since that
was the case before the wpa_dbg() change.
This converts number of debugging messages to use wpa_msg() in order
to allow the interface name to be shown with the messages.
A new function, wpa_dbg(), is introduced to allow
CONFIG_NO_STDOUT_DEBUG=y builds to remove the debug strings. This is
otherwise identical with wpa_msg(), but it gets compiled out if stdout
debugging is disabled.
Previously, both NULL and ff:ff:ff:ff:ff:ff addr were used in various
places to indicate default/broadcast keys. Make this more consistent
and useful by defining NULL to mean default key (i.e., used both for
unicast and broadcast) and ff:ff:ff:ff:ff:ff to indicate broadcast
key (i.e., used only with broadcast).
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
Commit 83935317a7 added forced
disconnection in case of 4-way handshake failures. However, it should
not have changed the case where the supplicant is requesting fallback
to full EAP authentication if the PMKID in EAPOL-Key message 1/4 is
not know. This case needs to send an EAPOL-Start frame instead of
EAPOL-Key message 2/4.
This works around a problem with APs that try to force PMKSA caching
even when the client does not include PMKID in (re)association request
frame to request it. [Bug 355]
This sets the FT Capability and Policy field in the MDIE to the values
received from the target AP (if available). This fixes the MDIE contents
during FT Protocol, but the correct value may not yet be used in initial
mobility domain association.
