Wireless LAN security guide Security for any organization large or small Author: George Ou Revision 2.0 - Jan 3, 2005

• Level 1: Home and SOHO WLAN security
• Level 2: Small Business WLAN security
• Level 3: Medium to large Enterprise WLAN security
• Level 4: Military grade maximum level WLAN security

Level 1: Home and SOHO WLAN security
Unfortunately, many home users are either using some old equipment, old drivers, or older operating systems that don't natively support WPA so they are still using WEP if anything at all.  WEP encryption was thought to be good for a week for most light traffic home wireless networks because the older WEP cracking tools needed 5 to 10 million packets to recover a WEP key, but the newest WEP cracking techniques can break WEP in minutes.  Even if there isn't that much traffic, the attacker now has ways to artificially generate traffic and accelerate WEP cracking.  Because of this, consumers should avoid any product that doesn't support WPA TKIP mode at a minimum but preferably WPA AES capable or WPA2 certified devices.  If they have WEP only devices, check with the vendor to see if there are any firmware and/or driver updates that will upgrade the device to WPA mode.  If not, anyone who cares about privacy should throw out those devices.  As harsh as that may sound, it is comforting to know that newer Access Points and Client Adapters that do support WPA can be purchased for as little as $30.  Client side Wireless LAN software (officially known as Supplicants) also need to be updated to support WPA or WPA2.  Windows XP SP1 with the WPA patch can suffice, but Windows XP SP2 is highly recommended.

The home or SOHO (Small Office Home Office) environment is very unlikely to have any kind of Authentication and PKI in place.  This may change when TinyPEAP gets launched, but that is currently in BETA phase and is not ready for prime time yet.  TinyPEAP puts a PEAP authentication server and PKI Certificate Authority in your home's Wi-Fi enabled Linksys Router which was once the exclusive domain of large organizations with dedicated authentication servers.  For the time being, the only viable option for this environment is WPA PSK (Wi-Fi Protected Access Pre-Shared Key) mode.  WPA mode mandates TKIP at a minimum but also has an optional AES encryption mode.  AES mode is highly recommended because it has a rock solid pedigree in cryptanalytic resistance whereas TKIP may be under attack in the near future.  Note that AES in WPA2 (fully ratified version of 802.11i) is no longer optional and is mandated today.  Since most home users would be lucky if all of their equipment and software was TKIP capable, most homes will have to be content with TKIP mode for now.

WPA PSK mode can be an effective security mechanism but leaves a lot to be desired in terms of usability.  This is because WPA PSK can be cracked with offline dictionary attacks so it relies on a strong random passphrase to be effective.  Unfortunately, humans are very bad at memorizing long random strings of characters and will almost always use simple to remember words and phrases or some slight variation of that.  This lends itself to dictionary attacks where a hacker will try every variation of every combination of words in the dictionary.  To make this very difficult to hack, use a 10 digit string of random characters comprised of a-z, A-Z, 0-9 or use a very long word phrase made up of 20 or more characters.  Unfortunately, this will force many users to write down their passphrases which in itself may lead to passphrase theft.  WPA PSK is not a good long term security solution and leaves Level 1 security with much to be desired, but it can be safe when used correctly.


Level 2: Small Business WLAN security
Small businesses must move beyond Level 1 by incorporating authentication in to their Wireless LAN access controls.  The standardized method for doing this is 802.1x and PEAP or TTLS authentication.  802.1x restricts access to the Datalink layer of a network by only permitting access to the network if a user proves their identity through the EAP (Extensible Authentication Protocol) mechanism.  There are many forms of EAP, but the two forms of EAP that is most appropriate for Level 2 security is PEAP (Protected EAP) and TTLS (Tunneled Transport Layer Security).  Note that PEAP in the general context refers to PEAP-EAP-MSCHAPv2 mode, which only requires a Server Side Digital Certificate and a Client Side Username/Password.  There are stronger forms of PEAP which we'll cover later in the higher security levels.  TTLS is actually a little better in security than PEAP-EAP-MSCHAPv2 because it does not divulge the username in clear text.  However, both forms of authentication do a good job of protecting passwords because the MSCHAPv2 password challenge session is protected inside an encrypted tunnel.  This is why PEAP or TTLS is so much better than Cisco's LEAP mechanism which transmits the MSCHAPv2 session in the clear lending itself to easy offline password dictionary cracking.

