[andrewaylett]

PEAP can still require a trusted server certificate -- getting set up with MDM is a pain, and scaling by hand is also a pain, but you can (and I do) set up my devices to require a specific valid SAN on the RADIUS connection. No extra certificate trust required, if the RADIUS server has a certificate that chains up to the default trust store.

I remain disappointed that there's no standard mechanism for mapping between an SSID and a domain name to know which SAN to trust.

[mmalone]

Just to clarify, are you describing EAP-PEAP or EAP-TTLS wrapping PEAP? I'm still learning a lot of this stuff... but, my understanding is that PEAP doesn't do TLS but TTLS + PEAP does. Right?

Fact remains, though, that users will probably bypass any certificate warnings (if allowed) and send their passwords to rogue APs. EAP-TLS mitigates this. Definitely pros & cons, but that's a clear win for EAP-TLS.

There are a lot of things that'd be nice to see in Wifi. Binding the SSID is an interesting one, though I suspect the folks working on this stuff were reluctant to rely on (and trust) the Web PKI CAs. If you're gonna push your own root cert, you might as well push a RADIUS SAN along with it, I guess.

[andrewaylett]

I have EAP-PEAP wrapping MSCHAPv2[1]. You might still be learning, but I suspect you already know more than I do about this stuff because I pretty much just stuck the right settings into the Unifi controller and poked at it until it started working :).

On Android, I set "use system certificates" and "Domain: radius.jumpcloud.com"[0]. On Mac, I'm given the option to verify the certificate and I can see that it chains up to their publicly-trusted CA. The vendor seems to assume that I'll be hard-coding their certificate in my MDM, but I've not needed to. The Mac wasn't happy when the certificate was rotated, but the Android and Linux devices I have were perfectly content.

My AP controller also has a valid certificate, but it's not in play. As a user, I need a username and password for MSCHAPv2, and to convince the client that the certificate is OK -- which is easy, when the client is willing to use the system trust store :). I'm not provisioning client certificates, so I don't need to generate a root for that purpose. And it's for home, so I only need to worry about provisioning for two people.

I really don't like setting trust bits on root certificates, even ones that I generated myself. Been there, would prefer a bit more certainty that I'm not being spoofed by my own leaked root certificate. I'm much happier trusting Web PKI than I am trusting anything of my own that's sufficiently accessible as to be usable for this kind of thing.

[0]: Yep, I'm using a hosted provider that's not your employer, sorry :P.

[1]: WPA-3 SAE is nice, and it would be really nice if we could use something including that for the EAP. SAE solves the spoofing issue for non-Enterprise use-cases, unless someone trusted with the key goes rogue. Per-user SAE could mean that the rogue user can only spoof themselves, I think?