Move to PTKINITDONE state and mark PTK valid after successful completion
of FT protocol. This allows the AP/Authenticator to start GTK rekeying
when FT protocol is used. Previously, the station using FT protocol did
not get the new GTK which would break delivery of group addressed
frames.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the PMK-R1 needs to be pulled for the R0KH, the previous
implementation ended up rejecting the over-the-air authentication and
over-the-DS action frame unnecessarily while waiting for the RRB
response. Improve this by postponing the Authentication/Action frame
response until the pull response is received.
Signed-off-by: Jouni Malinen <j@w1.fi>
It was already possible to configure hostapd and wpa_supplicant to use
FT-SAE for the key management, but number of places were missing proper
AKM checks to allow FT to be used with the new AKM.
Signed-hostap: Jouni Malinen <j@w1.fi>
The pad field in the RRB messages is unused, but it should be
initialized to avoid sending out arbitrary data from stack. This was
also generating number of valgrind complaints about uninitialized memory
accesses in local FT tests.
Signed-hostap: Jouni Malinen <j@w1.fi>
Use of two variables to track bounds checking seems to be a bit too much
for some static analyzers, so add an extra condition for buffer padding
to avoid incorrect warnings.
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>
Reassociation Request/Response frame validation need to count all IEs in
the RIC. In addition, TIE is not protected, so it should not be included
in the count.
Signed-off-by: Hong Wu <hong.wu@dspg.com>
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.
This makes it easier (and a bit faster) to handle multiple local
radios with FT. There is no need to depend on l2_packet in that
case since the frame can be delivered as a direct function call.
The pairwise cipher field is supposed to be little endian, but the
message building functions did not swap the bytes on big endian
hosts while the message processing functions did. Fix this by using
little endian byte order in both places.
ANonce, SNonce, R0KH-ID, and R1KH-ID must match with the values
used in the previous FT authentication sequence message per
IEEE Std 802.11r-2008, 11A.8.4.
We do not have any keys set at this point so there is no point in
adding the MIC. In addition, IEEE Std 802.11r-2008, 11A.4.2
describes this frame to have MIC IE count of 0 and MIC of 0.
IEEE Std 802.11r-2008, 11A.4.2 describes FT initial mobility domain
association in an RSN to include PMKR1Name in the PMKID-List field
in RSN IE in messages 2/4 and 3/4. This makes the RSN IE not be
bitwise identical with the values used in Beacon, Probe Response,
(Re)association Request frames.
The previous versions of wpa_supplicant and hostapd did not add the
PMKR1Name value in EAPOL-Key frame and did not accept it if added
(due to bitwise comparison of RSN IEs). This commit fixes the
implementation to be compliant with the standard by adding the
PMKR1Name value into EAPOL-Key messages during FT 4-Way Handshake and
by verifying that the received value matches with the value derived
locally.
This breaks interoperability with previous wpa_supplicant/hostapd
versions.
It turns out that this is needed for both FT-over-DS and FT-over-air
when using mac80211, so it looks easiest to just unconditionally
re-configure the keys after reassociation when FT is used.
This seems to be needed at least with mac80211 when a STA is using
FT-over-DS to reassociate back to the AP when the AP still has the
previous association state.
Must update sm->pairwise when fetching PMK-R1 SA.
Add a workaround for drivers that cannot set keys before association
(e.g., cfg80211/mac80211): retry PTK configuration after association.
This is needed to fix PTK derivation to use correct length. Previously,
64-octet PTK may have been derived if the authenticator did not already
have a STA entry. Now, the correct pairwise cipher suite is learned when
then PMK-R1 SA is received.
Doxygen and some build tools may get a bit confused about same file
name being used in different directories. Clean this up a bit by
renaming some of the duplicated file names in src/ap.
