[spr-alex]

EAP-TLS is generally a great practice, as EAP-PEAP is vulnerable to MITM issues (fix proposed in https://www.ietf.org/archive/id/draft-josefsson-pppext-eap-t... but never adopted).

For the use case cited -- blocking MAC spoofing, EAP-TLS doesn't quite solve it, it mainly only solves authentication. The outer layer is not wrapped with TLS and is instead based on an ephemeral session key. Additional work is needed to stop the spoofing. The RFC states explicitly that channel binding, which would help stop the MAC spoofing, is not implemented https://datatracker.ietf.org/doc/html/rfc5216. What it does prevent is a client from being man-in-the-middled.

What's even wilder is that on some access points, when set to bridge mode, with an upstream Radius Authentication Server, as described, they may be vulnerable to ARP spoofing of the upstream radius server IP. This is something we've reported to vendors and were told "won't fix". Names include Netgear and TP-Link, though we don't suspect all routers from them are affected by this. We have not tested with the unifi access point referenced in the article.

So to restate the attack, cause it's so ridiculous, you should know about it: an anonymous, unauthenticated wireless station associates without a password. Next it would begin the EAPOL negotiation but it instead then proceeds to perform ARP spoofing to claim the IP address of the upstream Radius that is supposed to only be routed over the uplink interfaces. Even without knowing the shared secret, it's possible for the client to pretend to be the radius server to the AP, and authenticate itself onto the network. One thing you want to be very sure of when setting up 802.1X Radius Auth, is that your access point is not going to be misconfigured to allow clients to do this.

[mmalone]

> For the use case cited -- blocking MAC spoofing, EAP-TLS doesn't quite solve it

The idea would be to rely on the client certificate authentication and not use MAC filtering at all. For example, you could have an EAP-TLS network that's unrestricted and not let Mallory on it. Or you could use RADIUS reply attributes to put Mallory on a restricted vlan.

[kccqzy]

Why not just set up multiple SSIDs then? The devices connected to different SSIDs belong to different VLANs. Then you don't have to consider MAC spoofing or even deploy EAP-TLS: just give different devices a different password.

I'm sure there are simpler ways to deal with the use case in mind, but I think this article just wants to have fun with NSA-grade WiFi.

[spr-alex]

Right, although the article did not mention how to stop the spoofing. I started this thread to raise awareness and point out that the details around RADIUS can really matter here when not using a secure AP because some of the security assumptions about radius clients do lead to hilarious security failure

[mmalone]

If you're doing EAP-TLS wouldn't the ARP attack you're describing fail at the client when it's unable to verify the RADIUS server's certificate?

[spr-alex]

Correct, a wifi station client would not be attacked this way. As for the radius client -- the answer is it depends.

For many radius clients used by a common consumer AP, it's been possible for the spoofed radius to just say "okay, authenticated" to authorize itself -- and the shared secret is never used. It's worth noting that RADIUS may use MD5 with that shared secret, which is vulnerable to cracking attacks as well but I have not had to go down the rabbithole that far.

It would be interesting to try this against the Unifi AP brand named in the article and see how it handles it. My understanding is they run a custom Openwrt image so maybe they provide source code.

[g-b-r]

Companies should be able to be sued for things like this (deliberately leaving such a big vulnerability there without even warning the customers).

It's actually maybe already possible to consider it a fraud