On Fri, Jul 1, 2022 at 12:49 PM achtol <achtol@xxxxxxx> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
