WPA3 SAE and FIPS 140-3

[James Ralston]

On Fri, Jul 1, 2022 at 12:49 PM achtol <achtol at free.fr> wrote:

> I am facing a couple of issues with wpa_supplicant when built with a
> crypto library that aims FIPS 140-3 compliance.
>
> First, SAE. In sae_derive_pwe_ecc and sae_derive_pwe_ffc, an HMAC is
> calculated. The HMAC key is obtained by concatenating two MAC
> addresses.  The crypto library's HMAC function called by
> hmac_sha256_vector returns an error code, on the grounds that the
> 96-bit key is shorter than the minimum 112-bit length recommended by
> NIST SP 800-131A Rev. 2
> <https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final>.
>
> Next, SAE-PK. SAE-PK involves the AES-SIV cipher, which is not
> FIPS-approved.
>
> Does this mean that WPA3 is incompatible with FIPS? That would be
> puzzling, when the arguably less secure WPA2 does not pose such a
> problem (only constraints on the length of SSID/passphrases).

WPA3 encompasses multiple capabilities (1) aimed at different use
cases (WPA3-Personal, WPA3-Enterprise, WPA3-Enterprise with 192-bit
mode) with different requirements for authentication, key derivation,
key lengths, encryption algorithms, and message digest algorithms.
Some combinations will be forbidden by FIPS; some will not be.

If you are required to run your Wi-Fi client in FIPS mode, where the
cryptographic libraries that wpa_supplicant calls will fail an attempt
to call a cryptographic function forbidden by FIPS (or a FIPS-approved
function but with parameters forbidden by FIPS) will fail,
unfortunately, I think you will find that you will be unable to
connect / authenticate to many Wi-Fi networks.

For example, I encountered a similar issue: my organization uses (WPA2
Enterprise, PEAP version 0, MSCHAPv2 inner authentication) for Wi-Fi.
If I boot a Red Hat Enterprise Linux 9 laptop without putting it in
FIPS mode, I can successfully authenticate to the wireless network.
But if I boot it in FIPS mode, wpa_supplicant fails to authenticate,
logging this error message:

OpenSSL: EVP_DigestInit_ex failed: error:0308010C:digital envelope
routines:unsupported
EAP-MSCHAPV2: Failed to derive response

MS-CHAP-V2 is defined in RFC2759.  It’s 22 years old, and appears to
use no stronger encryption than DES and RC4, and no stronger digest
algorithm than MD4.  I see no updates to RFC2759 that permit stronger
algorithms or hashes.

Practically speaking, this doesn’t matter, as the MS-CHAP-V2 inner
authentication is encapsulated within a TLS session.  But the
cryptographic libraries on the system can’t know that.  All they see
(or, rather, what I suspect they see) is wpa_supplicant attempting to
call encryption and message digest functions forbidden by FIPS.  And
when the system is in FIPS mode, they must deny those functions.

So, unfortunately, the only way that it would appear that a Linux
system in FIPS mode can use wpa_supplicant to perform MS-CHAP-V2 inner
authentication is if wpa_supplicant contains private implementations
of (DES, RC4, MD4) and either uses them always, or uses them if it
detects that the system is in FIPS mode.

> Or, can it be claimed that these operations do not fulfill a
> security function?  In which case, I believe, using a
> non-FIPS-approved algorithm is permitted.

> My plan would be to throw in custom implementations of these
> algorithms, for these two functions only. But to do that I need a
> justification for these exceptions, so that the FIPS status of the
> whole system is not questioned.

Unfortunately, this is going to depend on what security standard you
are being held to, and who is auditing you.

If, for example, you are required to conform to DISA STIGs, where the
(e.g.) Linux system is required to boot with fips=1 passed to the
kernel, then as long as you can show the system is in FIPS mode (the
the /proc/sys/crypto/fips_enabled file contains “1” and not “0”), then
it doesn’t matter what cryptographic functions wpa_supplement
implements privately.  All that matters is that running
“cat /proc/sys/crypto/fips_enabled” outputs 1 instead of 0.

But if you are instead required to conform to something like, say,
NIST SP 800-181 (1), which contains (among others) this requirement:

§3.13.11 Employ FIPS-validated cryptography when used to protect the
confidentiality of CUI.

…then you will likely be challenged to prove that there is no way for
network communication that could contain CUI to occur without being
encapsulated in some way via a protocol (a VPN, HTTPS, SSH) that
employs only FIPS-validated cryptography, as you will not be able to
assert that the Wi-Fi layer employs FIPS-validated cryptography.

(1) https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Specification_v3.0.pdf

(2) https://doi.org/10.6028/NIST.SP.800-171r2