I Vibe Coded a PPSK Portal Before Lunch

Several customers have private pre-shared keys installed. For anyone not familiar, that is a solution that basically uses a different pre-shared (PSK) key per user to access a network with the same SSID. Other vendors ship the same idea under different names. Cisco calls it iPSK, Aruba and Mist call it MPSK, Ruckus calls it DPSK. Aerohive coined the term Private PSK, which is why both Extreme and Ubiquiti say PPSK.

This has major benefits as you can then give someone a code (one way or the other) which will be used for that person that can then access the network.  Another person that wants to join this wireless network can join as well. Then you can of course revoke access for one user instead of dishing out new passwords for everyone that is using the SSID. This is for example very handy if someone leaves the company and you don't want the person to join the network again without having to change all the keys of the users and devices afterwards.

How it fits together

AAt a high level the setup is that you need two SSIDs and somewhere to keep the keys.

The first SSID is open. This is the onboarding side, the network you join just to register. It carries a captive web portal where the user fills in some details and is handed a key. No password needed to get this far, the portal is the gate.

The second SSID is the real one, the network you actually get on. It behaves like an ordinary WPA2* Personal network, but instead of one shared password it expects the personal key the user just received.

Tying the two together is a user group. The group is where the rules live. How the key is generated, which characters are allowed (ask me later how I got to know that one well), how long it stays valid, and which user profile or VLAN the user lands in. And if you want each user to get their own isolated little pocket of devices, that is the Private Client Group option sitting on the group.

The keys themselves live in a cloud password database that the management tool looks after for you. For a PPSK SSID you can keep that database in the cloud or push it down to every AP, and that choice matters more than it looks (more on that one later too). The tidy version is cloud. The platform validates the key and you never hand a static password to the hardware.

So that is the whole idea. Two SSIDs, a group that sets the rules, and a cloud keystore doing the bookkeeping.

For simplicity's sake, below is a basic flow of how this works. There are more features, for example you can issue keys that put users into different VLANs.

Now the challenge of today is that you want to verify this  in your own home lab without wasting an entire weekend. It is how to generate the key in an easy way so that it can be tested. For that you can use the build in solution, for example that you have an 'open' network, join a captive network, fill in some details. Wait for the email or message. Then type it to your wireless network and then fingers crossed that you typed it right and you get connected.

Or more fun, you can 'vibe code' your own application and use it to test it on your own Laptop, Fun! Is this difficult and can anyone (even my dear mother) do this?

So, I prompted AI, with a message:

" I want to use a registration page with API to create a temporary PPSK token using https://developer.extremeplatformone.com/ this way a user can go on the internet instead of registering via the open wireless"

And yes, it is not the best prompt but it went ahead (spoiler) and created the a program that I needed to be able to test:

From that one not-quite-perfect prompt, it went and:

• Checked the Platform ONE and ExtremeCloud IQ API docs to find the right call, the one that creates a PPSK user

• Worked out that the key creation needs an admin token, and that the token has to stay on a small backend instead of in the webpage

• Wrote that backend (Node), so the page only ever asks it for a key and never touches the token

• Built the registration page itself, the form a user fills in

• Added the nice touch of a scan-to-join QR code, so a phone joins without anyone typing a key

• Told me how to run the whole thing on my own laptop, step by step (happy to share if you want to do this)

To give you an idea of the result:

Was it perfect? Did it work in one go? Of course not. The program was written almost perfectly, but there were some hurdles to clear

How it comes together

A registration page, a small backend, the cloud. The page holds no secrets. The backend holds the API token and does the talking, because a page talking to the cloud directly would hand every visitor a key to the whole system.

There was some troubleshooting involved for example A wrong group id (needs to match up), a password rule that quietly banned digits, and one access point that turned out not to be beaconing at all (a thirty second packet capture settled that one).

All probe requests, no beacons, no join. The AP was not even on the air.

None of it was the code. The program was written in a couple of minutes. The bumps were all network, and clearing it still needs some manual labor…

So, could my mother do this? Probably not, but I think a tech savvy Wireless Engineer would. Know what you want and then knowing how to take 802.11 captures to troubleshoot will get you far.

And yes mom, if you read this, I will still come fix your wireless.

*I will write another blog about why WPA3 is not (yet) fully supported with all Vendors for PPSK