3 ms·

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 th

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 3y ago
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.
- nighthawk454 3y ago
  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
  - bongodongobob 3y ago
    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 3y ago
      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
      - blibble 3y ago
        you just described RADIUS
      - bongodongobob 3y ago
        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.
        deleted 3y ago
        [deleted]
  - DougN7 3y ago
    Is that any stronger than using a password if an attacker could force a connection to fall back to the password?
- jauntywundrkind 3y ago
  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.
- dathery 3y ago
  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 3y ago
  Isn't coordination between APs something that Ubiquiti APs already do?
  - callalex 3y ago
    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.
  - jsjohnst 3y ago
    > 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.
benmmurphy 3y ago
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 3y ago
shameless plug: https://github.com/spr-networks/super 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 3y ago
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.
dfc 3y ago
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 3y ago
  SSH does mostly fine with trust-on-first-use.
  - samus 3y ago
    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.
rokkitmensch 3y ago
Because industrial grade encryption isn't for us plebs, comrade, but for the various ~government bureaus~ megacorps who deserve security. But not you.
mattbee 3y ago
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 3y ago
  > 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 3y ago
    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 https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf [2] https://w1.fi/cgit/hostap/plain/hostapd/hostapd.wpa_psk 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.
forward1 3y ago
> 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_ 3y ago
  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 3y ago
    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 3y ago
      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
deleted 3y ago
[deleted]

toast0 3y ago

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.

nighthawk454 3y ago
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
- bongodongobob 3y ago
  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 3y ago
    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
    - blibble 3y ago
      you just described RADIUS
    - bongodongobob 3y ago
      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.
      - deleted 3y ago
        [deleted]
- DougN7 3y ago
  Is that any stronger than using a password if an attacker could force a connection to fall back to the password?
jauntywundrkind 3y ago
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.
dathery 3y ago
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 3y ago
Isn't coordination between APs something that Ubiquiti APs already do?
- callalex 3y ago
  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.
- jsjohnst 3y ago
  > 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.

benmmurphy 3y ago

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 3y ago

shameless plug: https://github.com/spr-networks/super 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 3y ago

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.

dfc 3y ago

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 3y ago
SSH does mostly fine with trust-on-first-use.
- samus 3y ago
  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.

rokkitmensch 3y ago

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

mattbee 3y ago

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 3y ago
> 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 3y ago
  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 https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf [2] https://w1.fi/cgit/hostap/plain/hostapd/hostapd.wpa_psk 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.

forward1 3y ago

> 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_ 3y ago
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 3y ago
  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 3y ago
    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

deleted 3y ago

[deleted]