Hacker News Reader

Comment by toast0 | Hacker News Reader

It's not unusual to run multiple APs on a single SSID. Your scheme doesn't work for that without coordination between the APs.

Also, it means replacing an AP would require reconfiguring all the clients.

View on HN

You don't need active coordination for this. APs serving the same SSID could verify client certificates issued from any other AP by verifying that the certificate is signed by a trusted certificate authority. You'd just need each AP to use the same CA to issue signatures from.

You could give each AP its own intermediate CA tracing back to the same root CA to avoid sharing private keys and allow easily revoking certificates signed by a compromised AP.

You would only need coordination for revoking client certificates (but you can't really avoid that regardless of model).

Isn't coordination between APs something that Ubiquiti APs already do?

They have a rather clean implementation of standards called RADIUS and 802.11r, if that’s what you are talking about. It’s not unique to one manufacturer, that’s the whole point of Wi-Fi Alliance standards.

> Isn't coordination between APs something that …

All non-consumer grade (and some consumer grade) AP systems do. Ubiquiti isn’t first, unique, or best in this category.

Re: sibling comment, and no, WiFi Alliance isn’t what resulted in this working, you have it the wrong way around.

Couldn't it just fall back to the password version like it does every time now? Like optionally use the keys if present if not renegotiate

I'm guessing that's going to be an issue for handoffs between APs. Think walking around a multi-story office on a Wi-Fi call. Now picture 30 APs and 100 people on wifi calls/VoIP etc. with DHCP recycling addresses, randomized MACs and so forth.

Is there any obstacle to having a centralized server these APs talk to, which manages authentication? I'm not seeing a hard obstacle, just another piece of network kit and it's cheaper to keep a clunky UX

you just described RADIUS

In theory I suppose. But you have to take into account that these APs can potentially be on different subnets, physical networks, talking across ipsec tunnels, dealing with multiple VLANs etc. There's just more overhead. It's easier to push out the info to the APs than to pull from who knows where.

Edit: For example: Say you have two buildings connected via an ipsec tunnel/static route. You have 4 wifi networks on 4 separate VLANs, 2 per building, guest and internal. Generally you'll have an internal wifi controller on an infra VLAN as well.

The wifi VLANs are not allowed to route to the infra VLAN, but infra can route to wifi. Rather than punching holes back allowing the the APs to talk to infra, you push out from infra to the APs.

Is that any stronger than using a password if an attacker could force a connection to fall back to the password?

This is nonsense. If you are using WPA3 Enterprise across multiple AP, you need coordination, period. This comment raises zero significant concerns.

The parent suggestion is perfectly sound. More user-friendly means to mint certs would be grand. The caveat is that, if you can mint a cert from a low security password, what's to keep an attacker from attacking the password directly, rather than the cert? It might not let them snoop traffic, but it'd still let them on with the password.

Reply on news.ycombinator.com