Although 802.11b APs generate a theoretical maximum of 11 Mbps, its observed rates are usually much less due to overhead and packet collisions, which can increase the amount of time before an IV is reused. However, packets are usually not at the Ethernet maximum of 1500 bytes, which reduces the IV reuse. In any event, this small space of IVs guarantees that a key stream will be reused in less than half of one day.

The importance of this relatively small time is that an attacker can collect two ciphertext packets that are encrypted with the same key stream. Then the attacker can perform statistical attacks to recover the plaintext, and once he has positively matched a ciphertext message with its plaintext counterpart , then an XOR operation will reveal the key, enabling him to comprehend all other ciphertext messages. Hence, it is fruitful for the passive eavesdropper to intercept all wireless traffic until an IV collision is observed.

Even if the threat cannot understand all the contents, the attacker can infer them by exploiting the predictable nature and redundancy of IP traffic. Further educated guesses about the contents of a plaintext message also allow the threat to statistically diminish the space of possible messages to get a clear idea of the exact contents. As the attacker ascertains more collisions using the same IV, the attacker can get an even better understanding of the concealed messages, facilitating the success rate of statistical analysis.

A variation of this attack is to use a host to send traffic from outside the WLAN to the AP. Because the attacker knows the plaintext (which he fabricated), he has everything necessary to recover the crucial key stream once he taps its ciphertext from the air.

Active Attack to Insert Traffic The problems from the attack mentioned previously can be worsened. If an attacker knows the precise plain- text and ciphertext pair, he would manifestly be able to generate the key stream. With this knowledge, the threat can build correctly encrypted packets by constructing a message, calculating its CRC-32, and executing an XOR operation with the newly discovered key stream. This ciphertext packet can be sent to the AP or mobile station to deceive it into thinking that it is a valid packet.

A minor modification to this attack can make it much more pernicious. Even if the attacker has not attained complete knowledge of the packet, he can alter selected bits of the message and successfully adjust the encrypted ICV to obtain a correct encrypted version of the modified packet. This is a lethal attack of the packet’s integrity, since all the attacker requires is partial knowledge of the packet’s contents to perform selective modification.

Active Attack from Both Ends The previous active attack can be extended even further to decrypt arbitrary traffic. Suppose the attacker speculates about the frame’s header only, not necessarily its actual contents. For example, he may be able to predict the destination IP address with a high degree of confidence. Equipped with just this information, the attacker can modify appropriate bits to transform the destination IP address to send the packet to a machine in his control via a rogue mobile station. Then the packet could be successfully decrypted by the AP and forwarded as plaintext to the attacker’s machine.

Even if the AP is positioned behind a firewall, once the attacker can deduce the Transmission Control Protocol (TCP) headers of the packet, he can change it to port 80 ( generally indicating World Wide Web service), thereby allowing it to be forwarded after decryption through most firewalls and to his machine somewhere on the Internet.

Table-based Attack The small space of potential IVs can allow an attacker to construct a decryption table. Once the plaintext of a packet is realized, an attacker can compute the key stream produced by the IV utilized. Accordingly, this key stream can be used to decrypt all other packets employing the same IV. Eventually, the threat can generate a table of IVs and corresponding key streams. Then the black hat can decrypt any and all packets sent over the wireless link, regardless of their IVs.

Because the table can contain up to 2 ^[24] (over 16 million) values, and each entry is a maximum of 1500 bytes, the table will be no larger than 24 GB. Thus, it is conceivable that a committed attacker can accumulate enough data to build a full decryption “dictionary.” Although this would be an arduous undertaking, his motivation is that once the table is formed , it is possible to immediately decrypt every subsequent ciphertext with little effort. Worse yet, this table can be distributed to other black hats. The flaw here is in the 24-bit IV; if the IV is expanded in a future version of WEP, constructing such a dictionary would be exponentially more laborious.

Workarounds A number of workarounds are being tested to make WLANs secure (see the following box).

