[londons_explore]

I want to know why WPA3 doesn't have a mode where a password is used for the initial connection, but then the client and AP generate a keypair and each store their half and use that for all future connections.

For all future connections, the AP can validate every client, and the client can validate that it is connecting to the same AP.

The AP could have an interface to 'revoke' access to any single client if necessary, and single use passwords could be used too.

That would give all the same benefits as WPA Enterprise (after the initial pairing), and all the ease of use of a preshared key.

[toast0]

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.

[dathery]

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).

[mcv]

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

[jsjohnst]

> 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.

[callalex]

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.

[nighthawk454]

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

[DougN7]

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

[bongodongobob]

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.

[klyrs]

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

[bongodongobob]

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.

[blibble]

you just described RADIUS

[jauntywundrkind]

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.

[dfc]

Saying that it is like WPA3 Enterprise after the initial pairing is somewhat unfair. The trust in the initial pairing is a large part of the draw. The trust on first use model you describe is similar to using a self signed certificate on a website. Sure, after you connect and trust the self signed certificate your connection to the server can use the same algorithms that it would have used with a trusted CA. But for large deployment there is something to be said for being able to trust that you are connecting to the right infrastructure.

[eru]

SSH does mostly fine with trust-on-first-use.

[samus]

It is really not. It's only fine if accessing the wrong machine is considered less bad than access by an unauthorized user. Depending on what you'd upload or download, that assessment might differ.

[mattbee]

You can already do this with hostapd under WPA3 or WPA2 - The password alone can identify each client, and activate different configs for each one.

Some commercial APs support this under different names but it's hard to make it work with RADIUS, which is usually necessary on larger installations.

But without preloaded certificates, the clients don't know that they're not connecting to a rogue access point.

Hotspot 2.0 was going to solve that part, but kind of died last year as the WiFi Alliance let their last KPI partnership die off.

[est31]

> The password alone can identify each client, and activate different configs for each one.

That's interesting, first time I hear this. How would that be represented in the hostapd config file? Would it be WPA enterprise using a radius server, or would it actually use WPA-PSK?

[mattbee]

Check the wpa_psk_file option in the main config file [1] which lets you specify a file full of PSKs [2], each with its own options like vlanid=X and keyid=X:

[1] https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf [2] https://w1.fi/cgit/hostap/plain/hostapd/hostapd.wpa_psk

Works with WPA2 or WPA3-Personal modes, but (if you didn't know) an attacker that sniffs a WPA2-Personal association can learn the password they're using.

[benmmurphy]

I guess the problem is it's the same until after the initial connection. And it not even clear that it is strictly better. It probably is, but now you are relying on two schemes instead of one so if the second scheme is broken you are worse off.

[spr-alex]

shameless plug: https://github.com/spr-networks/super is a project I work on that makes it easier to handle per-device wifi passwords on a single SSID, and it supports WPA3

[mmalone]

What would happen if you tried to reconnect to the network and the AP didn't have the pre-shared key? Presumably, you'd prompt the user and ask them if they want to connect. This is the same pattern as trust-on-first-use (TOFU) for SSH, except for non-expert users. It's a good thought but I think it'd fall apart in practice. You'd still be vulnerable to phishing / evil twin APs.

[rokkitmensch]

Because industrial grade encryption isn't for us plebs, comrade, but for the various ~government bureaus~ megacorps who deserve security.

But not you.

[forward1]

> why WPA3 doesn't have a mode where a password is used for the initial connection, but then the client and AP generate a keypair and each store their half and use that for all future connections.

Because it would regress security back to inferior bearer authentication.

[Terr_]

It's only equivalent if "the password" is fixed and can be used for an indefinite series of "first" connections.

In contrast, imagine that the thing the guest enters into their laptop is a freshly-generated random code which expires within X minutes and can only be used once.

[forward1]

That would be an improvement, but authentication would still be based on a phishable credential vs a cryptographic assertion, and ultimately exploited in the enterprise environment it was designed for.

[etskinner]

The enterprise environment would run the more secure version of it, and the prosumer people would run the less secure version. Doesn't mean the secure version is any less secure