WLAN/SSID Security Migration into 6GHz Networks

With the introduction of Wi-Fi 6E/6GHz, there is a huge increase in available RF space, multiplying the overall total capacity of any wireless network, and at the same time, removing sources of interference and noise. This increase in performance and quality of the wireless connections will be really exciting and bring multiple opportunities, but this will come with the price of new and better security requirements for our WLAN/SSID configuration migration.

The new standard did not leave security out of the picture and any new device supporting 6GHz, will be required to “only” support the following security standards while in the new band:

◉ WPA3: this enforces mandatory Protected Management Frames (PMF/802.11w)

◉ Opportunistic Key Encryption (OWE). This replaces the concept of “Open SSID”, and allows to have encryption across devices, without any authentication

◉ Simultaneous Authentication of Equals (SAE). This takes the role of PSK (also called “personal”) authentication methods but makes it resistant to offline password attacks, with improved cryptographic algorithms

There are as well provisions for more advanced encryption methods (WPA3 Enterprise-192), and several mandatory things that must “not be supported“, for example:  PMF disabled/optional, TKIP, WEP, etc.

What does this mean for 6GHz deployments?

Well… in the rare case of a greenfield 6GHz deployment, it would be just “awesome, we get new improved security standards by default”…

The problem is that almost deployments will not be greenfield.  You will have to support the coexistence of all current networks and devices with the new standard and migrate existing networks to include the new 6GHz access points and clients.

What is more: with few honorable exceptions, most of the current WLAN/SSIDs configured out there for 2.4 and 5, will “not” work over 6GHz radios, as they do not meet the new security requirements.

This means that your SSID supporting WPA2 Enterprise (802.1x), can’t be broadcasted directly in 6GHz… same for any existing Webauth or WPA2-PSK SSIDs. All of them will need to be changed to conform to the new standard. In order to ensure things can be done properly, this will need planning, and quite possibly, careful testing.

Changes also mean concerns about backward compatibility, and any older devices may not like or support the new security settings, so this is not just a matter of flipping a configuration switch and hoping it works.

The good thing is that there are different options on how to handle brownfield scenarios, with proper and natural coexistence of the new APs and clients supporting WPA3 and 6GHz, with older devices still stuck supporting WPA2 or older standards. Each one has its benefits and implementation costs, so it is important to plan properly.

Figure 1. Radio Policy and 6GHz support

Transition mode

Some people may come back with “But transition mode is available, we should be able to set this WLAN with WPA2/WPA3 transition and get it done”, unfortunately,  things are not so simple. This mode was created to introduce WPA3 into legacy bands, not to make it easy for 6GHz adoption.

WPA3 describes transition mode as a kind of hybrid WPA2/WPA3 scenario, with PMF set to optional, and the group key using legacy crypto, but this is not allowed in 6GHz, so we can’t just flip the existing WLAN from WPA2 to transition mode and get it done…it simply can’t be supported in the new band.

Transition mode is an excellent way to handle a migration into a more secure standard in the legacy band. Older devices can coexist on the same SSID with new devices supporting WPA3/PMF, allowing a smoother migration, but the price to pay is compatibility. Multiple clients may behave erratically, or simply, fail to connect to a transition mode SSID, even if what they support is still allowed, plus this alone can’t solve the 6GHz  security mandatory requirements.

One word of caution: There is a related feature called “Transition Disable”, which can be set in the WLAN Security tab, in the WPA Parameters area.

Figure 2. Transition Disable location

This setting tells the client, that once it has connected successfully to WPA3, it should migrate its SSID profile to support “only” WPA3, and not connect back to WPA2 if that is the only option available. On one side, this is good for security, as it will migrate all client devices to WPA3 only, as they join the transition mode WLAN, but if the network is composed of multiple physical locations, for example, some are set to WPA2, others to WPA3/WPA2 transition mode, this will cause the migrated clients to fail when moved to a location with WPA2 only.

This is a possible scenario for some large networks, with the same SSID covering different controllers/AP setups and with configurations not matching  100%.  The largest example would be Eduroam, which shares the same SSID name worldwide. Setting this could have serious issues for clients  moving across different network providers, so please use this with care, and only if you can ensure the same security setting is set properly across all network locations

So, what options do we have?

Option 1: Everybody Moves

This is the most radical solution. Here we move all SSIDs to WPA3, SAE, or OWE, with a single SSID across all bands. This means that all legacy security support will be removed across all SSIDs.

