WPA3 Enterprise on Omada… Maybe not?
Hi TP Link and everyone,
I'm experiencing strange behavior when trying to utilize WPA3-Enterprise on your product. Some of the findings:
- External analysis tools tend to report the SSID's capabilities as WPA2-Enterprise or "unknown"
- Clients connect and show WPA2-Enterprise instead of 3
- The selection drop-down in the controller is WPA2/WPA3-Enterprise implying that you can't force it to *only* WPA3 Enterprise
- Some clients (Windows) seem to state on the client end that they are able to use WPA3-Enterprise
- Where is 192-bit mode?
There is a single thread in this forum where commenters mentioned that the server certificate must be trusted certificate from a *public* CA in order for WPA3 to work, otherwise it falls back to WPA2. I take exception to that on two counts:
1.) Automatic fallback is nightmarish for security. Would anyone here be okay with WPA falling back to WEP if WPA failed? Falling back to a broken/less secure protocol would not be an okay behavior. If it is misconfigured, it should simply fail to connect.
2.) In my network, I roll my own PKI using a root CA built in OPNSense with server and client certificates issued from it. I have installed the CA as a trusted root on all of my subordinate network devices (clients, Omada controller, RADIUS server, etc.). 802.11w (PMF) is required as per the WPA3 spec. The Wi-Fi alliance itself details on slide 20 of this document that SCV should work so long as the CA is trusted:
https://www.wi-fi.org/system/files/202012_Wi-Fi_Security_Roadmap_and_WPA3_Updates.pdf
Furthermore, when I did use a server certificate from a public CA on the RADIUS server (Let's Encrypt), WPA3 still failed.
From this bizarre fallback behavior, inability to select *only* WPA3 Enterprise instead of a mixed 2/3 option, lack of 192-bit mode, and inconsistent behavior, my conclusion is that TP-Link has only partially implemented support for WPA3 Enterprise within Omada and its constituent products.
What say you TP-Link?