[o2bad455]

DD-WRT FreeRadius with PEAP-MSCHAPv2 has been working reliably for the past year or so with all of my modern clients, but the Android and Windows clients seem to authenticate differently! The Android clients can only connect using a client certificate (user/pswd isn't enough), but the Windows clients can only connect without using any client certificate (just user/pswd).

So today I tried to standardize by getting a Win 10 client to use a client cert too. After updating a FreeRadius user password and rebooting the router, I generated a fresh FreeRadius client cert p12 file, installed it on the Win 10 client for the current user using "Install PFX" from the Win pulldown, and then selected "Connect using a certificate" for the WiFi connection. But even after several tries and leaving it for over 30 minutes, the connection could never authenticate. So far, the connection can only authenticate from Win 10 if I don't use any client certificate at all.

As a sanity check, I successfully used the same exact client cert p12 file to authenticate from an Android 9 client. Any idea what I might do to get the Win 10 client to use the client cert as well? I realize that the client cert can be required instead of optional by changing a no to a yes in one of the FreeRadius config files, but first I'd need to get the Win clients on board.

[tedm]

windows pretty much ignores any certs not put in the trusted root certificate store under the Local Machine userID.

Instead of using the pulldown run msi and install the certificate addin and add it there.

[o2bad455]

That was it, thanks!

[tedm]

Now your next assignment is to stick the cert in a domain GPO so you can push it out automatically...LOL

[o2bad455]

Thanks for that, LoL! Sounds like a worthwhile challenge, but is Windows Server needed for a domain GPO?

Not sure if this is the right place to start, but I searched and found references to only Windows Server 2016+. See https://docs.microsoft.com/en-us/windows-server/networking/branchcache/deploy/use-group-policy-to-configure-domain-member-client-computers.

I just might have an older license for Windows Server that came with a Dell R410 (since migrated to a completely different OS), but it would definitely be older than 2016...

[kernel-panic69]

Might as well be running NT4 SP6a.

https://www.securew2.com/blog/peap-mschapv2-vulnerability

https://www.securew2.com/blog/eap-tls-vs-peap-mschapv2-which-authentication-protocol-is-superior

[o2bad455]

Yikes, thanks for the heads up! I had a feeling MSCHAPv2 might turn into a game of pop-a-mole. Now considereing EAP-TLS instead...

I think BS said that other FreeRadius-supported modes could work, but just not from the GUI (i.e., must edit the FR config files). Hopefully EAP-TLS is all there. Worst case, I guess my fallback from WPA2-EAP (PEAP-MSCHAPv2) could be WPA3-SAE(personal).

EDIT: Oh, wait a minute... According to the official spec, one of the improvements of WPA3-EAP over WPA2-EAP is that WPA3-EAP requires server certificate validation (SCV)!

On some of my dd-wrt routers (e.g., WRT1900ACS), I can select WPA3-EAP even though it's limited to CCMP-128 (AES) instead of the WPA3-EAP official minimum of GCMP-256 (AES). Would I be correct to conclude that using WPA3-EAP (PEAP-MSCHAPv2), even with the lesser AES, should still prevent OTA credential theft since it apparently enforces SCV?

I just tested some devices for compatibility (without proving actual SCV), and most of my clients could still connect to WPA3-EAP as the only change. But, interestingly, one of my fully updated PC client cards (plus an Android client) can't connect after switching from WPA2-EAP to WPA3-EAP, so there does seem to be a difference in addition to GCMP-256 and 802.11w MFP (which were otherwise configured the same for my testing). As long as that difference actually includes SCV, shouldn't that address most of the above-linked vulnerabilities?

EDIT #2: Even when only WPA3-EAP is selected in dd-wrt, the lack of GCMP-256 on the router apparently causes WPA3-capable clients to report the connection as WPA2-EAP. In this case, would SCV still be enforced by the dd-wrt router since that's set to WPA3-EAP, or might it not be enforced since the client reports it as WPA2-EAP (which doesn't necessarily require SCV)?