Securely connecting a wifi client to an AP using a generated password

Question

I have two embedded systems, one acting as an AP with WPA2 and the other as a client. The idea is for a user to connect their client to the AP without any setup, so the authentication will all be handled automatically. The user will likely have multiple APs in their possession to connect to, but we intend to only connect to one AP at a time.

Is there a secure way of connecting these two devices to one another via wifi without the user entering a password? It might be ok to say "screw it" and rely solely on encrypting network traffic, but allowing an attacker onto the network would be more dangerous than not, right?

My initial thoughts are using one hardcoded password everywhere or basing the AP password on its SSID, neither of which are appealing.

Edit: I should mention, none of these devices will be connected to the internet

Answer 1

It sounds like 802.1x over WPA2 is the way to go. I won't say that this is necessarily easy to configure, but it may fit your requirements.

You'll need a CA. This could be your AD server for simplicity, you're enterprise might have one already, or you could designate any server you trust sufficiently to be an internal CA (if you're really a martyr, you could even use a public CA so long as you don't mind it taking weeks to add new clients and racking up thousands of dollars in fees). This will need to sign certificates for your RADIUS server and clients.

You'll need a RADIUS server. This can be the NPS service in Windows Server, FreeRADIUS on RHEL, pfsense, even some routers can do it (But if you make your router into a RADIUS server, I wouldn't admit it on the InfoSec Stack Exchange). This will need a signed cert to validate its identity to your clients. This will serve to authenticate your clients, it can be configured to do so by username/password, or it could do so by validating the client possesses a valid, signed cert. In some cases, you can configure the RADIUS server to check an LDAP directory (such as AD, IPA, openLDAP, etc.) which associates each identity (certificate in this case) with a set of groups. These groups could control which networks the user is authorized to connect to.

Your APs will need to be set to use WPA2 Enterprise, and configured to route authentication requests to the RADIUS server. Configuration varies wildly based on the make of your AP.

Your clients will need to have a signed cert loaded onto their system and configured to provide that cert as 802.1x authentication for the WiFi connection to your AP(s). Again this varies wildly depending on the device and configuration is left as an exercise to the reader. This is using client-authentication TLS over EAP and is thus usually decorated as the EAP-TLS option in many configs that I've seen.

Anti-Patterns

The issues with this depend on your environment and risk-acceptance. But these concerns should be addressed.

Getting certs to the client You'll need a way to get certificates onto the client device. In a passwordless environment, that certificate allows network access and must be protected like a password and thus a secure method of transmission must be devised (in this regard, it might undermine the whole reason you're considering this option).

For laptops, if you can wire it into the network, do some automated validation (MAC Address, Active Directory credentials, or whatever you devise), then you could load a signed cert onto the system (or have the system generate the cert and send a CSR to your CA).

But if your environment has phones/tablets, the problem becomes trickier. Options might be transferring certs by USB flash drives connected to OTG connectors (make sure you sanitize that drive after each time you connect it to a yucky user device). Perhaps you could provide an easier-to-access WiFi network on its own isolated network/VLAN, this could use a single PSK that you rotate as needed, and on this network all you can do is validate your device and be issued a cert. These options come with their tradeoffs, send them through your own risk analysis.

Cert Compromise The other concern is that certificates get compromised. Most likely this would only happen if a user's system is owned, but there could be a few other scenarios where a valid certificate is leaked. If you can identify this compromise early, you can have your RADIUS server validate against OCSP or a CRL. To combat against unknown compromises, you could set the certificates to expire quickly, but you have to have an infrastructure set up to automatically renew and install users certificates and ensure that most users connect at least once before their certificates expire. The best idea is probably a little bit of both and locking down network resources so that being on the network doesn't necessarily give you access to anything (i.e. don't use the same client certificates to authenticate to other network resources).

P.S.

This is not a quick and easy set-up, but it can be a robust one if you find a good level of trade-offs between providing access to users and protecting access from attackers. And it can allow you opportunities to expand and add additional functionality once you become more comfortable with your implementation.