As many of us are going to wireless now I found this interesting article on the web. It can be viewed in the title link or just read below.
Wireless Security Blackpaper
Wednesday, July 17, 2002
Introduction
In 1999 the IEEE completed and approved the standard known as 802.11b, and WLANs were born. Finally, computer networks could achieve connectivity with a useable amount of bandwidth without being networked via a wall socket. Suddenly connecting multiple computers in a house to share an Internet connection or play LAN games no longer required expensive or ugly cabling. Business users could get up out of their chairs and sit in the sunshine while they worked. New generations of handheld devices allowed users access to stored data as they walked down the hall to a meeting. The dawn of networking elegance was upon us. Users could set their laptops down anywhere and instantly be granted access to all networking resources. This was, and is, the vision of wireless networks, and what they are capable of delivering.
Fast forward to today. While wireless networks have seen widespread adoption in the home user markets, widely reported and easily exploited holes in the standard security system have stunted wireless' deployment rate in enterprise environments. While many people don't know exactly what the weaknesses are, most have accepted the prevailing wisdom that wireless networks are inherently insecure and nothing can be done about it. Can wireless networks be deployed securely today? What exactly are the security holes in the current standard, and how do they work? Where is wireless security headed in the future? This article attempts to shed light on these questions and others about wireless networking security in an enterprise environment.
A few technical detailsWLAN networks exist in either infrastructure or ad hoc mode. Ad hoc networks have multiple wireless clients talking to each other as peers to share data among themselves without the aid of a central Access Point. An infrastructure WLAN consists of several clients talking to a central device called an Access Point (AP), which is usually connected to a wired network like the Internet or a corporate or home LAN. Because the most common implementation requiring security is infrastructure mode, most security measures center around this design, so securing an infrastructure mode wireless network will be the focus of this article. 802.11b specifies that radios talk on the unlicensed 2.4GHz band on one of 15 specific channels (in the US, we are limited to using only the first 11 of those 15 channels). Wireless network cards automatically search through these channels to find WLANs, so there is no need to configure client stations to specific channels. Once the NIC finds the correct channel, it begins talking to the Access Point. As long as all of the security settings on the client and AP match, communications across the AP can begin and the user can participate as part of the network.
Bandwidth on an 802.11b network is limited to 11Mb per access point. This 11Mb is divided among all users on that access point. If ten people access the same AP, communication to the wired world will be limited to approximately the equivalent of a decent DSL line. Because the 802.11b standard does not contain any specifications for load balancing across multiple access points, devices that strictly adhere to the standard have no answer if you find your network becoming over populated. The only way to manage this is to add another AP in the same area, but with a different network name and radio channel, effectively having more than one separate network (up to a maximum of three), in the exact same area. Some wireless vendors have proprietary solutions for load balancing, but discussing these initiatives falls outside the scope of this article. Interested readers should look into individual companies' propaganda documentation before they deploy their wireless network if they feel they will need these services.
Basic security: 802.11b's nod towards private communications and its weaknesses
From its inception the 802.11b standard was not meant to contain a comprehensive set of enterprise level security tools. Still, there are some basic security measures included in the standard which can be employed to help make a network more secure. With each security feature, the potential for making the network either more secure or more open to attack exists.
Service Set Identifier
The Service Set Identifier (SSID) is meant to differentiate networks from one another. Initially, AP's come set to a default depending on the manufacturer. For example, all Linksys AP's are set to the network name of 'linksys', while Cisco AP's are initially set to 'tsunami'. Because these default SSID's are so well known, not changing it makes your network much easier to detect. Another common mistake regarding the SSID is setting it to something meaningful such as the AP's location or department, or setting them to something easily guessable. The SSID should be created with the same rules as any strong password (long, non-meaningful strings of characters including letters, numbers and symbols).
By default the Access Point broadcasts the SSID every few seconds in what are known as 'Beacon Frames'. While this makes it easy for authorized users to find the correct network, it also makes it easy for unauthorized users to find the network name. This feature is what allows most wireless network detection software to find networks without having the SSID upfront.
SSID settings on your network should be considered the first level security, and should be treated as such. In its standards-adherent state, SSID may not offer any protection to who gains access to your network, but configuring your SSID to something not easily guessable can make it harder for intruders to know what exactly they are looking at.
Authentication type and WEPBefore any other communications take place between a wireless client and an AP, they must first begin a dialogue. This process is known as associating. When 802.11b was designed, the IEEE added a feature to allow networks to require authentication immediately after a device associates, before it attempts communications across the AP--supposedly providing an extra layer of keyed security. This feature can be set to either shared key authentication or open authentication. The simplest and default setting for this feature is open authentication. Using open authentication allows anyone to begin a conversation with the access point, and provides no security whatsoever on who can talk to the AP. When set to shared key mode the client begins by sending an association request to the AP. The AP then responds with a string of challenge text, which the client then encrypts using the WEP key (see below) and returns. If the text is encrypted correctly, the client is allowed to communicate with the AP, and move on to the next layer of security.
The weakness with this particular method is in the clear text transmission of the challenge string. By passively listening to the conversation, an attacker can obtain two of the three variables in the authentication equation; the clear text challenge string and what the challenge string looks like after it has been encrypted. By plugging these values into the RC4 equations, the attacker can easily solve for the shared authentication key. Furthermore, because the same keys are used for shared key authentication and WEP, when you use shared key authentication and it is compromised you have had your WEP keys compromised as well, meaning that an intruder could then decipher all traffic to and from the AP point and its clients. Ironically, the most secure setting of this feature is 'open authentication', allowing anyone to associate with your access points, and relying on other methods to handle security. While removing a layer of security may seem contradictory to making your network more secure, this particular layer is flawed and hurts far more than it helps.
WEPWired Equivalent Privacy (WEP) was intended to give wireless users security equivalent to being on a wired network. With WEP turned on each packet transmitted from one radio to another is first encrypted by taking the packet's data payload and a secret 40 bit number and passing them through a shredding machine called RC4. The resulting encrypted packet is then transmitted across the air waves. When the receiving station hears the packet it then uses the same 40 bit number to pass the encrypted data through RC4 backwards, resulting in the host receiving good, useable data.
There are several problems with WEP in its 802.11b ratified form that keep it from begin the definitive answer to wireless security. The main problem with WEP is that the RC4 stream cipher used to encrypt the data has been proven insecure. There are multiple attacks on the RC4 cipher revolving around a technological weakness in its encryption mechanism. RC4 combines the 40 bit WEP key with a 24 bit random number known as an Initialization Vector (IV) to encrypt the data. The packet sent over the airwaves contains the IV followed by the encrypted data. Unlike shared key authentication, the attacker does not know the unencrypted text beforehand, so he does not have enough variables to immediately figure out the WEP key.
The first attack uses a simple numerical limitation of the IV to figure out the WEP key. Because the IV is only 24 bits long, there are only so many permutations of the IV for RC4 to pick from. Mathematically there are only 16,777,216 (2^24) possible values for the IV. While that may seem like a lot, it takes so many packets to transmit useful data that 16 million packets can go by in hours on a heavily used network. Eventually the RC4 mechanism starts picking the same IVs over and over. By passively listening to the encrypted traffic, and picking the repeating IVs out of the data stream, an attacker can begin to infer what the WEP key is. Eventually enough data can be gathered that the WEP key is cracked.
The second attack based on the IV centers around what are known as Weak IVs. As discussed above, the encryption of a piece of data begins with RC4 choosing a random 24 bit number, and then combining that number with the WEP key to encrypt the data. Some numbers in the range of 0 to 16777215 do not work well in the RC4 encryption mechanism. When the RC4 algorithm picks out these 'Weak IVs', the resulting encrypted packet can be run through mathematical functions to reveal part of the WEP key. By capturing massive numbers of packets, an attacker can pick out enough Weak IVs to reveal the WEP key and compromise the network's security.
Another problem with WEP is key management. When you enable WEP according to the 802.11b standard, you have to visit each wireless device you will use and type in the proper WEP key. While this can initially be rolled into new client setup, if your key is compromised for any reason (employee leaves, someone gave it out over the phone, or you detected that someone guessed it) you have to change that key, or lose all security. This is not a big deal with only a few users, but what if you have an entire university campus or hundreds of corporate users on your network? In those scenarios changing the WEP key quickly becomes a logistical nightmare.
Above and beyond the standard: What else is available to secure my network?
One of the first attempts to address wireless network insecurity was developed by Lucent for their Orinoco WaveLAN brand of equipment. They developed what they called the 'Closed Network'. According to Lucent, their closed networks differed from standard 802.11b networks by having the AP's simply not periodically broadcast the SSID beacon frames. Recognizing that this feature turned the SSID from simply a way to identify networks into a legitimate security tool, many enterprise wireless AP vendors followed suit. Despite the fact that the SSID is still transmitted through the air in clear text, turning off the beacon frames means that finding other people's wireless networks requires a little more network savvy than simply pressing the Scan button repeatedly on your wireless client.
Even though turning this broadcast SSID feature off requires more management time (the user has to type the SSID into the client instead of clicking the Scan button), because most modern clients for 802.11b networks allow the users to manually type in the SSID, this is a fairly easy security measure to implement. It requires no special software to be loaded at the client other than what is already there, and only a little reconfiguration of the existing wireless clients is necessary. To avoid management nightmares in the future, your SSID should never change. This means that it will be compromised at some point, but there are other security measures to handle the intruders who manage to gain your SSID. While not a deterrent to serious, planned attacks on your wireless infrastructure, turning off the SSID broadcast can help defend your network against the casual war driver, preventing a large majority of attacks before they start.
Lucent also pioneered 128 bit WEP (they call it WEP Plus) . This extends the WEP key from 40 bits to 104 bits for added security. Using today's computing horsepower, this feature increases the time it takes to brute force crack a WEP key from a few days to approximately 20 weeks. While it seems like a good idea, there are several key areas where this security initiative falls short of the definitive security solution. On top of the management problems using static WEP keys there are two serious issues that plague 128 bit WEP. First of all, the attacks on WEP have nothing whatsoever to do with the key length itself. Whether you are using a 64 bit or 128 bit WEP you still have the exact same 24 bit IV which is the source of the weaknesses. This increases security absolutely zero for today's wireless implementations because no one bothers to brute force a WEP key when it is so easy to use one of the other attacks. Also, because this feature falls outside the standard for 802.11b, not all cards support it, and for those that do, the added burden of processing twice the encryption per frame can potentially drastically shrink useable bandwidth. It is true, though, that tomorrow's computers will have the capacity to crack a 40 bit key in a matter of minutes or seconds. Because of this, a move to 104 bit WEP keys will be a good idea in the future as long as you use other technologies to address WEP's shortcomings.
Broadcast key rotation is another method intended to help counter the flaws in WEP. In the 802.11b specification, there are two WEP keys. One key is meant to encrypt the individual stream of data between the AP and the wireless client, and the other is meant to encrypt broadcast transmissions such as DHCP or ARP requests. Because this key is usually the exact same as the static WEP key, this was never mentioned until Cisco introduced the idea of dynamically generated, short lived broadcast WEP keys in an early revision of its AP firmware. Although it was introduced by Cisco, other AP vendors have come to embrace this as a means to make the wireless network more secure. Like turning off the AP beacon frames, this feature requires no extra installation, and is easy to implement. The administrator sets a specific time, in seconds, on the AP, and every time the counter is up, the AP broadcasts a new broadcast WEP key, encrypting it with the old. Because these timeouts are usually set to ten minutes or so, there's not enough time for attackers to intercept the amount of packets needed to crack the key. While effective, this feature is only meant to secure broadcast communications, and must only be part of the overall security scheme.
MAC address filtering is another way that people have tried to secure their networks over and above the 802.11b standards. The MAC address of a network card is a 12 digit hexadecimal number that is unique to each and every network card in the world. Because each card has its own individual address, if you limit access to the AP to only those MAC addresses of authorized devices, you can easily shut out everyone who should not be on your network. Or at least that is the idea. There are several problems with MAC address filtering that prevent it from offering a totally secure network.
The first problem with MAC address filtering is the management aspect of it. When turned on, the wireless LAN administrator must keep a database of every device allowed to access the network. This database must be kept either on each AP individually, or on a special RADIUS server that each AP looks at. Any time a device is added, lost, stolen, or changed in any way the WLAN administrator must update the database(s) of allowed devices. While this is not too terrible of a burden for ten or even twenty people, in an enterprise network with hundreds or thousands of devices this is simply not a practical solution. It would require a full time employee just to keep up with the database changes.
The management nightmare might be considered a worthy price if MAC address filtering were 100% secure. That, however, is not the case. MAC address filtering is easy to defeat for someone who has the right tools. Using a wireless sniffer an attacker can watch the wireless traffic of your network and easily pick MAC addresses of valid users out of the frames floating through the air, even if they are encrypted. Then they can simply modify the MAC address their OS sends out to mimic one of the stolen ones and your security is beaten. Once your MAC address security is compromised you are still forced to deal with the management nightmare while gaining none of the benefits.
For smaller wireless implementations MAC address filtering might be considered as a viable option if nothing else is available, since the management aspect is not as difficult to deal with. For larger wireless networks, however, MAC address filtering simply does not offer the level of security that might justify its enormous management overhead.
Alternative Encryption Schemes: Targeting the weaknesses in static WEP
For a long time, most people considered VPN as the definitive solution for handling wireless security. The idea behind this security measure is to consider the wireless network equivalent to the Internet. Companies use a firewall device at the point where their network connects to the Internet, and only allow users in via an encrypted, secure channel. The same idea applies to their wireless networks. Using the VPN solution, all wireless network traffic is segmented behind a firewall. Each client is then configured with a VPN client and tunneled over the wireless network to a VPN concentrator on the wired network. This security setup uses a secure, proven technology to prevent outsiders from gaining access to your wired network. Also it reuses a technology many companies have already deployed, so there is very little added expense in those cases.
There are a few weaknesses with this setup however. The process of gaining legitimate access to a wireless network begins with the client booting up and getting an IP. Once the client has an IP, through either static addresses or more commonly DHCP, the client can then negotiate a tunnel over the wireless network to begin its communications. Illegitimate users go through the exact same process, except that they do not gain direct access to the wired network. Because the attacker has been given an IP, though, there is nothing preventing him from communicating with other wireless clients on their side of the firewall. By communicating with other wireless clients the attacker has the possibility of breaking into an authorized user and gaining access through their client. It is possible to prevent this by allowing the wireless user to only communicate with the VPN concentrator point, but that feature is available in only some of the VPN clients out there. The added burden of having to lock down each client as well as the wireless-to-wired network connection makes this a more difficult situation to implement than it might seem on the surface.
Even if you do manage to lock down the clients on your network and prevent them from accessing the wired network at all, you are still handing out IP's to anyone who asks. This means that it is possible for unauthorized wireless users to piggyback your wireless connection to communicate to other non-VPN clients on the same network segment. This means that Joe Cracker and Suzy Cracker can communicate with each other across your campus, but not your other internal networks. Because network bandwidth is shared on a wireless connection and there is only currently 11Mbits to go around, this type of piggybacking can cause extreme performance hits on your wireless network, and deny legitimate users the bandwidth they need for their applications.
VPN solutions can be an effective way of preventing unauthorized users from gaining entry to your wired network as long as they are implemented correctly. There are other concerns though which might make a wireless administrator think twice about implementing it.
802.1X is a standard which was ratified in early April by the IEEE regarding port level security. Initially it was intended to standardize security on wired network ports, but it was found to be very much applicable to wireless networking as well. This new layer 2 (MAC address layer) security protocol exists at the authentication stage of the security process. Using 802.1X, when a device requests access to the AP, the AP demands a set of credentials. The user then supplies some form of credentials which the AP then forwards to a standard RADIUS server for authentication and authorization. RADIUS stands for Remote Authentication Dial-In User Service, and is commonly used to authenticate dial-in users. The exact method of supplying credentials is defined in the 802.1X standard EAP (Extensible Authentication Protocol). EAP is an authentication "bucket" that allows developers to create their own methods of passing credentials and is the main security measure in 802.1X. There are four commonly used EAP methods in use today. They are EAP-MD5, EAP-Cisco Wireless (also known as LEAP), EAP-TLS, and EAP-TTLS.
EAP-MD5 relies on an MD5 hash of a username and password to pass credentials to the RADIUS server. EAP-MD5 offers no key management or dynamic key generation, requiring the use of static WEP keys. This prevents unauthorized users from accessing your wireless network directly, but offers nothing over the proven insecure static WEP encryption scheme. Attackers can still sniff your airborne traffic and decrypt the WEP key. Once the key is decrypted they can easily watch all data running over your wireless network. Another flaw in EAP-MD5 is that it offers no way for the wireless client to verify the AP. Because of this, a determined attacker could plant a rogue AP on your network and fool your wireless clients into thinking that it is a secure communications point. Because it offers no other features over the standard 802.1X, EAP-MD5 is considered the least secure of all the common EAP standards.
EAP-Cisco Wireless, or LEAP, is a standard developed by Cisco in conjunction with the 802.1X standard, and is the basis for much of the ratified version of EAP. Like EAP-MD5, LEAP accepts a username and password from the wireless device and transmits them to the RADIUS server for authentication. What sets LEAP apart from EAP-MD5 are the extra features it adds over what is explicitly called for within the 802.1X/EAP specification. When LEAP authenticates the user, one time WEP keys are dynamically generated for that session. This means that every user on your wireless network is using a different WEP key that no one knows, not even the user. Also, you can combine this with the session timeout feature of RADIUS to have the user re-login every few minutes (handled behind the scenes, the user doesn't have to type anything in) and create new dynamic WEP keys that change every few minutes. Setting your RADIUS server up this way effectively nullifies current attacks on WEP because the individual keys are not used long enough for an attacker to crack them. LEAP also stipulates mutual authentication of client-to-AP and AP-to-client above what 802.1X strictly calls for. This prevents a hacker from inserting a rogue AP into your network and fooling your wireless clients into thinking it is a secure connection. There are presently two drawbacks to running LEAP. First, the mechanism of passing the logon credentials uses MS-CHAPv1 for both the client and AP authentication. This version of MS-CHAP has known vulnerabilities, and can be compromised by a determined enough attacker with the right tools. There are no known instances of LEAP being compromised by this, but MS-CHAPv1 is a weakness. The second drawback in implementing LEAP is that LEAP currently only works on Cisco end-to-end networks, because only Cisco has added LEAP capabilities to their wireless client. Other vendors, however, are working to add LEAP to their wireless client software to allow non-Cisco network cards in established LEAP implementations.
EAP-TLS was developed by Microsoft, and is outlined in RFC 2716 . Instead of username/password combinations, EAP-TLS uses X.509 certificates to handle authentication. EAP-TLS relies on Transport Layer Security, the IETF's attempt at standardizing the Secure Sockets Layer (SSL) to pass PKI information in the EAP bucket. Like LEAP, EAP-TLS offers dynamic one-time WEP key generation, and authenticates the AP to the wireless client as well as the client to the AP. EAP-TLS runs on any platform that has a client written for it. Currently clients for EAP-TLS are implemented through several vendors for Linux and all flavors of Windows (except CE). The first hindrance to implementing EAP-TLS is in the burden of PKI. If your organization does not already have a PKI in place handing out certificates to trusted parties there is a potentially steep learning curve in figuring out exactly what PKI is and how to implement it. Once you get the PKI services installed and implemented, handing out certificates is not too much of a burden. The main impedance to EAP-TLS right now is the general confusion surrounding exactly how to do it. The only way to currently easily deploy EAP-TLS is if you are in an Active Directory (AD) using a Microsoft Certificate Server with wireless clients that only log into the AD, and all your certificates are published to the user accounts in the AD. Problems crop up when you want to change any part of that. If you are using some other directory service such as Open LDAP or NDS, then you can't publish the certificates to the user accounts, and the RADIUS server has no standards-based way to tell if the certificate you are passing it is a valid one for the account you send it. If you want to use some other certificate server you run into issues between the EAP-TLS standard as written and the interpretation of the X.509 standard for certificates. There is an optional field called "Extended Key Usage" that exists in all Microsoft certificates. This field is used to determine what the certificate is used for. Either mail signing, code signing, or user authentication. In a Microsoft Certificate Services certificate, that field always exists and, if you use the certificate for all purposes it contains every value. If you are using a Verisign issued certificate for every purpose that optional field doesn't exist at all. Since EAP-TLS looks for a specific value in that field, if you have a general Verisign certificate you can't use it. If your wireless client doesn't log into the Active Directory, then the Certificate Services will not issue it a certificate at all.See, confusion. Unless your organization can take The Microsoft Wayô document straight from MS and implement it just how they have it, EAP-TLS should be considered a work in progress, and not quite ready for primetime. Currently there are vendors working to address these confusing issues, however, and in the next few months TLS should be ready for the spotlight.
EAP-TTLS was pioneered by Funk Software as an alternative to EAP-TLS. The AP still identifies itself to the client with a server certificate, but the users now send their credentials in username/password form. EAP-TTLS then passes the credentials in any number of administrator specified challenge-response mechanisms (PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PAP/Token Card, or EAP). The only challenges to EAP-TTLS are the slightly less secure than dual certificates of EAP-TLS, and the upcoming standard developed by Microsoft and Cisco that works exactly the same way called Protected EAP (PEAP).
Advanced implementation and conclusionTo implement 802.1X in your wireless deployment, you have to do some research and be prepared to mix and match vendors' offerings depending on what EAP protocol you plan to use. First you have to pick a RADIUS server to handle the credential verification. Presently there are four different RADIUS servers which can handle some or all of the EAP standards:
Microsoft's Internet Authentication Service (IAS)
is part of Windows 2000, and can authenticate both EAP-TLS and EAP-MD5. If you own a copy of Windows 2000 Server, you already have this RADIUS server, and can access it through Add/Remove Programs from the Control Panel.
Cisco's Access Control Software (ACS) was developed for both the UNIX and Windows platforms. It is a full fledged TACACS+ and RADIUS server and, beginning with version 2.6a, it handles wireless authentication with EAP-Cisco Wireless and EAP-TLS.
Funk Software is generally known for their product called Steel Belted RADIUS. The have a stripped down version of that platform known as Odyssey which handles wireless authentication exclusively. Odyssey handles the widest range of EAP types by supporting all four of the commonly used protocols, EAP-MD5, EAP-TLS, EAP-Cisco Wireless, and EAP-TTLS.
AEGIS from Meetinghouse Data offers a RADIUS server that runs on the Linux platform and handles EAP-TTLS and EAP-TLS authentication.
FreeRadius is an open source project that runs on the Linux platform. FreeRADIUS supports both EAP-MD5 and EAP-TLS.
The second piece needed to implement 802.1X is an AP capable of passing the authentication messages. Because the AP acts only as a conduit for the authentication messages, there are no compatibility issues between certain AP's and different EAP protocols. As long as the EAP protocol fits the standard, then an 802.1X enabled AP can use it. Generally all enterprise level AP's are either currently capable of handling 802.1X requests either out of the box or through a firmware upgrade for existing equipment. If you have a much smaller environment, or just don't want to spend the money on enterprise class AP's, there are hacks available for home user level AP's to support 802.1X authentication. [Editor's Note - You can find a full walkthrough on hacking an Orinoco RG-1100 to accept 802.1X in the Networking Matrix . Azariah did an excellent job writing it up, and it's really a bargain for a secure wireless setup.]
The final piece of the 802.1X puzzle is the client software. Again, depending on your OS and preferred EAP standard there are several to choose from.
Cisco writes its ACU client piece to make its adapters work with EAP-Cisco Wireless on all flavors of Windows, Apple, and Linux.
Windows XP has a built-in client for EAP-TLS and EAP-MD5. It only works properly with Microsoft issued certificates though. This client is supposed to be released for Windows 2000 and CE.NET as well.
Funk's Odyssey client currently works on all flavors of Windows except CE. Linux, CE and Apple versions are all due out in the next few of months. The Odyssey client handles EAP-MD5, EAP-TLS and EAP-TTLS, and will soon offer EAP-Cisco Wireless support for non-Cisco hardware.
The AEGIS client from Meetinghouse Data offers EAP-TLS, EAP-TTLS, and EAP-MD5 support for all flavors of Windows (except CE) and Linux.
Several open source clients are being worked on currently, most notably Xsupplicant from the open1X project .
Conclusion
What exactly do I need to do to secure my network right now?
If possible, put the wireless network behind its own routed interface so you can shut it off if necessary.
Pick a random SSID that gives nothing about your network away.
Set your AP to 'Closed Network'
Set the authentication method to 'Open'
Have your broadcast keys rotate every ten minutes or less
Use 802.1X for key management and authentication
Look over the available EAP protocols and decide which is right for your environment.
Set the session to time out every ten minutes or less.
Where is the future of wireless security headed? Spurred by the insecurities and management issues exposed with WEP as it was standardized in 802.11b, the IEEE formed Task Force 802.11i to write a good standard for wireless security. The 802.11i standard is a work in progress, but enough has been done to figure out what much of it will be. Wireless implementations are divided into two groups, legacy and new. Legacy networks are those which were put in place before the .11i standard was ratified, and new networks are those put in place after it is ratified. Both groups use 802.1X as the means of handling credential verification, but the encryption method differs. 802.11i also specifies that only EAP standards which handle dynamic key generation may be used.
To conform to 802.11i legacy networks will be required to use 104 bit WEP, and also use Temporal Key Integrity Protocol (TKIP, formerly known as WEP2) and Message Integrity Check (MIC). Both of these technologies were developed by Cisco as proprietary means of strengthening WEP. Though they are available today, these are only available on all Cisco networks, and then not on all platforms. TKIP addresses the IV attacks on WEP by encrypting everything before it is run through the WEP machine, essentially adding another layer of encryption to the packet. MIC adds stronger integrity checking than a simple CRC check to prevent attackers from changing messages after transmission.
According to 802.11i new wireless networks will be the same as legacy, except they should replace WEP/TKIP with a new encryption scheme called Advanced Encryption Standard - Operation Cipher Block (AES-OCB). This new encryption standard is a version of the AES standard recently adopted by the U.S. government as the replacement for 3DES. AES-OCB is touted as being much stronger than WEP/TKIP.
References
"Your 802.11 Wireless Network Has no Clothes", William A. Arbaugh, Narendar Shankar, Y.C. Justing Wan. 2001
"Intercepting Mobile Communications: The Insecurity of 802.1", Nikita Borisov, Ian Goldberg, David Wagner. 2001
"Weaknesses in the Key Scheduling Algorithm of RC4", Scott Fluhrer, Itsik Mantin, Adi Shamir. 2001
"Wireless LAN Security: A Short History", Matthew Gast. 2002