Adam Stubblefield, John Ioannidis, and Aviel D. Rubin implemented an attack against the WEP, the link-layer security protocol for 802.11 networks. Fluhrer, Mantin, and Shamir also described the attack in a paper of their own. They were able to recover the 128-bit secret key used in a production network with a passive attack. The WEP standard uses RC4 IVs improperly, and the attack exploits this design failure. They conclude that 802.11 WEP is totally insecure, and we provide some recommendations. ^[7]

Stubblefield et al. were able to implement the attack described by Fluhrer et al. in several hours. According to the authors, it took a few days to figure out which tools to use and what equipment to buy to successfully read keys off of 802.11 wireless networks. The attack used off-the-shelf hardware and software, and the only piece the authors provided was the implementation of the RC4 attack, along with some optimizations. Stubblefield et al. have demonstrated the ultimate break of WEP, which is the recovery of the secret key by the observation of traffic. Given this attack, 802.11 networks should be viewed as insecure.

Stubblefield et al. recommend the following for people using such wireless networks:

• Assume that the link layer offers no security.

• Use higher-level security mechanisms such as IP Security (IPSec) ^[12] and Secure Shell (SSH) ^[13] for security, instead of relying on WEP.

• Treat all systems that are connected via 802.11 as external. Place all APs outside the firewall.

• Assume that anyone within the physical range can communicate on the network as a valid user . Keep in mind that an adversary may utilize a sophisticated antenna with a much longer range than found on a typical 802.11 PC card.

Wireless systems that rely on a 64-bit key (used in many homes and in the original WLAN hardware) can be broken in 60 seconds or less. The original choice of encryption by the IEEE 802.11 group may also be related to U.S. export law restrictions. ^[14] In the United States, vendors are advancing proprietary 128-bit solutions. Although this may provide stronger encryption security, it impacts interoperability with equipment from different vendors . Also, poorly chosen passwords can still be cracked with an old technique known as a dictionary attack: using a list of common passwords and a dictionary of words, the potential intruder can try various combinations until the password is broken. ^[15]

Some stakeholders are working on upgrading WEP to a WEP2 version that separates encryption and authentication functions in such a manner that the same static key does not need to be shared within a WLAN. ^[16] Recognizing that WEP2 will not be the WLAN’s final security solution, the IEEE 802.11 group has approved a draft to establish a stronger authentication and 128-bit key management system, tentatively called the Enhanced Security Network (ESN). ESN’s encryption will augment the RC4 PRNG algorithm with the Advanced Encryption Standard (AES). ^[17] ESN is expected to be finalized in 2002. Security work is going on both in IEEE 802.11e and 802.11i.

In the meantime, security experts recommend the deployment of multiple security measures. For example, the recommendation is to place the WLAN outside the firewall and to run a virtual private network (VPN) inside the firewall. The Remote Access Dial-In User Service (RADIUS) protocol can be implemented to provide another level of security designed to authenticate remote clients to a centralized server. ^[18]

Summary of the Issue and Planned Fixes

Summarizing the previous discussion, the vulnerabilities exposed in WEP can be traced back to two problems in the standard: ^[19] (1) the limitations of the IV combined with (2) the use of static WEP keys where the odds of collisions are very high. IV collisions produce so-called “weak” WEP keys when the same IV is used with the same WEP key on more than one data frame. When a number of these weak keys can be analyzed , WEP can be attacked to expose the shared secret. Some early reports inferred that the stream cipher used for WEP encryption, RC4, was the weakness. But this turned out not the case: the vulnerabilities exposed in WEP can be traced back to the way the initialization vector and the WEP key are combined to get a per-packet RC4 key.

