OpenWiFi Deployments with Multi-PSK Solutions

Recently, solutions offering MPSK-RADIUS services have gained traction in various deployment environments, including MDUs, parks, and venues. These systems provide a versatile solution, enabling user authentication, accounting, and attribute assignments such as VLANs, rate limiting, and quotas, all without requiring EAP support.

Some solutions, like those built on Passpoint 2.0, offer a smoother user experience by enabling seamless connectivity with zero user intervention. However, these solutions require EAP support, which is often lacking in low-end devices such as IoT devices. As a result, these devices cannot take advantage of the benefits provided by Passpoint 2.0-based solutions.

On the other hand, MPSK-RADIUS systems are based on the most common and basic security protocol in Wi-Fi, PSK (Personal), which is supported by virtually every device. In MPSK-RADIUS deployments, from the client’s perspective, there is no visible RADIUS server. Clients perform simple WPA or WPA2 Personal authentication using passphrases entered by the users.

In a traditional MPSK-RADIUS system, the AP does not have knowledge of the passphrase. Instead, a RADIUS server is configured with a list of MAC addresses and their corresponding passphrases. When a new client tries to connect to the AP, it goes through the open system authentication and association processes. Afterward, the AP initiates the 4-way handshake:

• The AP sends EAPOL-Key message 1, which contains the ANonce.
• The client generates the SNonce and, using it alongside the passphrase (which is expanded based on the SSID to become the PMK, where PMK = f(PSK, SSID)), generates the PTK and its derivatives (KEK, KCK, and TK).
  • PTK = f(PMK, Client MAC, BSSID, ANonce, SNonce)
• The client installs the PTK, constructs EAPOL-Key message 2 by adding the SNonce, and uses the KCK to calculate a MIC for the message payload.
• In a typical WPA2 Personal scenario, the AP would use the same inputs to calculate the PTK and verify the MIC based on the KCK. However, since the passphrase is stored on the RADIUS server, the AP forwards the entire content of EAPOL-Key message 2 to the RADIUS server in an Access-Request message.
• The RADIUS server searches for a matching MAC address in its list. Once a match is found, it uses the passphrase and the information from EAPOL-Key message 2 to calculate the PMK. The RADIUS server then sends the PMK to the AP in an Access-Accept message.
• With the PMK, the AP can either use the existing ANonce and SNonce to calculate the PTK and its derivatives or restart the 4-way handshake procedure to obtain new values. This decision typically depends on the configured timeout between EAPOL-Key messages and the time it takes for the RADIUS server to respond with the Access-Accept message.
• The remainder of the process follows the standard 4-way handshake. The AP installs the PTK, generates the GTK (if this is its first client), encrypts it with the PTK, and sends it in EAPOL-Key message 3.
• The final message, EAPOL-Key 4, is sent by the client to acknowledge the receipt and installation of the GTK.
  

This setup works well in controlled environments where the network administrator has a pre-populated list of all client MAC addresses. This scenario is common in enterprise networks where EAP is the primary authentication method, and MPSK-RADIUS is used to onboard IoT devices that do not support 802.1X.

However, a traditional MPSK-RADIUS setup is impractical in environments where the administrator has no control over the devices users bring to the network. A prime example is MDU networks, where the admin needs to manage a pool of PSKs that are not tied to a one-to-one mapping with specific MAC addresses. The system must allow users to authenticate with their assigned PSK, regardless of the MAC address of the device they are using to connect to the network.

MPSK with RADIUS systems offers a solution to the problem mentioned above. These solutions typically consist of multiple components that provide various services. Some of these components include:

• RADIUS server for authentication and accounting.
• Databases to manage pools of PSKs and PMKs.
• Captive portal services for user interaction and onboarding.
• SMS gateways to assist with new customer onboarding.
• User portal for customers to manage their subscriptions and change their passwords without requiring network admin intervention.

The workflow for an MPSK-RADIUS solution is similar to the traditional MPSK-RADIUS setup described above, with one key difference: instead of matching the MAC address of the authenticating client to a list of one-to-one MAC-to-PSK pairs, the system calculates the PTK and MIC for all PSKs in the pool and tests them against the MIC sent by the AP in EAPOL-Key message 2. When a match is found, the system forwards the corresponding PMK to the AP. Once the AP receives the PMK, it has two options:

• Create the GTK and build EAPOL-Key message 3: The AP generates the Group Temporal Key (GTK) if this is the first client or if a new GTK is needed. It then builds EAPOL-Key message 3, encrypts the GTK with the PTK, and sends it to the client.
• Restart the 4-way handshake: If the time spent waiting for the Access-Accept message with the PMK exceeds the timeout for the 4-way handshake, the AP will restart the handshake process. This ensures that fresh ANonce and SNonce values are used, allowing the process to complete successfully.
  

One major downside to the process described in the flowchart above is that every time a device roams to a new AP, it must undergo a full RADIUS authentication, which usually takes about one second. A roaming time of one second is unacceptable, as it can disrupt most Layer 3 (L3) connections. To address this, OpenWiFi enables PMKSA key caching for when the client re-roams back to the original AP and supports Fast Transition (FT) with MPSK-RADIUS or PSK-RADIUS when roaming to a new AP. The FT process can be summarized as follows:

• Client initiates the roaming process by scanning for the next best candidate AP.
• Client confirms FT support: The client checks whether the target AP supports Over-The-Air (OTA) or Distribution System (DS) FT transition roaming.
• For Over-The-Air (OTA) FT:
• Authentication exchange: The client and the target AP exchange FT Authentication frames. The client shares its SNonce, PMK ID, PMK-R0 ID, and Mobility Domain ID with the target AP. In return, the target AP provides its ANonce, PMK ID, PMK-R0 ID, PMK-R1 ID, and Mobility Domain ID.
• Association exchange: The client and the target AP exchange Association and Reassociation frames. In the Association frames, the client includes the same information as above, along with a MIC generated on the message payload. In the Reassociation frames, the target AP includes the same information plus the GTK.
• For Distribution System (DS) FT:
• Authentication exchange: The same information is exchanged in the Authentication frames as in OTA FT, but instead of being sent over the air, the data is embedded in an Action Frame sent to the current AP. The current AP forwards this frame over the distribution system to the target AP. The target AP replies to the client via the distribution system through the current AP.
• Association and Reassociation exchange: The Association and Reassociation frames remain unchanged, and the procedure follows the same steps as in the OTA case.

The packet capture screenshots below illustrate how PMKSA key caching and Over-The-Air (OTA) Fast Transition (FT) with MPSK-RADIUS reduce authentication time from approximately 1 second to around 50 milliseconds.