On Jul 5, 2022, at 3:24 PM, James Ralston <ralston@xxxxxxxxx> wrote: > 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. EAP-TLS will work. But if the EAP packets are carried over RADIUS, RADIUS uses MD5, which isn't FIPS compliant. > 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. It's impossible to update MS-CHAP at this point. I don't know of anyone who's trying to do that. > 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. Yes. > 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 ask OpenSSL "Pretty please, may I use MD4 in FIPS mode?", and OpenSSL will say "OK". Yes, it's that simple to bypass FIPS mode. wpa_supplicant / hostap also does this: src/crypto/crypto_openssl.c: legacy = OSSL_PROVIDER_load(NULL, "legacy") Which is used to load the legacy MD4 / etc. functions. And even if that didn't work, any software needing MD4 / MD5 will include it's own libraries to implement these functions. > ... > …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. I suspect using PEAP with MS-CHAPv2 may be fine, as the insecure MS-CHAPv2 is protected by a FIPS-approved TLS layer. However, the only way to be sure that non-FIPS methods don't "leak", is to use OpenSSL for all TLS exchanges, and then use internal functions for all MD4 / MD5 / DES functionality. This scenario also allows wpa_supplicant to run in a system where OpenSSL has had the legacy methods entirely removed. These issues are the same for RADIUS servers, which is why I've spent too much time looking into them. Any hard-line approach to FIPS means that RADIUS won't work, and many EAP methods won't work. Which severely limits your choices for network access. Although I suppose if you can't get on the network at all, then your systems could be judged as "secure". Useless, perhaps. But secure. Alan DeKok. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