Some IVs produce weak RC4 keys that leak information on the WEP key. Free tools (or scripts) like AirSnort and WEPCrack have appeared on the Internet that anyone can use to attack WEP. AirSnort authors claim their code can capture WEP keys after gathering information from just 2,000 packets with weak keys. It is estimated that out of 16 million keys generated using 128-bit WEP encryption, 3,000 are weak. (Keep in mind that 802.11b actually calls for the use of 40-bit WEP encryption, which is even more vulnerable. Many vendors are going one step ahead of the spec and providing 128-bit WEP encryption in their products today, but even this tighter security is vulnerable to the new tools.) Network sniffers like AirSnort analyze the weak keys to discover the shared secret between wireless clients and APs. Once the shared secret is discovered, a malicious attacker would have access to the WLAN network and be able to go back and decrypt data packets being passed on the exposed network.

In a public statement responding to the weakness discovered in WEP, Ron Rivest, inventor of the RC4 algorithm, recommends that “users consider strengthening the key scheduling algorithm by preprocessing the base key and any counter or initialization vector by passing them through a hash function such as MD5. Alternatively, weaknesses in the key scheduling algorithm can be prevented by discarding the first 256 output bytes of the pseudo-random generator before beginning encryption. Either or both of these techniques suffice to defeat the Fluhrer, Mantin, and Shamir attacks on WEP and WEP2.”

Network security is only as strong as the authentication system it is based on. Proper authentication techniques thwart popular attacks like the man-in-the-middle and denial of service attacks. In the current 802.11b standard, turning WEP on allows client authentication to take place via a password-based system, but leaves the system vulnerable to the attacks described earlier. What’s worse is that no mechanism for AP authentication is identified.

The Protected Extensible Authentication Protocol (EAP) in the new 802.1X standard improves the authentication mechanisms in 802.11 standards like 802.11b or 802.11a (the standard was introduced by RSA Security, Cisco, and Microsoft). The standard solves three key problems:

• It protects the network from rogue APs being introduced.

• It outlines a way users can strongly authenticate themselves to the AP using a variety of popularly used authentication methods .

• It allows users to strongly authenticate themselves while roaming between the separate AP that make up a network’s WLAN.

The Protected EAP proposal calls for EAP to be used in combination with the Transport Layer Security (TLS) protocol. Both EAP and TLS are popularly used Internet Engineering Task Force (IETF) standards on the Inter- net. The combination of the two protocols results in client and server authentication that protects the WLAN network against passive eavesdroppers.

Protected EAP works in two phases. A TLS phase authenticates APs using an encrypted tunnel to protect authentication information being exchanged, even when users are roaming between different APs. Next , an EAP phase authenticates the users of wireless clients.

Phase One A TLS handshake (see Figure 4-1) is used to authenticate the AP to the wireless client. First, the wireless client sends a message to a backend server announcing that it is connected to the wireless AP. The message tells the server that a new connection should be initiated, and it also tells which cryptographic algorithms the client understands so that secure messages sent between the two can be understood .

Figure 4-1: TLS handshake

After receiving this message, the backend server responds with a new session ID, a list of algorithms that will be used to correspond , and a public key certificate that enables the client to trust the AP it has used to establish the connection to the network. The wireless client verifies the signature and validity of the server certificate and then responds by generating a secret key and encrypting it with the public key obtained from the server certificate. This protected information is sent back to the server and, if the server is able to decrypt this information, it is authenticated: only the server’s private key would be able to decrypt messages encrypted with its public key. After this last exchange, authentication of the AP is complete and a secure TLS session is established to protect the user authentication credentials that will be passed in phase two.

Phase Two An added layer of protection is provided in the second phase of Protected EAP through the use of EAP, which is able to strongly authenticate the end user of the wireless client by challenging the user with a suitable EAP mechanism (see Figure 4-2). Suitable EAP mechanisms include the use of passwords, smart cards, digital certificates, or time-synchronous tokens like the RSA SecurID token, which produces one-time passcode challenges. The EAP challenges are passed to backend authentication servers connected to the wireless APs sitting on a company’s WLAN. The versatility here is really the key, because EAP enables enterprises to continue to use any appropriate EAP method already deployed to their employees and extend its use to the WLAN.

Figure 4-2: Protected EAP authentication phase

