Design flaw in wireless VoIP handsets endanger the enterprise
Update 2/23/2008 - Cisco confirms vulnerability in 7921 Wi-Fi IP phone
Security conscious businesses and organizations who implemented 802.1x/EAP enterprise-grade authentication are at risk with certain implementations of wireless LAN VoIP handsets. I have verified that Vocera Communications is one of the vulnerable vendors and I have heard from other security researchers that Cisco's wireless VoIP handsets have this design flaw as well. I'm trying to get official responses from Vocera and Cisco. Based on the Vocera's own PDF documentation on page 55, we have the following admission.
PEAP is a two-part protocol. In the first part, an authentication server and a client set up an encrypted Transport Level Security (TLS) tunnel. The badge accepts a certificate from the authentication server, but does not validate it because of the processing overhead required.
From a security standpoint, this is a reckless design decision that undermines the whole purpose of using strong EAP authentication with asymmetric cryptography in the first place. By skipping the certificate checking process, it effectively reverts 802.1x PEAP authentication to the insecure level of Cisco's proprietary LEAP authentication. What this means is that a client (the wireless VoIP phone in this case) will assume that the wireless access point and its backend authentication infrastructure is authentic and not check its certificate for authenticity due to processing overhead.
By not validating the server certificate, the client's hashed password would be sent in the clear to an attacker trying to hack the network. Because the strength of hash passwords depend solely on the complexity and length of the password, hashed passwords typically can't withstand a password dictionary attack for more than a few hours. There are some EAP implementations where hashing isn't even used and in those cases the password would immediately be exposed as clear text under this attack. Once the password is cracked and the username is already known due to the fact that it was sent in the clear, an attacker not only has the means to enter a network but they have the user credentials to access all the servers and applications. From a security stand point, this is a worst case scenario. If Domain Admin passwords were compromised in this matter, then the keys to the kingdom would be compromised.
Temporary workarounds: Do not use 802.1x/EAP authentication on these vulnerable clients that don't perform certificate checks and use WPA-PSK on these vulnerable embedded devices. WPA-PSK mode is also much faster for these computationally-challenged embedded devices which cuts down on startup and roaming times. If you have to use LEAP, certificate-unverified PEAP, or certificate-unverified EAP-FAST mode, you have to assume that the password hash can be exposed to an attacker.
Note: LEAP makes zero effort to protect the hashed password since it is sent in the clear. Many implementations of EAP-FAST are fundamentally weak because they employ anonymous server certificates which can be made up by anyone. PEAP can be secure if it's implemented and deployed correctly where the digital certificate's signer and subject field (server name) are properly verified by the client.
If you still have to use these vulnerable clients in this vulnerable EAP implementation, then the password you use has to be a random 32-character alpha-numeric password to achieve roughly 128 bits of entropy. If 64 bits of entropy is enough, then a random 16 character alpha-numeric password will suffice. Special characters are not recommended since it might cause some compatibility problems with some wireless infrastructure or devices and the keypads on mobile devices may not be able to enter them.
If you're using WPA-PSK, you can reasonably use a random 10-16 character alpha-numeric PSK (Pre-Shared Key) passphrase because it's extremely time consuming and CPU intensive to run a dictionary attack against WPA-PSK. One downside to WPA-PSK is that every client uses the same PSK so if you lose one of those devices configured with the PSK, you have to re-key every client device. The other downside to WPA-PSK mode is that a compromised PSK allows the attacker to decrypt other WPA-PSK sessions that use the same key. There is a way to get around these two shortcomings by using Dynamic PSK mode from Ruckus which uses a very practical and effective per-client PSK, but that's only for the Ruckus products.
Conclusion: Until these design flaws in the client-side PEAP and EAP-FAST implementation are solved, users will not be able to use the reasonably short passwords that they currently use in authentication directories such as Active Directory or the short pins they use with their phones. Even if these flaws are fixed, the computational resources required for certificate validation may make these embedded devices too slow for roaming. Fortunately, the PMK caching and pre-authentication features in the WPA2 standard will permit seamless roaming if your infrastructure and clients support it.