Hostapd has now been updated to include the group number when rejecting
the connection with UNSUPP_FINITE_CYCLIC_GROUP. We still need the existing
len == 0 check because old hostapd versions will still behave this way.
A length check was still assuming the 256 bit ECC group. This
was updated to scale with the group. The commit buffer was also
not properly sized. This was changed to allow for the largest
ECC group supported.
SAE was hardcoded to work only with group 19. This change fixes up the
hard coded lengths to allow it to work with group 20 since ELL supports
it. There was also good amount of logic added to support negotiating
groups. Before, since we only supported group 19, we would just reject
the connection to an AP unless it only supported group 19.
This did lead to a discovery of a potential bug in hostapd, which was
worked around in SAE in order to properly support group negotiation.
If an AP receives a commit request with a group it does not support it
should reject the authentication with code 77. According to the spec
it should also include the group number which it is rejecting. This is
not the case with hostapd. To fix this we needed to special case a
length check where we would otherwise fail the connection.
Rather than hard coding to SHA256, we can pass in l_checksum_type
and use that SHA. This will allow for OWE/SAE/PWD to support more
curves that use different SHA algorithms for hashing.
This fixes the valgrind warning:
==14804== Conditional jump or move depends on uninitialised value(s)
==14804== at 0x402E56: sae_is_quadradic_residue (sae.c:218)
==14804== by 0x402E56: sae_compute_pwe (sae.c:272)
==14804== by 0x402E56: sae_build_commit (sae.c:333)
==14804== by 0x402E56: sae_send_commit (sae.c:591)
==14804== by 0x401CC3: test_confirm_after_accept (test-sae.c:454)
==14804== by 0x408A28: l_test_run (test.c:83)
==14804== by 0x401427: main (test-sae.c:566)
The return from l_ecc_point_from_data was not being checked for NULL,
which would cause a segfault if the peer sent an invalid point.
This adds a check and fails the protocol if p_element is NULL, as the
spec defines.
The RFC (5869) for this implementation defines two functions,
HKDF-Extract and HKDF-Expand. The existing 'hkdf_256' was implementing
the Extract function, so it was renamed appropriately. The name was
changed for consistency when the Expand function will be added in the
future.
The "H" function used by SAE and EAP-PWD was effectively the same
function, EAP-PWD just used a zero key for its calls. This removes
the duplicate implementations and merges them into crypto.c as
"hkdf_256".
Since EAP-PWD always uses a zero'ed key, passing in a NULL key to
hkdf_256 will actually use a 32 byte zero'ed array as the key. This
avoids the need for EAP-PWD to store or create a zero'ed key for
every call.
Both the original "H" functions never called va_end, so that was
added to hkdf_256.
SAE is meant to work in a peer-to-peer fashion where neither side acts
as a dedicated authenticator or supplicant. This was not the case with
the current code. The handshake state authenticator address was hard
coded as the destination address for all packets, which will not work
when mesh comes into play. This also made unit testing the full SAE
procedure with two sae_sm's impossible.
This patch adds a peer address element to sae_sm which is filled with
either aa/spa based on the value of handshake->authenticator
The send confirm counter is incremented before calling sae_send_confirm
in all cases, but the function itself was also incrementing sc after
sending the packet. This isn't critical to the successful execution of
SAE as the AP just uses the sc value in the packet but it did violate
the 802.11 spec.
SAE (Simultaneous Authentication of Equals) takes place during
authentication, and followed by EAPoL/4-way handshake. This
module handles the entire SAE commit/confirm exchange. This was
done similar to eapol.
SAE begins when sae_register is called. At this point a commit
message will be created and sent out which kicks off the SAE
authentication procedure.
The commit/confirm exchange is very similar to EAP-PWD, so all
the ecc utility functions could be re-used as-is. A few new ecc
utility functions were added to conform to the 80211 'blinding'
technique for computing the password element.