The real benefit will be felt by users who are roaming within a corporation’s WLAN and require a seamless connection. Users want mobility and convenience. If they are asked to authenticate themselves each time they pass from one conference room to another, they will want to give up security in favor of convenience, and that is the reason for choosing TLS for Protected EAP in the 802.1X standard (see “Moving Forward”). Using the connection reestablishment mechanism provided in the TLS handshake enables users to have one seamless connection while roaming between different APs connected to the same backend server. If the session ID is still valid, the wireless client and server can share old secrets to negotiate a new handshake and keep the connection alive and secure (see Figure 4-3).

Figure 4-3: Roaming in protected EAP

Moving Forward Moving forward, one can expect 802.1X to be adopted into a variety of 802.11 standards such as 802.11a, which is good news from a security perspective, because products being built today can use 802.1X. These products will offer advantages to enterprises by enabling them to take the same strong authentication solutions currently deployed in enterprises and use them with WLAN products. In addition, implementing 802.1X in WLAN products will offer the advantage of enabling users to roam more conveniently and securely. It is a long- term fix to solve user and AP authentication in a roaming environment.

On the encryption side, Task Group I is working out a solution to fix WEP for the long term. Vendors are following up with announcements about how they plan to incorporate the merits of the Task Group’s work into a quick fix for WEP to clean up the issue in all of the 802.11b hardware currently deployed.

For the longer-term solution, Task Group I work may roll into an 802.11i standard that will eventually replace 802.11b. It seems logical to draw the conclusion that Task Group I’s work will also be incorporated into the 802.11a standard to secure WLAN products that will be capable of offering higher bandwidth to users sometime in 2003. Vendors working with 802.11a should also start evaluating the Protected EAP proposal in the 802.1X standard right away.

802.1X: Port-based Network Access Control

Authentication as defined in the IEEE 802.11 standard is focused more on WLAN connectivity than on verifying station identity. For WLAN systems to scale to a large number of users, the current method of authentication must be replaced with an authentication framework that supports centralized user authentication. As just noted, Task Group I of the IEEE 802.11 committee recently developed 802.1X, an IEEE standard that provides an authentication framework for 802-based LANs.

IEEE 802.1X is a standard drafted by the IEEE that is designed to provide enhanced security for users of 802.11b WLANs. 802.1X is a supplement to ISO/IEC 15802-3:1998 (IEEE standard 802.1D-1998) that defines the changes necessary to the operation of a MAC bridge in order to provide port-based network access control capability. The activity was launched in early 2000 and by January 2002 Draft 11 incorporated comments received from the industry. 802.1aa-802.1X Maintenance is an amendment to IEEE standard 802.1X-2001 and is intended to document maintenance items identified in the text of IEEE standard 802.1X-2001.

The standard provides port-level authentication for any wired or wireless Ethernet client system. IEEE 802.1X was originally designed as a standard for wired Ethernet, but is applicable to WLANs. It leverages many of the security features used with dial-up networking. ^[20] When 802.1X is applied to 802.11 networks, it has the potential to simplify security management for WLAN environments; however, it is only one element of the security layers needed in WLANs. When it is coupled with an authentication algorithm and data frame encryption, it can support scalable, manageable, and mobile network services.

IEEE 802.1X is a port-based authentication protocol , but it can be used in any scenario where one can define any abstract notion of a port. It requires entities to play three roles in the authentication process: a supplicant, an authenticator, and an authentication server. Figure 4-4 recapitulates the basic scenario. ^[21] A port access entity (PAE) is an entity that has access or is capable of gaining or controlling access to some port that offers some services.

Figure 4-4: The setup using the IEEE 802.1X port- based authentication mechanism

