My previous post went more viral than I expected. My follow up post is getting long, so I’m going to break it up into 3 additional parts. This section, Part 2, will be an expansion of my previous post with some updated material and examples including Protocol Analysis.
This post will cover:
- Issues with WPA3-Enterprise and eduroam
- Possible solutions with protocol captures
The next two posts will cover the following topics:
- Options for deploying eduroam in 6ghz from different vendors
- Clients support for WPA3-Enterprise
- Downgrade Protection Issues
The topic of eduroam, 6ghz, and WPA3-Enterprise keeps popping up without anyone providing a definitive answer because there isn’t one. So, here is a follow up to my previous blog post on the topic. I don’t have THE answers but have some situational answers and will provide a ton of resources. So let’s get started.
*Quickly, I want to mention that I have been in conversations with our national eduroam organization Internet2, similar to Geant or other organizations in other locations of the world. They are aware of these issues. I have been told that they are working on updating their guideline documentation with workarounds, concerns, and additional information about these issues. To understand these issues, I recommend reading their documentation before beginning, that was last updated 10 months ago. They know their recommendations on their websites do not handle all of the problems with having a single SSID called eduroam across all the bands. I’ll add the resources to this page and share them publicly when we receive more information.
So what happens when it comes to eduroam and 6Ghz?
Almost twenty years ago, the Wifi industry made the migration from the broken WEP to a transitionary WPA to the finalized WPA2. WPA was a stop gap to quickly fix the issues with WEP until upgraded clients that supported WPA2 were released. That transition was just as fraught with issues as we are experiencing with WPA3. Although, the Wifi world was much smaller back then compared to today. We are seeing that same transition going from the twenty year entrenched WPA2 to the newcomer WPA3.
Things don’t always go so well when you make these types of transition. Even the solution to help called “Transition Mode” doesn’t mean devices are going to play nice. The recommendation for security and operational purposes is to just rip off the bandaid and not use the transition mode, with differently named SSIDs for different security types. The rub comes from the requirements from eduroam that says we can’t do a differently named SSID for security types. Those recommendations from eduroam also suggest using WPA3-Transition Mode. Well, that doesn’t work if you enable 6ghz with SOME vendors as I’ll explain shortly.
What’s our options?
My good friend, Doug Hales, after WLPC Phoenix tweeted the following summary of what he learned from WLPC about eduroam and 6Ghz. His tweet lead to a quality discussion that I’ll dig into shortly. I highly recommend, any interested parties go and read some of the responses. There isn’t going to be a solution that solves all our problems.
The purpose of eduroam is to provide seamless connectivity across organizations to as many in the educational community as possible. Not providing solutions for anyone that fails to connect is a fail in my eyes to the purpose of providing an eduroam network. But at the same time, providing 100% connectivity and support for every client out there is impossible.
In my previous post, I talked about these 4 solutions but now have an additional solution in bold below.
- Go all in on WPA3-Enterprise across the bands
- Use WPA2/3-Enterprise Transition Mode in 2.4/5 and WPA3-Enterprise in 6Ghz in a single configuration profile – Two vendors currently supports this when 6ghz is enabled.
- Use separate SSID configuration profiles with different security types ie. WPA2/3-Enterprise Transition for 2.4/5ghz and WPA3-Enterprise for 6ghz band. This was my solution but there are major FLAWS that I’ll discuss below.
- Continue to use WPA2-Enterprise in 2.4/5ghz and only use 6ghz for other non eduroam SSIDs.
- Use OpenRoaming in the 6Ghz band and eduroam WPA2-Enterprise in the 2.4/5Ghz bands.
Option 2 is new compared to my previous recommendations. I’ll explain it more in depth when I get to the Vendor support section in my next post, because currently only two vendors supports it, Juniper and Aruba. Hopefully more catch on; although, this is not part of the standard!
All options have the potential for some clients to fail. The question is which will cause the least number of issues? That may come down to the organization. Let’s dig deeper into some of the above options.
WPA3-Enterprise 192-Bit
I want to start with something not on that list that is explicitly called out by eduroam as something to not implement, WPA3-Enterprise 192-Bit. As eduroam mentions in their documentation and specifically called out in this document, DO NOT ENABLE WPA3-ENTERPRISE 192-BIT. This function was created for high security sites like governments and military. It causes major compatibility issues if you use it on eduroam because of requirements on the RADIUS server, not just the AP and Client sides.
That second document says the following in regard to 192-Bit:
“Despite being part of the Wi-Fi CERTIFIED WPA3™ certification, which suggests that it has an immediate effect only between client devices and access points, its security requirements would also induce a stringent required feature set on the RADIUS/EAP server equipment of eduroam Identity Providers. Early studies in the eduroam IdP landscape indicate that the cipher suite and key length requirements are not met by a majority of eduroam IdPs at this point in time. Furthermore, EAP methods not based on TLS – notably EAP-pwd – are not permitted at all on WPA3-Enterprise with 192-Bit Security networks.”
A network configured with 192-Bit sets the RSN Information Element as below with the GCMP-256 Cipher Suite compared CCMP-128 on the 128-bit WPA3-Enterprise side.
More details and the reasoning behind the choice to not support 192-Bit can be found on that document. I’ll also talk about this more in depth in my next post about Vendor Support because of a bug I found in Extreme Network’s configuration.
eduroam in All Bands with Full WPA3-Enterprise
There are some organizations that have gone all in and made eduroam their main SSID in the 2.4/5ghz legacy bands. Depending on the vendor of choice, all bands running WPA3-Enterprise may be how an organization will have to approach this, though, if they want eduroam in 6ghz.
Many clients support going full WPA3-Enterprise with eduroam. This will work for many of your end users. There is a lot of WPA3-Enterprise support in clients, especially on the WPA3-Enterprise side. I have tested this and it works.. until it doesn’t. The problems is we don’t have control over our client base with eduroam and can’t provide a different SSID for legacy clients.
The problem comes because that, while WPA3 has been around for several years, everyone put it off to rollout.. that is until 6Ghz started to go mainstream and that WPA3 migration became required. When you enable a single SSID across the 2.4, 5, and 6ghz bands in most Wifi vendors, you immediately enable WPA3 across all three bands WITHOUT the ability to do Transition Mode in the legacy bands. Any device that doesn’t support WPA3 is not going to work. Previous implementations in the legacy 2.4/5 bands could turn on WPA3 Transition Mode and be on your way to testing as the eduroam documentation recommends. That isn’t an option with most vendors when it comes to 6ghz.
Ultimately, the end goal for the best security, we want to move to Full WPA3-Enterprise. We don’t want to mess with Transition Mode, or the lesser versions of WPA2-Enterprise in the legacy bands, etc.
Jennifer (JJ) Minella talked about the issues with Transition Mode in her WLPC Phoenix 2023 presentation in the following video. She says that we should start migrating sooner than later.
BUT as I said before, with eduroam there are issues with moving full speed ahead since we have no control over the end users.
Maybe a separate guest network for those clients that struggle may fulfill those requirements for your organization. Play with it in the lab and see if you are willing to go down that road. As I’ve seen JJ mention several times in Tweets and her presentations.. TEST, TEST, TEST!!
When you go full WPA3-Enterprise, the RSN Information Element of the beacon looks like the screenshot below. It shows an AKM Suite Count of 2 because I have FT enabled on the SSID. The other AKM is for WPA3-Enterprise or AKM Suite 00:0f:ac WPA (SHA256). Unless a device understands that AKM, it is not going to join the network.
While not as headline grabbing, this may be the end solution and is where we will all arrive eventually. You may have to provide a WPA3-Enterprise eduroam SSID in all three bands and a separate guest network for any device that doesn’t connect to eduroam. Most are probably already providing a separate guest network right now. If you chose this route, be prepared for a possible increase in support tickets for those who can’t connect to eduroam. This partially follows eduroam’s current guidelines.
WPA2-Enterprise + PMF = WPA3-Enterprise
In response to my previous post, many people correctly exclaimed that the solution is that WPA3-Enterprise is just WPA2-Enterprise with required Protected Management Frames (PMF). The problem is the devices that do not support PMF may have problems with the RSN Information Element AKM that is broadcast in the beacons. So let’s dig into the issues with WPA3-Enterprise being just WPA2-Enterprise + PMF.
Jennifer (JJ) Minella in her book, Wireless Security Architecture, above discusses WPA3, WPA3-Enterprise, and OWE at length. She also briefly talks about them in this blog post:
At WLPC Phoenix 2023, JJ gave a special brief presentation, that sadly isn’t on the Youtube channel, about some testing they conducted in her Deep Dive at the conference. Luckily, Juniper had JJ on a webinar to discuss some of the findings. Many of the details about this I’ll dig into deeper in my next blog posts on clients.
She mentioned an issue with the advertised AKM in the beacons and how clients handle those AKMs. She said that, just like the transition from WPA to WPA2 20 years ago, there are clients that do not understand the AKM for WPA3. How Transition Mode works is that it includes both the AKM for WPA2-Enterprise and the AKM for WPA3-Enterprise in the beacons. The problem is that some devices will just give up when they see an AKM they don’t understand.
Let’s look at the Protocol Analysis level. Here is a PCAP of a 6ghz Beacon advertising WPA3-Enterprise. The same is shown in the Association Request and Reassociatiom Request frames. The AP is broadcasting multiple SSIDs in a single beacon as happens in 6Ghz. When using WPA3-Enterprise only it broadcasts the single AKM 00:0f:ac Type SAE (SHA256) since 802.11r FT is not enabled on this SSID.
Devices that don’t understand the WPA3 AKM Type SAE (SHA256) are not going to connect to a network configured with WPA3 in the 2.4/5ghz bands.
Next, let’s look at how the AKM looks for a WPA2 network. Since it is in the 5Ghz band, it only includes the single SSID in the beacon. This beacon shows the AKM 00:0f:ac Type WPA. Current WPA2-Enterprise eduroam networks look like this.
Finally, let’s look at how a beacon looks when it is broadcasting WPA2/3 Transition mode in the 2.4/5ghz band. This was captured in the 5ghz band on channel 64. The AKM Suite Count is 3 in this example since I have FT enabled as well. There is an AKM for WPA2, one for FT over 802.1X, and one for WPA3 (SHA256).
Devices that do not understand that last AKM may or may not freak out and may or may not join even though they understand the WPA2 AKM. This is the very heart of the problem for clients on WPA3-Enterprise eduroam networks. In that Juniper webinar, Wes Purvis says that this is a smaller issue when it comes to WPA3-Enterprise and multiple AKMs verses WPA3-Personal. I’ll discuss this more at length in my next post about client support for WPA3-Enterprise.
Dual Configured eduroam SSIDs – FLAWED Work Around
In my previous post, I included a break through solution, or so I thought. Wes Purvis, from Juniper Mist, mentioned it as a possible solution briefly in his WLPC Phoenix 2022 talk. Many vendors let you configure multiple SSIDs with the same name but different security profiles. I successfully configured one SSID called eduroam using WPA2-Enterprise for the 2.4/5Ghz band and another SSID called eduroam using WPA3-Enterprise for the 6Ghz band. The first two screenshots of the PCAPs in the previous section comes from this setup. I did a bunch of testing in my lab environment and it worked great, until it didn’t.
One note that I should have included was that you should use WPA2-Enterprise/WPA3-Enterprise Transition Mode on the 2.4/5Ghz bands eduroam SSID. My main test network used Ubiquiti and they do not have an option to enable WPA2/3-Enterprise Transition Mode. It’s only WPA2-Enterprise or WPA3-Enterprise but they do have the option to set PMF to optional on WPA2-Enterprise. Devices will NOT roam between bands if the 2.4/5ghz side does not have PMF set to optional or WPA3-Transition Mode. If you are going to play with this, enable Transition mode on the 2.4/5Ghz band and TEST IT.
For the Packet Capture below, I purposely set PMF to Disabled on the 5ghz eduroam profile. My iPad Pro would only connect to the 6ghz Profile. It didn’t even try to connect to the 5ghz profile! Without PMF being required or optional or WPA3-Enterprise Transition Mode, the two are completely different security types and incompatible.
Wes Purvis after my post shared some additional issues with this approach that they had found in their testing of this very solution. The BIGGEST problem comes down to 802.11r Fast Transition Roaming. I know some Institutions still do not enable FT on eduroam for compatibility issues.
Roaming vs Moving between SSIDs
I want to mention one more thing before digging into Roaming with Dual Profiles. On Twitter a few weeks ago there was a discussion about the definition of an ESSID. I include it here because it has some relevance to what I will get to in a minute.
If those three things are missing, it appears to be doing a roam but is just “moving” between the SSIDs.
The problem comes down to how TCP connections could drop and voice calls could disconnect when the device “moves” instead of “roams” between the two security types and bands. As Phil states, missing one of those three requirements will make it a move instead of a roam. Luke Jenkins pointed this out to me after doing some testing of it of his own.
Non 802.11r FT Roaming
When using this solution and using slow roaming Non Fast Transition (Non FT), the device will jump between bands. This is how my original tests showed that this solution worked.
Since a user’s eduroam RADIUS server could be located anywhere around the world, this can be an issue with latency when credentials are having to traverse continents or oceans. You may have to do the full 4-Way Handshake every time you join a new SSID/AP. That’s the nature of slow Non FT Roaming.
Shortly after publishing my previous post, Ben Toner approached me and said we should look at how my iPad is roaming using his tool, nOveright. His tools paints a good picture of what is happening to help explain things. The screenshot below from nOversight shows how my iPad Pro quickly moved between the different bands. This was eduroam configured as Non-FT.
These are slow roams, but it does move between bands with little problem.
A quick note, the breaks in connection at the beginning of the above screenshot are when I turned Wifi off on my iPad, then it roamed to my PrivateLTE network briefly because I forced it to disconnect from the Wifi to start my testing. Also for my testing, I’m using 160mhz wide channels to make the 6ghz network as welcoming as possible, so my iPad wants to be on 6ghz.
I setup multiple protocol captures using Adrian Granados‘ Airtool 2 connected to a WLAN Pi Pro and a couple custom WLAN Pis with 7 total adapters. Without Fast Transition enabled on either eduroam Profile, the client does a slow roam per profile..
At the beginning, the client has to do a Full Association with BOTH SSIDs Profiles. First it joined 5ghz on channel 108 and did a full 4-Way Handshake. Then it slow moved to the 6ghz SSID on channel 69 and had to do a full Association again. Once the initial full Association with both eduroam profiles is complete, it then can do Reassociations with either band as long as the PMKID is still valid if using PMK Caching (as Ubiquiti appears to be doing.) Things then work as expected with a slow roam.
In the above protocol capture, it shows my iPad Pro Reassociating to the eduroam SSID from channel 37 in 6ghz to channel 108 in 5ghz. On the reassociations, it has a cached PMKID from when it joined the profile before.
In my walking around trying to cause it to roam, I had the Apple Diagnostic Profile from Dan Jones installed and watched what channel the iPad was connected to. After the initial associtations, it would easily roam between 5 and 6ghz as quickly as a slow roam regularly takes. The key difference is you have to do a full association with both profiles before you can do Reassociations between the 2.4/5 and 6ghz bands. As another aside, I was testing this at home over Starlink, the RADIUS traffic to my RADIUS Server was going to the Starlink Satellites then back to the ground station, across the state to my office then back again. This added some latency, but it does work.
Next let’s look at the AKMs for the Association Requests. First is a 6Ghz WPA3-Enterprise only AKM.
Second is a 2.4/5Ghz WPA2-Enterprise only AKM. Another difference is that PMF is set to optional (not required but capable) as would be set in WPA3-Enterprise Transition mode.
802.11r FT Roaming
Next let’s look at how Dual SSID Profiles roaming works if we enable 802.11r FT. With FT, it doesn’t work, as there is not any roaming between bands at all. It requires a hard drop of the connection then does an association, not a reassociation, to the next band every time. Intra-band within 2.4ghz to 5ghz or 5ghz to 5ghz or 6ghz to 6ghz will FT roam normally with reassociations because it’s using the same profile configuration on the band.
As Phil Morgan mentioned in those Tweets I reference before, this is doing a “Move” and not an actual Roam.
With FT on Dual Profiles, Roaming between the 2.4/5 to 6ghz bands is destructive and doesn’t happen unless a SSID on the currently connected band is not available. I had to walk to the edge of the 6ghz cell to get it to try to join the 2.4 or 5ghz band SSID. At one point, my iPad Pro dropped to my PrivateLTE cellular network before associating back to the 5ghz band.
Let’s dig into my captures, first with Ben Toner’s tool, nOversight.
The above screenshot of nOversight shows my iPad Pro roaming with 802.11r FT enabled on the eduroam SSID using the duplicate profile method. The first 4 roams were intra-band on the 6ghz SSIDs only. It would NOT roam to another band but would happily roam on the same 6ghz band. Then in the middle, I walked to the edge of the 6ghz cell to force it to “move”. It suddenly jumped to 2.4ghz then 5ghz then to my PrivateLTE network then back to 5ghz. It was fine roaming between the 2.4 and 5ghz bands because they are configured with the same configuration profile.
As before I had the Apple Diagnostic Profile open on my iPad as I walked around causing the roams. The iPad prefers 5ghz over 2.4ghz and 6ghz over 5ghz, that’s why it was so quick to jump to 5ghz from the 2.4ghz. It then stayed on the 5ghz band until finally jumping back to 6ghz at the end. When I was at the edge of the cell, RSSI was around -80dBm and it still wasn’t roaming. It was acting sticky when Apple iPads usually tend to be better at roaming. Using this method will cause major issues with roaming between bands.
Next, let’s look at the Packet Captures.
The above capture shows it initially Associating to eduroam on channel 108 in 5Ghz as expected. Then things start to break.
The next screenshot above shows it trying but failing to Authenticate to eduroam on 6ghz channel 37. It then roamed with a FT Reassociation to my other AP on 5ghz channel 132, then back to channel 108 with a reassociation. It finally at the bottom is able to do a full Association to 6ghz on channel 37.
Once it is associated on the 6ghz profile, it then roamed to the 6ghz channel 69 with a Reassociation. Then there was another Reassociation back to channel 37. Then finally to prove the point, it does a full Association with the 5ghz profile on channel 108. Notice this time, the roam does not use Reassociations but Associations between profiles.
The problem comes down the PMK Keys that are established during the EAP Process. Those keys are not transitioned between profiles so the device does not have the correct keys on a different Band Profile. It does a very hard roam or “moves” when 802.11r FT is enabled.
Finally, let’s look at the AKMs for both Association Requests. First here is the RSN Information for the 6ghz Association Request.
Now, here is the AKM on the 5Ghz band Association Request. PMF is only set to capable but not required.
Logging Issues
Wes also pointed out that the either version of the Dual SSID Profile solution will cause issues with reporting and logging as these will appear as different networks in all logs. Less of an issue than causing connectivity problems, but a problem none the less.
In the end, is using a Dual SSID Profile solution worth it? Short answer is No. Longer answer is that it depends on if you need 802.11r FT or not. If you need FT then I do not recommend this solution, there are way too many issues. If you can deal without FT or aren’t using it currently, then the answer is a maybe. It’s fun to play with and test, but most networks need 802.11r FT now days and client support has improved. That hard disassociation then association to the next band with FT is a big issue.
Some vendors are implementing a better way of handling this without Dual Profiles that I’ll get to in my next post. Hopefully, more vendors catch on to the way those vendors are handling this.
OpenRoaming
I covered this solution in my previous article so I’m not going to cover it here again. I do not have an OpenRoaming setup available for testing. This has been successfully tested in Europe and is a proven solution. Although there are issues, such as clients not being configured for OpenRoaming or the additional setup requirements.
WPA2-Enterprise Only
Sticking with the old solution of not deploying eduroam in 6Ghz leaves you the ability to continue to provide WPA2-Enterprise as is. Should be status quo.. but what are we giving up?
I referenced Jennifer JJ Minella’s WLPC presentation earlier, but I’m going to share it here again because she does an excellent job explaining the issues.
As she says in that video, she is a huge proponent of using WPA3 NOW!! We are using a twenty year old security technology. Plus our management frames are being sent in the clear unencrypted across the PHY.. a major security issue.
Since in eduroam we are doing EAP authentication, then we are doing much better than WPA2-Personal though. With one big flaw.. Protected Management Frame (PMF). We can turn that on as optional and we get most of the way there. Clients that struggle with PMF don’t have to use it. You can get almost to Full WPA3-Enterprise while sticking with WPA2-Enterprise by setting PMF to optional.
Ultimately, WPA2-Enterprise eduroam networks are going to be with us for a long time. This is still a valid option for eduroam networks. There isn’t a need to push ahead and move eduroam into the 6Ghz band if an organization doesn’t feel the need. And with how few clients there are right now, pushing eduroam in 6Ghz is not a necessity. Should we be moving beyond a twenty year old technology, probably, but only do it at the speed your organization feels comfortable with.
What’s Next?
My next post, I’m going to focus specifically on option 2 above, how is vendor support and enabling eduroam in 6Ghz. With how 6Ghz and WPA3-Enterprise are in their infancy, the vendors are still working out the bugs and learning right along with us.
Then later I’ll dig into some of the research and findings being conducted around clients support and issues with WPA3-Enterprise. As several have requested, I’ll also talk about findings of the Downgrade Protection issues, if any, with eduroam.
