AKM Suite Count: 2 – Benefit and Downside of an 802.1X & PSK Hybrid SSID

Introduction

In this blogpost, I’d like to show you how a single SSID with both 802.1X & PSK enabled looks like, what the use-cases for this constellation are, and what could go wrong when you decide to implement it.

Warning in advance: Use this option with caution – there are some pitfalls!

RSN Information Element

Since the introduction of IEEE 802.11i and the Wi-Fi Alliance certification “WPA2”, the proper way to establish an 802.11 connection between a Client STA and an Access Point looks something like this:

After Open System Authentication and Association, the 3rd step initiates the WPA2 authentication process, based on the authentitation configured (PSK or 802.1X).

Hint: When there is no security enabled (“None“), which is fairly common in guest networks, no further authentication takes place (maybe a captive portal, but this is no “real” authentication).

When you enable PSK or 802.1X authentication on an SSID, the Beacons and Probe Response Frames include the RSN Information Element, which amongst other things defines the type of encryption and authentication:

RSN Information Element with 802.1X Authentication

In an 802.1X-Protected WiFi, inside the RSN Information Element, the AKM Suite Count ist set to 1 (this indicates that only 1 type of authentication is allowed) and the AKM Suite is set to 00-0f-ac:1 (the 1 indicates that the Suite type is 802.1X):

RSN Information Element with PSK Authentication

In a PSK-Protected WiFi, inside the RSN Information Element, the AKM Suite Count is set to 1, too, but the AKM Suite is set to 00-0f-ac:2 (the 2 indicates that the Suite type is PSK):

RSN Information Element with 802.1X & PSK Hybrid Authentication

The 802.11-2016 Standard states (subclause 9.4.2.25.3 – “AKM suites”), that you are allowed to enable both 802.1X & PSK simultaneously, which allows you to operate an SSID with two different types of authentication methods:

NOTE—Selector values 00-0F-AC:1 and 00-0F-AC:2 can simultaneously be enabled by an Authenticator.

If both 802.1X and PSK authentication are enabled in an SSID, inside the RSN Information Element, the AKM Suite Count is now set to 2 (as there are now 2 allowed types of authentication), and below, both 00-0f-ac:1 and 00-0f-ac:2 are listed as valid AKM Suites:

Use Case for 802.1X & PSK Hybrid Authentication

I personally can see 2 valid reasons to use both 802.1X and PSK within the same SSID:

Migrate a WiFi from PSK to 802.1X:

To avoid adding a new/different SSID to your environment when you want to migrate your existing SSID from PSK to 802.1X, you can enable both authentication methods on the same SSID. The hybrid-situation would only be temporary, until every client is reconfigured (either via GPOs or manually). After the migration, you can disable PSK, and it would run as a “pure” 802.1X.

Onboarding MDM/BYOD-Devices

We were interested in using this as an option to onboard MDM/BYOD-Devices. Users could then connect their devices to the WiFi by entering a PSK, and their device would end up in a VLAN with restricted access to only our MDM/BYOD-Solution, where they could onboard themselves. During onboarding, they would get a user-certificate and the WiFi-Profile would get overridden to 802.1X. After disabling and enabling the WiFi, the device would reauthenticate, but this time via EAP-TLS, and thanks to Dynamic VLAN Assignment, they would end up in the appropriate VLAN.

Problems with 802.1X & PSK Hybrid Authentication

In the example of MDM/BYOD-Onboardung, there are some fundamental problems:

By enabling both 802.1X & PSK on the same SSID, you give every Client STA 2 options to connect to the WiFi. Well, this doesn’t sound so bad, right? But the problem lies underneath that… The coder of every operating system wants to make everything as simple as possible for end users. So when you click on a new SSID, you don’t have to decide wether you would like to connect to a “WPA Personal”, “WPA2 Personal”, “WPA Enterprise” or “WPA2 Enterprise” network – you automatically get the appropriate prompt to enter your Passphrase or Username/Password. This all happens based on the content in the RSN Information Element from within the Beacon or Probe Response Frames.

But now there are 2 different options in this element – which means that depending on the decision the Client STA makes, you either get a PSK-Prompt or a Username/Password-Prompt.

The workaround for this would be to instruct the users to not click on the WiFi, but rather manually create a new WiFi-Profile on their device on their own with the appropriate settings, which is very complicated for the people that are not really tech-savvy.

The 2nd problem is, that even once the WiFi-Profile was properly configured on the Client STA, some of them were not able to connect to the WiFi. Some of them sent out a Probe Request, but ignored the respective Probe Responses (probably because they thought that it was an AKM Suite mismatch), while others started the PSK 4-Way-Handshake, but after the 2nd Message decided to start an 802.1X Authentication, which of course eventually failed:

After all the tests I did, I have to say, that I would not recommend to enable both 802.1X and PSK on the same SSID in a live-environment – simply because you do not really have control over the end-systems and their behaviour.

Cheers Renzo