As noted in the previous section, WLANs based on the 802.11 standards have come under intense scrutiny as their security based on WEP has been found to be unreliable. The new 802.1X has a key management protocol built into its specification that provides keys automatically. Keys can also be changed rapidly at set intervals. ^[20] 802.1X takes advantage of EAP. ^{[22 ]} 802.1X takes EAP, which is written around PPP, and ties it to the physical medium, be it Ethernet or WLAN. EAP messages are encapsulated in 802.1X messages and referred to as EAP over LAN (EAPOL). ^[23] It should be noted that 802.1X alone lacks the components that 802.11-based LANs need for user-based authentication. Task Group I was in the process of drafting amendments to the 802.11 specifications at press time to incorporate 802.1X services. Currently, ^[24] 802.1X specifies that it operates on physical ports only in systems that support link aggregation; ports cannot aggregate until they have been authorized. ^[24]

As previously mentioned, 802.1X authentication for WLANs has three components (see Figure 4-5 ^[25] ): the supplicant (the client software), the authenticator (the AP), and the authentication server (a RADIUS server, although RADIUS is not specifically required by 802.1X). The client attempts to connect to the AP, which detects the client and enables the client’s port. At this juncture, it forces the port into an unauthorized state, meaning that only 802.1X traffic is forwarded; traffic such as the Dynamic Host Configuration Protocol (DHCP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), and Post Office Protocol 3 is blocked.

Figure 4-5: General topology of IEEE 802.1X

The client then sends an EAP-start message (see Figure 4-6). The AP replies with an EAP-request identity message to obtain the client’s identity. The client’s EAP-response packet containing the client’s identity is forwarded to the authentication server. The authentication server is configured to authenticate clients with a specific authentication algorithm. The result is an accept or reject packet from the authentication server to the AP. Upon receiving the accept packet, the AP transitions the client’s port to an authorized state, and traffic will be forwarded. At logoff, the client will send an EAP- logoff message. This forces the AP to transition the client port to an unauthorized state. ^[23]

Figure 4-6: IEEE 802.1X

Proponents claim that Windows XP and 802.1X provide for what is called zero configuration support , enabling laptops with a wireless adapter card to automatically detect and connect to wireless APs within range. The combination allows link layer authentication, enabling seamless user authentication. As an example, corporations will be able to use their active directories and databases to automatically authenticate employees. ^[20] Cisco and Microsoft have partnered in creating an early commercial 802.1X implementation. The Microsoft/Cisco implementation requires three components (see Figure 4-7 ^[26] ):

• Windows 2000 Domain Controller

• Windows XP Client

• Cisco 340/350 AP

  
  Figure 4-7: Initial Cisco implementation of IEEE 802.1X

You may also wish to refer to Figure 2-5 which depicts another view of the actual commercial implementation of IEEE 802.1X by Cisco Systems.

The client side of IEEE 802.1X, port-based network access control, solves the problem of key distribution in WLANs by enabling public key authentication and encryption between wireless APs and roaming stations. It also enables network managers to control 802.1X user profiles from a centralized RADIUS server. ^[27]

Figure 4-8 shows the network elements involved in a typical WLAN. When 802.1X is running, a wireless device must authenticate itself with the AP in order to get access to the existing LAN. With respect to the terms used in the 802.1X standard, wireless APs function as authenticators and wireless devices function as supplicants . The authenticator keeps a control port status for each supplicant it is serving. If the supplicant has been authenticated, then the control port status is said to be authorized , and the supplicant can send application data to the LAN through the wireless APs. Otherwise, the control port status is said to be unauthorized , and application data cannot traverse the wireless APs.

Figure 4-8: An infrastructure mode network

Figure 4-9 is a typical message exchange when the device and the wireless AP support 802.1X (note that this figure amplifies Figure 4-2). When a wireless AP acting as an authenticator detects a wireless station on the LAN, it sends an EAP-request for the user’s identity to the device. (The EAP is an authentication protocol that runs before network layer protocols transmit data over the link; it will be examined in the next subsection.) In turn, the device responds with its identity, and the wireless AP relays this identity to an authentication server, which is typically an external RADIUS server, as depicted in Figure 4-8. This allows the RADIUS server to act as the central repository of user profile information, which allows the user to access WLANs at many different points, but still be authenticated against the same server.

