Alexander Clouter <alex+freeradius@coremem.com> wrote:
On Mon, 26 Oct 2026, at 15:22, Brian Julin wrote:
Yes, we all know EAP-TLS exists. For those that wish to preserve the use of usernames and require a responsible user, rather then trust individual machines not to find their way into the wrong hands, EAP-TTLS-PAP seems to be the only viable multi-OS path forward.
Might shift your stance a little, Windows does tie client certificates to the TPM which may help alleviate some of those concerns.
That's great for managed systems that host auth and who's OS-enforced user account authentication you trust. Even better if that OS can competently handle using different certs when different users are logged in. But, we are waaayyy over half BYOD clients here, no GPO or Intune. It's less about whether the cert may leave the machine and more about whether the machine may leave the user.
On a related note, it is a real crime Google, Apple and Microsoft completely undermined EAP-GTC[3] and do not show the challenge message and cache the response as a static credential. We could have all gotten easy access to MFA.
Yeah, add the native IPSEC clients and the whole XAuth dead-end to that complaint for VPN, too. These days I pretty much operate under the assumption that the 3rd-party MFA VARs are giving kickbacks. True or not, it accurately predicts what to expect the native clients to do: completely ruin anything that makes MFA stuff, or even basic secure single auth, work OOTB.
1) For Windows to properly TOFU, TLSv1.3 must be turned off. Use TLSv1.2, it supports crypto suites required by WPA3 just fine. Microsoft Windows's session resumption for TLS1.3 is broken anyway, so there's even more reason to turn it off.
They are fixing this[2]. I am/was trying to kick the tires on it but wired 802.1X on Windows is absolutely 'hot garbage'.
In addition to the broken resumption, the Windows client when it detects TLSv1.3 swaps its backend logic to some newer flow that IIRC triggers either Credential Guard or some other cutoff that prevents a TOFU connection from completing, even though the creds are obviously not NTLM hashes. With or without session resumption turned off, it fails.
The bigger issue with resumption is that most people consider "TLS resumption == authentication + authorization" when really it is neither and all it _reliably_ does is established a TLS jacket faster.
Yes it's an optimization for roaming and that's really all it is. You have to balance your security requirements with how long you want to let the user kite along on a previous authentication/authorization decision, and keep track of what that decision was yourself, and it's a messy config.
The rlm_cache module inside FreeRADIUS can restore similar protections as well as reduce the load on KRB5 backend servers. This does involve a larger memory profile for the server as the cache can get pretty big. (I'd share the config we have worked up for this, but seeing as it is untested except for some lab experiments, I'll hold off till we get some mileage on it.)
I use this for LDAP bind()'s and Entra ID ROPC authentications backed by memcached, it works well. Overhead seems to be about 250 to 600 bytes per entry compared to ~3kB for TLS resumption caching.
Our prototype system is dedicated to just user/pass pairs, doesn't combine any authorization stuff. It still lets password guessing of many different passwords through to lock the account, and combined with a few other caches, handles AAA DoS attempts and spraying as much as possible. We hash the user/pass before storing the cache entry, and rotate the hash seed, which under FR3 is mere theater but once we are in FR4, where objects are wiped when freed, it will greatly reduce the theoretical exposure of retained creds in the AS server. It's a bit paranoid. Frankly you're pretty boned if someone is in far enough to read FR's memory space or freed segments. But you know, "security in depth", right? It should be a very nice stress test for rlm_cache once it's in production, but we're a long way off from that with the transition off PEAP still to come.