To implement PEAP or TTLS, the organization needs to implement a RADIUS Authentication Server.  There are many ways to do this no matter what your software preference is.  There are options for Microsoft Windows 2003 Server with IAS, 3rd party applications such as Funk Odyssey (needed for TTLS mode) that run on Windows, Open Source solutions with FreeRADIUS.  However, in order to run in PEAP or TTLS mode, the RADIUS server must have a server side x.509 digital certificate.  This certificate can be purchased from a 3rd party Certificate Authority such as Verisign, or it can be issued from an organization's internal Certificate Authority.  These two options are conventional wisdom but neither option is particularly appealing to small businesses since they won't like paying $500/year for a 3rd party Digital Certificate and they most likely don't have a PKI in place which requires a Certificate Authority server.  An excellent way to get around this problem is to use a Self Signed Certificate on your RADIUS server.  Self Signed Digital Certificates violates all best practice concepts for PKI, but I say be damned with them if the alternative is to use no Digital Certificates at all on your RADIUS server and run a completely vulnerable EAP mechanism such as LEAP.  Running a secure EAP mechanism such as PEAP or TTLS is too important to let PKI be an obstacle.  A newer protocol from Cisco called EAP-FAST promises to solve this problem by claiming that you don't need PKI and Digital Certificates but if you read the fine print from Cisco, that's clearly not the case.  Self Signed Certificates would solve the problem for PEAP, TTLS, or EAP-FAST for organizations too small to run a dedicated PKI Certificate Authority infrastructure.

The easiest method by far if you're a Microsoft Windows 2003 Server shop is to use the built in RADIUS server of Windows 2003 called IAS (Internet Authentication Server).  For a small business, there is nothing wrong with adding the IAS service to an existing Windows 2003 server even if it's their only server which also happens to be the Active Directory server.  You can either convert that server in to a Certificate Authority as well and grant yourself a digital certificate for the RADIUS server or simply Self Sign a digital certificate.  With this in place, the Root Certificate (the public key of the Digital Certificate) for the RADIUS server must be installed in all of the client's computers.  With Active Directory, this can be easily be pushed out via Group Policy.  All of the clients also need to configure their wireless settings on the WZC (Wireless Zero Configuration) service built in to Windows XP SP1 or SP2.  However, Active Directory allows you to configure this globally for all your users with Active Directory Group Policy.  Using the Microsoft method, a secure wireless network can be deployed throughout an organization big or small in hours.  If you don't have IAS, it comes with Windows 2003 Standard Edition which costs around $500 per copy.  IAS in my experience is extremely robust, reliable, and secure.

For those who wish to implement TTLS, they will need to either purchase Funk Software's Odyssey server (in the $2000 range) or implement FreeRADIUS on Linux which is Open Source.  Note that Windows does not have a built in TTLS client built in, you will need to purchase a wireless Supplicant (AKA Client software) for your end users.  MDC has an Open Source version for Linux, but you'll need to purchase one for Windows which is what most people are using.  You'll either need to implement the Root Certificate on the Clients manually or you'll need to purchase a 3rd party Digital Certificate which has its Root Certificate already preinstalled.  As for client side configuration, you'll need to find some other method to automate the installation process since Active Directory does not support the automation of 3rd party clients.

While 802.1x and PEAP or TTLS addresses the authentication half of the equation when it comes to security, encryption must also be addressed.  Up until recent months, it was thought that "Dynamic WEP" where WEP keys are rotated often (commonly 10 minutes) was considered to be "good enough" encryption.  With the next generation of WEP cryptanalysis tools, this is no longer the case and TKIP is the new bare minimum. The WPA standard implements TKIP which is a rewrite of the WEP protocol which will hold against current cryptanalysis techniques for now, but newer methods of attacking TKIP are on the horizon.  The reliable long term solution from the IEEE standards body is the 802.11i standard which mandates AES.  The recommendation for Level 2 through 3 is that you should be using WPA with TKIP at a minimum and upgrade to AES as soon as possible.  Note that some WPA devices already support AES encryption while all WPA2 certified devices must support AES encryption.  To be on the safe side, only buy products that support 802.11i and are WPA2 certified.