Figure 4-9: Typical message exchange

In response to the access-request, the RADIUS server sends an access- challenge to the wireless AP, which is then relayed in the form of an EAP- request to the device. The device sends it credentials to the wireless AP, which in turn relays them to the RADIUS server. The RADIUS server determines whether or not access to the network is accepted or denied based on the supplicant’s credentials.

An example of a product in this space is SecureSupplicant ^TM by Meetinghouse Data Communications. ^[28] SecureSupplicant enables network administrators to continue to use RADIUS as their centralized authentication server. In 802.11b, authentication took place between the AP and the station; there was no concept of passing credentials from the AP to an authentication server. For traditional LANs, this was fine, but as users began to use their devices in remote locations, this became inadequate. 802.1X solves this problem by enabling APs to pass through client credentials to the appropriate authentication server.

For example, Figure 4-10 represents the authentication flow for a mobile user who wishes to create a VPN in his home office. By using the Secure- Supplicant, the user can associate with a wireless network provided by a third party, in this case the Internet service provider (ISP). We assume that the company and the ISP have established a service relationship beforehand. When the ISP receives the user’s credentials, it proxies these credentials to the company’s RADIUS server, which either accepts or denies the user. This response is then propagated to the remote user.

Figure 4-10: Central user administration

One problem with WEP is that the shared key used by the station and the AP is inherently static. That is, this shared key will only change if it is manually reconfigured on both devices. Software such as the SecureSupplicant remedies this by supporting the TLS protocol. TLS ensures that a new shared key is generated each time a station associates itself with an AP. TLS has proven itself to be an excellent authentication and encryption protocol in commercial environments.

^[3] WEP is used at the two lowest layers of the Open Systems Interconnection (OSI) Reference Model; therefore, it does not offer endto-end security that would be possible if the encryption took place, for example, at the application layer.

^[4,5] Nikita Borisov, Ian Goldberg, and David Wagner, “Security of the WEP Algorithm.” www.isaac.cs.berkeley.edu/isaac/wep-faq.html, University of California at Berkeley, February 2001.

^[1] Kim Getgen, “Securing the air: Don’t let your wireless LAN be a moving target.” RSA Security, November 2001, www-106.ibm.com/ developerworks/library/wi-sec1/index.html?dwzone=wireless.

^[10] Dennis Fisher and Carmen Nobel, “Wireless LAN Holes.” eWeek , www.zdnet.com/eweek/stories/general/0,11011,2684337,00.html, February 11, 2001.

^[6] Mike McMurry, “Wireless Security.” www.sans.org/infosecFAQ/wireless/ wireless_sec.htm, January 22, 2001.

^[7] Nikita Borisov, Ian Goldberg, and David Wagner, “Intercepting mobile communications: The insecurity of 802.11.” MOBICOM 2001 (2001).

^[8] Adam Stubblefield, John Ioannidis, and Aviel D. Rubin, “Using the Fluhrer, Mantin, and Shamir Attack to Break WEP.” August 6, 2001.

^[9] Nikita Borisov, Ian Goldberg, and David Wagner, “Wired Equivalent Privacy (WEP).” www.isaac.cs.berkeley.edu/isaac/wep-faq.html, wep@isaac.cs.berkeley.edu, Summer 2001.

^[6] Mike McMurry, “Wireless Security.” www.sans.org/infosecFAQ/wireless/ wireless_sec.htm, January 22, 2001.

^[10] Dennis Fisher and Carmen Nobel, “Wireless LAN Holes.” eWeek , www.zdnet.com/eweek/stories/general/0,11011,2684337,00.html, February 11, 2001.

^{[11 ]} Princy C. Mehta, “Wired Equivalent Privacy Vulnerability.” http://rr.sans.org/wireless/equiv.php, April 4, 2001.

^[24] P. Roshan, “802.1X Authenticates 802.11 Wireless.” Network World , September 24, 2001.

