Still a sore point for many enterprises, secure roaming for Wi-Fi clients doesn’t have to be such as chore.
When the IEEE created the 802.11i amendment for Wi-Fi security it did a great job of providing a framework for Wi-Fi security but a not-so-great job with secure roaming.
Within the 802.11i spec, 802.1X is effectively the foundation for this enterprise framework. Excellent for carriers and huge Fortune 500 enterprises with large IT staff, 802.1X is state-of-the-art when it comes to wired/wireless security. But what about the unfortunate 50,000?
Originally developed as a port-based wired authentication protocol, 802.1X was adapted for Wi-Fi use within the 802.11i standard but is notoriously slow for client roaming. Not to worry, Wi-Fi devices are still safe when they roam. Yet with 802.1X, more than likely they won?t do it with any great sense of urgency. Here’s why:
The majority of 802.1X systems require a RADIUS server to verify the credentials of the wireless user. The first time this happens is during initial association, which is completely normal. What occurs next is where the problem lies. Without 802.1X security a Wi-Fi client can roam quite quickly; somewhere in the neighborhood of <20 milliseconds – plenty fast for any streaming application like voice and video.
802.11i, however, specifies that a Wi-Fi client re-authenticate to the RADIUS server every time it roams to a new AP. Depending on the speed of your wired network and how fast your RADIUS server can respond, the total time will more than likely exceed appropriate roaming times and cause an interruption to your voice or video service.
The IEEE responded to this problem with the 802.11r (think R for roaming) amendment. 802.11r specifies methods for fast secure roaming that solves this problem by redefining the security key negotiation protocol. This allows both the negotiation and requests for wireless resources to occur in parallel. The approach is to allow part of the key (the shared secret between the authentication server and client) derived from the server to be cached in the wireless network.
Without 802.11r, when a 802.1X client roams it is treated like a new client and must verify credentials with the RADIUS server. 802.11r fixed that by requiring that the supplicant (client) send a PMKID (pairwise master key identifier) to the Wi-Fi system during roaming.
When the Wi-Fi system receives that PMKID, it will go through the normal 4-way handshake (which is responsible for encryption) without the need of contacting the RADIUS server. So, if you?re going to use WPA2-Enterprise, which requires 802.1X authentication, your client will need some kind of fast roaming mechanism if it is running any sort of delay-sensitive application.
That's what 802.11r was designed to deliver (here's a good primer on 802.11r).
So what’s the problem then? In a word: implementation. Or in another word: complexity.
Ultimately, there is no real standard for secure roaming that can be used by a majority of client devices. 802.11r and the ever upcoming Wi-Fi Alliance Voice-Enterprise certification offers standardized 802.1X roaming support, but just a few clients claim to support it and even those seem to be hit and miss.
Most wireless vendors have fixed the problem on the infrastructure side, but since most of us don?t make the client devices we are at their mercy. So how can you get enterprise-grade security that 802.1X promises without all the hassle? The answer? Dynamic Pre Shared Keys.
A patented a technique called Dynamic Pre-Shared Keys (DPSK) delivers the best of both worlds: the simplicity of pre-shared keys (without the sharing part) and 802.1X (with out the complexity part). DPSK gives you 802.1X level security that roams perfectly with every client produced since the introduction of WPA. It does this by automatically generating a unique 63-byte passphrase for each client that successfully passes authentication against your Zone Director, RADIUS, LDAP or active directory servers.
The first time a user connects to the network and is challenged with a username and password. If they successfully authenticate, the system generates a unique passphrase for that client, binding it to the MAC address of the device.
It then automatically installs that passphrase and the requisite wireless configuration info (eg. SSID, the key itself, etc.) on the client. Current customers successfully deploy DPSK security without EVER touching the end user?s device. What happens if a user is no longer valid? Set time limits on their key or invalidate their key with one click.
Oh, and to deploy it on every device in your network you don?t need certificates, a RADIUS server or weeks of training.