From a vulnerability standpoint, the only way to break this security level is to steal a user credential by either looking over someone's shoulders to see what password they are typing, coaxing them in to telling you what the password is (this is easier than you think), or installing a key logger on to a user's computer so you can record their key strokes as they type in the password.  Barring password theft, it would be far easier to break in to your premise and tap in to a Wired LAN than to attempt to crack Level 2 Wireless LAN security.  Level 2 is a good choice for most small businesses but organizations where security is a high priority should seriously consider the next two levels because a single lost password could compromise the entire system..


Level 3: Medium to large Enterprise WLAN security
Level 3 Wireless LAN security builds on the same principles of Level 2, but you're not allowed to use the "cheats" such as bolting on the RADIUS server on to an existing server or using Self Signed Digital Certificates.  PEAP-EAP-MSCHAPv2 is also disallowed because of its sole dependency on passwords which would be classified as "single factor" authentication.  EAP-TLS or PEAP-EAP-TLS using "soft" Digital Certificates (certificates that are stored on the user's hard drive) would be the recommended authentication method for this security level.  PEAP-EAP-TLS is an improved version of the original EAP-TLS protocol that goes further to encrypt client digital certificate information.  Both PEAP-EAP-TLS and EAP-TLS have the same server and client side digital certificate requirements, but PEAP-EAP-TLS may not be compatible with some older Supplicants (Client Software) or some non-Microsoft client side implementations.

To implement EAP-TLS or PEAP-EAP-TLS, not only does the server require a Digital Certificate but the users as well.  This means you will need a full blown Certificate Authority to issue a proper Server Digital Certificate on a pair of dedicated RADIUS servers and not just a Self Signed Certificate on a makeshift RADIUS Server.  For this security level, the proper PKI best practices should be followed.  There should be at least a single dedicated PKI Root Certificate Authority, but preferably it should at least be a 2 or 3 tier PKI design.  A two tier chain for a medium Enterprise organization would have an offline Root Certificate Authority and an online Issuing Certificate Authority.  A large Enterprise should implement the three tier design with offline Root Certificate Authority, offline subordinate Certificate Authority, and online Issuing Certificate Authority.  The reason for this is that if a Certificate Authority is ever compromised, you can revoke it and create a new one from the higher offline Certificate Authorities without having to start your PKI deployment from scratch.  Building a PKI from scratch because of a compromised Certificate Authority would be completely unacceptable in a large scale environment.

To deploy Digital Certificates to the user community, a PKI management infrastructure must be deployed and permanent human resources must be allocated to manage end user certificates if your user base numbers in the thousands or more.  Medium size Enterprises can add PKI management to their current hire/termination procedure.  Microsoft Active Directory with an Enterprise Root Certificate Authority (a PKI that is completely integrated in to an Active Directory) can issue digital certificates automatically, but be warned that this is not a substitute for proper management.  Lost or stolen laptops or terminated employees must have their digital certificates revoked and this is not an automatic process even if a user account is disabled or deleted.  After the certificates are revoked, they must be published in a CRL (Certificate Revocation List) and be applied to all Authentication servers or else the revoked certificates are still usable.  If Active Directory auto-enrollment is used, it is highly recommended that you do not just apply the policy to the entire domain by default so that everyone will automatically get a user digital certificate.  The policy should be set on just a particular OU (Organizational Unit) so that users who need user certificates and Wireless LAN access must be manually moved to that Certificate enabled OU.  Automatic enrollment should be used as a way to simplify management, not substitute management.

As for encryption, the same requirements and recommendations from the previous 2 levels applyl.  TKIP at a minimum but AES is recommended as soon as possible.  Level 3 organizations should probably be the first to jump to the next level of encryption.  The size of these organizations that would select Level 3 wireless LAN security can make upgrading difficult, but it's too important to ignore.  The good news is that once AES is achieved, it is expected to hold for some time.

From a vulnerability standpoint, Level 3 is reasonably secure.  The only way to compromise this security level is if the hacker can not only steal a user's password, but also steal that user's Digital Certificate which is much more difficult than just stealing a user's password.  To steal a "soft" Digital Certificate, either the laptop needs to be stolen in which case it would be obvious and the certificate could be revoked, or a malicious program like a backdoor, virus or worm would have to be installed on the laptop to "harvest" the private key of the digital certificate.  The latter option is much more sinister because a theft could occur totally undetected and the certificate would not be revoked.  The same malicious code could also "log" the user's keystrokes and the user's password would be compromised as well.  At this point, Level 3 security would be totally defeated hence the need for an even stronger solution in Level 4.  Discriminating Enterprises should seriously consider the next security level.