This is only feasible for the Greenfield scenario, or when we have absolute control of all clients’ device versions and configurations. It is highly probable that customers will never go this route.

Client support

◉ Apple IOS: on 15.1, it does support WPA3/PMF, and SAE, but it does not support OWE. SAE support is not compatible with 6GHz requirements

◉ Android: Supports WPA3/PMF/SAE since version 10

◉ Windows: supported in 11, but should work on version 10-2004

Cons

◉ There is a large list of compatibility issues regarding some of the requirements, and implementing this option will lead to compatibility issues as soon as any older device tries to connect

◉ Migrating the SSID profile on clients may be problematic, depending on operating systems. Several devices will use right away the higher security offerings, others will need to be adjusted

Pros

◉ No need for additional SSIDs

◉ Removes any older low-security SSIDs

Option 2: Tailored SSIDs

In this scenario,  the idea is to create new SSIDs, specifically focused on functionality, with support on each band as needed. New SSIDs would be created for 6GHz support, optionally broadcasted in other bands.

This maximizes backward compatibility, as it leaves anything existing  “untouched”.

For example, a company may have an existing SSID design as:

◉ Legacy SSID: mycompany, broadcasted in 5 GHz supporting WPA2 Enterprise

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 and 5 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific SSID: mycompanyNG, broadcasted on 5 and 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ A new SSID will need to be created and broadcasted

◉ Additional profile configuration across devices. Depending on client management being available, this can be a daunting task

◉ SSID names are a sensitive subject for customers. Selecting a new name may not be simple in some instances

Pros

◉ No impact on anything already existing

◉ You can have a gradual migration of devices supporting the new security standards (WPA3) to the new SSID, without having to do a risky forklift in the client profile configuration

◉ Fast roaming supported between bands for the same WLAN

Option 3:  Same SSID, two WLAN profiles, using transition mode

Keeping the same SSID across bands, touches your existing WLAN profile changing it to WPA3 transition mode and restricting it to 2.4 and 5GHz. Plus adds a new profile, just for 6GHz, with the required security settings.

Following on our previous example:

◉ Legacy SSID: mycompany, WLAN profile mycompany, broadcasted in 5 GHz. Modified now to supporting WPA2 Enterprise and WPA3 in transition mode

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific WLAN profile: same mycompany, SSID, with different profile name, mycompanyNG  broadcasted on 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ Several client vendors have issues handling WPA3 transition mode properly

◉ Clients may not like the same SSID with different security settings across bands.

◉ Roaming is not supported across WLANs. A client authenticated in 5 GHz, will have to do full authentication when moving into 6

Pros

◉ No new SSIDs on the client side to be managed

◉ Devices supporting WPA3 will connect in legacy bands with the higher security standard. This will help with security migration

◉ As we have the same SSID name across bands, clients will be able to fallback from 6 to 2.4/5, in case of any coverage problem

Option 4:  Same SSID, two WLAN profiles, no transition

This is basically a small variation of option 3.  The existing profile is left untouched, and we add a 6GHz specific WLAN profile:

◉ Legacy SSID: mycompany, WLAN profile mycompany, broadcasted in 5 GHz. WPA2-Enterprise

◉ Guest SSID: mycompanyGuest, supporting webauth in 2.4 GHz

◉ IoT: mycompanyIOT, with WPA2-PSK, for restricted sensor/telemetry devices in 2.4 GHz

What we would add:

◉ Wi-Fi 6 specific WLAN profile: same mycompany, SSID, with different profile name, mycompanyNG  broadcasted on 6GHz, using WPA3 with 802.1x authentication and PMF

Cons

◉ Clients may not like the same SSID with different security settings across bands. This is yet to be confirmed, so far, no issues reported in testing

◉ Roaming across WLANs is not supported. A client authenticated in 5 GHz, will have to do full authentication when moving into 6

◉ Legacy bands will be stuck on lower security protocols

Pros

◉ No new SSIDs to be managed on the client side

◉ As we have the same SSID name across bands, clients will be able to fallback from 6 to 2.4/5, in case of any coverage problem

◉ Avoids any client interoperability issues with transition mode

Too many options, but which is the best?

For most customers, option 4 (new WLAN profile, same name, new security), is what will be implemented most of the time, as it allows deployments, reducing most risks.

For customers that want better security, option 2 (specific SSID), or option 3 (change to transition mode, add new profile for 6), will be the best suited.

And for sure, don’t move WPA2 networks to WPA2/WPA3 transition mode, without validating with your existing clients, especially if there are any legacy or custom devices present.

Source: cisco.com