A look into Multi-Preshared Keys

When implementing security on a wireless LAN, 802.1X/EAP is the way to go for maximum security. But as this is not always possible, we often need to make sure that WLANs with Preshared-Keys are implemented as secure as possible.

The PSK has to be very strong, that is common knowledge. But when different users or groups share a common PSK, additional risks are given. A PSK can not be easily revoked and each user knowing the PSK can spy on traffic of the other users.

One option to address this problem is to use IPSKs (Identity Preshared Keys, or private PSKs) where the Authenticator sends the clients MAC address to the RADIUS-server which is configured with the PSK for this particular client. On Cisco Platforms this is available on AireOS, 9800 and also Meraki. Other vendors often have something similar with different names.

When configuring my new 9800 WLC, I spotted another option, the Multiple Preshared Keys (MPSKs). The WLAN can be configured with up to five PSKs and the client can connect with any of them. An implementation could be to have one PSK for regular users and a different PSK for specific groups of IoT devices. Or different PSKs for different IoT-devices. With this feature, the amount of SSID can be reduced and still have different PSKs for different groups.

The Configuration

Configuring this feature is quite easy. We are just adding additional PSKs.

This screenshot is from an Embedded Wireless Controller, EWC, on a Catalyst 9115):

This is how it looks on the CLI:

wlan LAB-TEST 1 LAB-TEST
 security wpa wpa2 mpsk
  priority 0 set-key ascii 0 Test1234567890
  priority 1 set-key ascii 0 Test11111111
  priority 2 set-key ascii 0 Test22222222
  priority 3 set-key ascii 0 Test33333333
  priority 4 set-key ascii 0 Test44444444
 security wpa psk set-key ascii 0 Test1234567890

How does it work?

But how does this feature work when the WLC has no information which client uses which PSK? Up to now, I did not find any internal info on that, but let’s examine this feature a little deeper.

The RSN-information in Wifi Explorer Pro shows no difference to a regular SSID. Obviously, the client is not aware of this functionality and has to „see“ standard BSSID information:

Same for a Wireshark trace of the 4-Way handshake from two different clients with two different PSKs that look perfectly normal.

When debugging a client-connection with PSK4, I also didn’t see any hint of the internal process taken by the WLC:

Mar 27 15:49:30.040: %CLIENT_ORCH_LOG-7-CLIENT_MOVED_TO_RUN_STATE: Chassis 1 R0/0: wncd: Username (null), MAC: f84e.730f.ab65, IP 10.255.161.23 associated to AP (AP-2702-2) with SSID (LAB-TEST)

Mar 27 15:49:32.787: %CLIENT_ORCH_LOG-7-CLIENT_IP_UPDATED: Chassis 1 R0/0: wncd: Username (null), MAC: f84e.730f.ab65, IP 10.255.161.23 fe80::ca8:3aa9:a22b:63 IP address updated, associated to AP (AP-2702-2) with SSID (LAB-TEST)

But how can the WLC know which PSK to use?

When looking at the first two packets of the 4-Way-Handshake we can see that it can be quite easy for the WLC to figure out which PSK to use:

After the first packet of the 4-Way handshake, the client calculates the PTK from the PMK, ANonce, SNonce, AAddr, and SAddr. Based on this calculation the second packet includes a MIC (Message integrity Code).

The WLC does the same calculation, but does not know which PSK to pick. When testing the MIC with the first PSK fails, the test could go on with the next PSK until the MIC is successfully verified. On success, the WLC knows which PSK was used by the client.

Restrictions?

Yes, some are listed in the config guide. One big restriction is not listed, but you get an error when trying to enable MPSK on an SSID with WPA3 configured.

The reason gets clear when looking at the packets that are exchanged between client and WLC with WPA3-Personal:

In the SAE Commit phase, the client and the WLC generate elements that are based on the PSK. These are sent to the peer in packet one and two. In the SAE Confirm phase, both peers test if they have derived the same PMK. The WLC has to choose one PSK to send his SAE Commit, after receiving the client’s SAE Confirm, the WLC can only see if that choice was right or not. But the WLC can not just decide to use one of the other PSKs.

Conclusion:

I think that I’ll use MPSKs quite often in the future as WPA2 will be needed for quite some time, at least for the IoT-SSIDs.