Level 4: Military grade maximum level WLAN security
Level 4 builds on Level 3 but aims to solve the key logging certificate stealing malicious code threat.  From a PKI Certificate Authority standpoint, not only is a 3 tier architecture required but the use of FIPS 140-2 Level 3 compliant HSMs (Hardware Security Modules AKA Cryptographic Modules for server side applications) are mandated.  These modules cost thousands of dollars in the form of a tamper resistant external module.  All Certificate Authorities should use one of these modules to ensure maximum security.  Even a malicious code compromise on the Root Certificate Authority cannot compromise the Root CA's private key although such a compromise on a Certificate Authority would still be very serious.  This is why the top two tiers of the PKI chain are never connected to the network as an extra precaution so that all interactions between the PKI tiers must be hand carried.

On the user side, the Digital Certificate cannot be stored on the hard drive so EAP-TLS or PEAP-EAP-TLS with "hard" tokens are mandatory.  The certificates must be stored inside an HSM (these are called Cryptographic Tokens on the client side) which are typically in the form of a USB dongle the size of two fingers carried on a person's key chain or a smartcard.  USB dongles are usually much more practical because they can be used by notebooks without a smartcard reader.  Some newer Notebook computers have a built in HSM called a TPM (Trusted Platform Module) but it can't be separated from the computer.  If an HSM empowered computer is infected with malicious code, the password can be logged and stolen but the digital certificate cannot.  This is because the HSM never divulges the private key of the digital certificate to its host computer because all asymmetric cryptographic operations happen inside the HSM and not on its host computer.  This makes it nearly impossible to steal a private key unless the TPM Notebook or USB dongle is physically stolen.  If that were to occur, it would be fairly obvious and the Digital Certificate stored inside the stolen HSM could be easily revoked by an administrator as part of the PKI management process.  To further enhance security, more expensive USB dongles and smartcards have built in finger print readers so that they are useless unless they have your living finger or they can figure out some extremely complex method of fooling the finger print reader.  But the biometrics portion is just a last defense meant to buy you enough time to revoke a certificate before unauthorized access is gained.  With biometrics enabled HSMs, you have the strongest 3-factor authentication system possible.

From an encryption standpoint, AES is the only encryption algorithm permitted for Level 4 and it also happens to be mandated for federal government and military applications.  AES was created by the NIST and its encryption algorithm was selected from a list of finalists that represented the best encryption algorithms in the world.  To comply with the AES requirement, 802.11i (AKA WPA2) compliant Wi-Fi gear is required on all Access Points, client Adapters, and software.  Most consumer Wi-Fi products sold do not support 802.11i while most newer business class Wi-Fi products do.  You'll have be look for the 802.11i or WPA2 logo on any Wi-Fi products you buy.  Many organizations may already own products that are AES compliant if they would simply update their firwares and drivers on their Access Points and Client Adapters.  Cisco products are a perfect example of this because it is probably the most dominant player in the enterprise Wireless LAN market yet most of their customers are not running the latest firmware.  Upgrades on such a large scale are very difficult but corporations cannot afford to put off good security because not only is it good business, it may be the law because of SOX and HIPAA compliance.

From a vulnerability standpoint, Level 4 is rock solid and extremely difficult to compromise.  The hacker would have to not only steal a user's password, but also physically steal that user's cryptographic token or a TPM notebook and take advantage of it before the user realizes anything wrong and reports the theft.  With 3-factor authentication, it is practically impossible to break in to the Wireless LAN from the wireless side.  The attacker will have to try some other means of compromising the network and a crowbar would be far more effective at that point.


Conclusion:
Contrary to popular belief, a Wireless LAN can indeed be secure.  Depending on the level of risk versus cost trade off you are willing to take, you will need to decide if you need to implement Level 1, 2, 3 or 4.  Fortunately, most of the security measures that you need to implement can also serve you in other aspects of IT infrastructure.  The same RADIUS, PKI, and Cryptographic Tokens can be used to secure your VPN and Remote Access solution.  PKI, Digital Certificates, and Cryptographic Modules are the fundamental building blocks of strong authentication and there is no way around that.  You can make the best of it by leveraging the hefty investment for all your security needs.

Comments