|
|
This section covers the details needed for setting up WPA/WPA2 as securely as possible. Though all flavors of WPA are inherently more secure than WEP, there are precautions you can take to further minimize risk. The most significant decision is to use WPA2 with CCMP (AES-based encryption) as opposed to WPA with TKIP (RC4-based encryption). Though there are currently no practical attacks against the confidentiality or authentication features in TKIP, it never hurts to be ahead of the curve.
Usually, deciding on TKIP or CCMP is a no-brainer. If your hardware supports CCMP, use it. If not, fall back to TKIP until you can use CCMP. A more difficult question for some people is deciding between WPA-PSK or a full-blown enterprise authentication scheme complete with a RADIUS server.
Though the convenience of WPA-PSK tempts many organizations to use it instead of strong enterprise authentication, it really isn't a good idea. It's not that there is an inherent flaw in WPA-PSK that outsiders will be able to attack (assuming it's set up correctly to avoid dictionary attacks). One of the biggest problems is that technically adept insiders can decrypt each other's packets. Unless you trust all of your users to not read each other's mail, it's probably not a good idea to use WPA-PSK.
The other big problem with using WPA-PSK in a large organization is that as soon as an individual user compromises the key to an attacker (intentionally or not), all of the network traffic is the attacker's for the reading until the next key rotation. If you have a large enough organization, obtaining the key is not a very difficult task. All an attacker has to do is social engineer the key out of a single user or gain control of a machine on the network, and they have unfettered access until you change the key, which brings up the next issue-key rotation.
Key rotation in WPA-PSK is no easier than it is with static WEP keys. It stands to reason that many organizations will change the passphrase about as often as the WEP key (which is to say, almost never). Attackers know this, and many will devote significant resources to recovering the passphrase or PMK precisely because they know it won't be changed frequently.
Currently, the only attacks against the authentication or confidentiality of WPA-PSK are based on weak passphrases. Unlike WEP, where even truly random keys can be attacked and recovered, WPA-PSK will not betray its secrets so easily. A home user with a strong passphrase can sleep easy at night. Though it was already mentioned in the section on SSIDs, I will repeat it again: when using WPA-PSK, choose a unique SSID. Using a unique SSID prevents your network from being attacked using a precomputed WPA-PSK dictionary attack, a feature that is implemented in cowpatty.
Assuming you have a strong passphrase and a unique SSID, you are in good shape. The only thing you can try to do to improve security at the 802.11 layer is to change the passphrase periodically and use WPA2/CCMP if possible.
If your organization already uses a RADIUS server for authentication, then extending your current infrastructure to the wireless side should be straightforward. The only complication would be if you currently use some sort of weak EAP authentication type that doesn't perform mutual authentication, a requirement of WPA2/802.11i. Details of attacks and defenses against the major EAP authentication types are discussed in Chapter 7. Only a basic outline of EAP authentication types is discussed here.
EAP-TLS stands for EAP-Transport Layer Security. This authentication technique is conceptually straightforward. The server provides a certificate to the client, proving its identity to the user. The user then sends the server a certificate of his own. Assuming both sides can validate the certificates, a random number is generated and used to create the dynamic WPA PMK. The advantage of this technique is that the protocol itself is very secure and straightforward. The biggest disadvantage of EAP-TLS is that it requires extensive support for PKI inside the organization before it can be deployed.
LEAP (Lightweight EAP) is a proprietary authentication technique developed by Cisco. It is a basic username/password challenge-response protocol with serious flaws. Don't use LEAP unless you really have to for some reason. If you do need to use LEAP, make sure your users don't use dictionary words for passwords. For details on the problems with LEAP see Chapter 7.
PEAP (Protected EAP) and EAP-TTLS (EAP-Tunneled TLS) are two different EAP types with the same goal: to run any other EAP type inside an encrypted tunnel, allowing you to use a relatively insecure (but very convenient) challenge-response protocol inside a protected tunnel.
The biggest difference between PEAP and EAP-TTLS is that PEAP has stronger industry backing since Microsoft had a hand in designing it. Either one of these protocols can be deployed securely; however, there is a strong requirement on the client side to validate server certificates. This concern might seem like a small one (who wouldn't validate a certificate?), but in practice, ensuring clients aren't misconfigured can be difficult.
The 802.11i standard specifies some stringent requirements for EAP types to be used with 802.11i. In particular, the requirement that the specific EAP authentication type perform mutual authentication rules out EAP-MD5-Challenge and generic token-card support. Fortunately, you can use whatever type of authentication you want inside a PEAP tunnel (assuming you have client software that can do it).
If you are going to use PEAP to secure a weaker authentication type that is used elsewhere in your organization, you open yourself up to an advanced attack similar to the PEAP certificate validation attack discussed in Chapter 7. Though this possibility shouldn't necessarily dissuade you from using PEAP in this manner, you should read up on the details of the attack so you can make an accurate risk assessment.
|
|