^[7] Nikita Borisov, Ian Goldberg, and David Wagner, “Intercepting mobile communications: The insecurity of 802.11.” MOBICOM 2001 (2001).

^[12] The rest of this section is taken from Princy C. Mehta. “Wired Equivalent Privacy Vulnerability.” http://rr.sans.org/wireless/equiv.php, April 4, 2001.

^[13] S. Kent and R. Atkinson, “Security architecture for the Internet protocol.” Request for Comments 2401, Internet Engineering Task Force, November 1998.

^[14] T. Ylonen, “SSH-secure login connection over the Internet.” USENIX Security Conference VI (1996), pp. 37—42.

^[15] Ellen Zurko, “Listwatch: Items from Security-Related Mailing Lists.” www.ieee-security.org/Cipher/Newsbriefs/2001/022001 .ListWatch.html, IEEE, February 16, 2001.

^[16] Robert Lemos, “Wireless networks wide open to hackers.” CNET News.com, July 12, 2001.

^[17] Andrew Garcia, “Holes in Wireless Nets.” eWeek , www.zdnet.com/eweek/ stories/general/0,11011,2687518,00.html, February 26, 2001.

^[18] Andrew Garcia, “WEP Remains Vulnerable.” eWeek , www.zdnet.com/eweek/stories/general/0,11011,2700806,00.html, March 26, 2001.

^[19] Richard Shim, “How to Fill Wi-Fi’s Security Holes.” www.zdnet.com/enterprise/stories/main/0,10228,2693864,00.html, ZDNet, March 8, 2001.

^[20] This section is taken from work by Kim Getgen, used with permission. Security in San Mateo, CA. She is responsible for the marketing of the RSA BSAFE product line and the RSA Wireless Kim Getgen (kgetgen@rsasecurity.com) is a product marketing manager at RSA Security Portfolio. Reference: “Securing the air: Don’t let your wireless LAN be a moving target,” www-106.ibm.com/developerworks/library/ wi-sec1/index.html?dwzone=wireless, November 2001.

^[21] Matthew Peretz, “IEEE 802.1X Standard Used Successfully with Windows XP.” www.80211-planet.com/news/article/0,,1481_905331,00.html.

^[20] This section is taken from work by Kim Getgen, used with permission. Security in San Mateo, CA. She is responsible for the marketing of the RSA BSAFE product line and the RSA Wireless Kim Getgen (kgetgen@rsasecurity.com) is a product marketing manager at RSA Security Portfolio. Reference: “Securing the air: Don’t let your wireless LAN be a moving target,” www-106.ibm.com/developerworks/library/ wi-sec1/index.html?dwzone=wireless, November 2001.

^{[22 ]} Nick Petroni and Bryan D. Payne, “Opensource Implementation of IEEE 802.1X.” Maryland Information and Systems Security Lab at the University of Maryland, www.missl.cs.umd.edu/1x/index.html.

^[23] RFC 2284.

^[24] P. Roshan, “802.1X Authenticates 802.11 Wireless.” Network World , September 24, 2001.

^[24] P. Roshan, “802.1X Authenticates 802.11 Wireless.” Network World , September 24, 2001.

^[25] IEEE 802 minutes, 802.1 Interim meeting, Raleigh, NC. January 17 and 18, 2002.

^[23] RFC 2284.

^[20] This section is taken from work by Kim Getgen, used with permission. Security in San Mateo, CA. She is responsible for the marketing of the RSA BSAFE product line and the RSA Wireless Kim Getgen (kgetgen@rsasecurity.com) is a product marketing manager at RSA Security Portfolio. Reference: “Securing the air: Don’t let your wireless LAN be a moving target,” www-106.ibm.com/developerworks/library/ wi-sec1/index.html?dwzone=wireless, November 2001.

^[26] Paul Congdon, “IEEE 802.1X Overview: Port-Based Network Access Control IEEE Plenary.” http://grouper.ieee.org/groups/802/1/pages/802.1X.html, March 2000.