Wireless Security White Paper

Technical Education
An Introduction to 802.11 Wireless Security
Rev. 4.0
TT145 802.11 Wireless Security
1-1
April 2, 2008
Technical Education
1-2
April 2, 2008
Technical Education
Table of Contents
1.0 2.0 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.2 2.2.1 2.2.2 3.0 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 4.0 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.4 4.5 5.0 5.1 5.2 5.2.1 5.3 6.0 7.0 8.0 9.0 Introduction..................................................................................................................................... 6 802.11 Security................................................................................................................................ 7 802.11 Authentication ....................................................................................................................... 7 Open Authentication ......................................................................................................................... 8 Shared-Key Authentication ............................................................................................................... 9 Broadcast of SSID ...........................................................................................................................10 MAC address authentication............................................................................................................10 802.11 WEP ....................................................................................................................................10 WEP RC4 ........................................................................................................................................11 WEP CRC-32 ..................................................................................................................................12 Weaknesses in 802.11 Security ....................................................................................................15 Weaknesses in 802.11 Authentication.............................................................................................15 Use of SSID and MAC Address Authentication ...............................................................................17 Weaknesses with WEP....................................................................................................................17 Weaknesses with the RC4 Stream Cipher.......................................................................................18 CRC-32............................................................................................................................................19 Lack of Key Distribution ...................................................................................................................21 IEEE 802.1X (Port-Based Network Access Control) ...................................................................23 802.1X Authentication Process........................................................................................................25 Dynamic Encryption Keys................................................................................................................26 EAP Authentication Methods ...........................................................................................................27 EAP-TLS..........................................................................................................................................29 EAP PEAP-MSCHAPv2...................................................................................................................30 Cisco LEAP .....................................................................................................................................32 EAP-FAST .......................................................................................................................................33 A little bit about importing Certificates..............................................................................................36 Advantages of 802.1X Authentication..............................................................................................37 Wi-Fi Protected Access.................................................................................................................38 WPA Authentication.........................................................................................................................39 WPA TKIP .......................................................................................................................................39 Message Integrity Check .................................................................................................................41 Advantages of WPA.........................................................................................................................42 IEEE 802.11i (WPA2)......................................................................................................................43 Cisco Compatible Extensions ......................................................................................................45 Putting It All Together ...................................................................................................................47 Glossary .........................................................................................................................................48
1-3
April 2, 2008
Technical Education
1-4
April 2, 2008
Technical Education
802.11 Security
(In The Beginning)
1-5
April 2, 2008
Technical Education
1.0 Introduction
An 802.11 wireless network (WLAN) has many advantages over a traditional wired network. However, 802.11 wireless technology introduces security risks that a wired network is not susceptible to. Without a robust wireless security solution, organizations leave themselves vulnerable to attack through their WLAN. Access control, data privacy and data integrity are key components in preventing unauthorized access to a WLAN and compromising confidential information. Unfortunately, the security protocols defined in the original IEEE 802.11 specification (8802-11:1999) were defined at a time when the primary concerns for deploying an 802.11 wireless network were interoperability and ease of use - not security - and as a result are relatively weak in preventing the types of attacks that can be executed today against any 802.11 wireless network. A number of papers have been published on the Internet which expose the vulnerabilities in the authentication, data privacy and data integrity protocols defined in the 802.11 specification. Today, however, there are a number of enhanced wireless security solutions that are designed to combat these vulnerabilities and provide strong security for 802.11 networks. The primary focus of this document is to provide the reader with: An introduction to the security protocols defined in the original IEEE 802.11 specification. A description of the vulnerabilities of these protocols and the attacks used to exploit these vulnerabilities An introduction to the enhanced wireless security solutions available today that were developed to mitigate these vulnerabilities and attacks.
1-6
April 2, 2008
Technical Education
2.0 802.11 Security

The 802.11 specification (8802-11:1999) defines two mechanisms for providing security to 802.11 WLANs: 1. Station authentication (mobile device authentication) 2. Data encryption / integrity The specification defines two methods for authenticating mobile devices to a WLAN: Open authentication and Shared-Key authentication, and defines the Wired Equivalent Privacy (WEP) protocol for data encryption and data integrity.
2.1 802.11 Authentication

The authentication methods defined in the 802.11 specification are based on one-way communication; that is, mobile devices wishing to join a WLAN must authenticate to it first (i.e. authenticate to the AP). This one-way communication implies that the AP is considered a trusted part of the network infrastructure. The authentication process for mobile devices consists of the following transactions: 1. The mobile device broadcasts a probe request on every channel supported by the mobile device. 2. The APs within signal range respond with a probe response. 3. The mobile device decides which AP is best for access and sends an authentication request. 4. The AP sends an authentication response. 5. Upon successful authentication, the mobile device sends an association request to the AP. 6. The AP responds with an association response. 7. The mobile device is then able to transmit data to the AP (i.e. to the network).
Figure 1. illustrates the 802.11 authentication process.
Figure 1. 802.11 authentication process
1-7
April 2, 2008
Technical Education
2.1.1 Open Authentication

Open authentication is the default authentication method for 802.11. It is the simplest of the two authentication mechanisms defined in the 802.11 specification. Essentially, it is a null authentication algorithm designed to provide any mobile device quick access to a WLAN. The Open authentication process consists of two transactions: the authentication request and the corresponding authentication response. A mutual relationship is established between two 802.11 devices following a successful authentication exchange, this relationship can exist between a mobile device and AP (infrastructure) or between two mobile devices (ad-hoc). Open authentication can be used with or without WEP encryption enabled. The mobile device will perform the normal Open authentication procedure whether WEP encryption is enabled or not. Once authentication of the mobile device is complete the data transmitted between the mobile device and AP will be sent either in clear-text (unencrypted) or encrypted using the configured WEP key. Keep in mind, however, that if WEP encryption is enabled the WEP keys configured on the mobile device and AP must match, otherwise the mobile device will be able to associate to the AP but not pass data through the AP.
Figure 2. illustrates Open authentication and the effect of using different WEP keys.
Figure 2. Open Authentication using different WEP keys
1-8
April 2, 2008
Technical Education
2.1.2 Shared-Key Authentication

Shared-key authentication on the other hand requires WEP encryption as part of its authentication process and requires the mobile device and AP be configured with the same WEP key for successful authentication of the mobile device to occur. The 802.11 specification does not define a mechanism for the dynamic distribution of WEP keys; therefore the WEP keys must be manually configured. Shared-key authentication uses a challenge-text along with WEP to provide authentication. The Shared-key authentication process consists of the following transactions: 1. The station sends an authentication request to the AP requesting shared-key authentication. 2. The AP responds with an authentication response containing challenge-text, which is sent as plain-text. 3. The station uses its WEP key to encrypt the challenge-text and responds to the AP with a subsequent authentication request containing the encrypted challengetext. 4. The AP compares the encrypted challenge-text against its copy of the encrypted challenge-text. If the two challenges match, the AP allows the station access to the network.
Figure 3. illustrates the shared-key authentication process.
Figure 3. Shared-Key Authentication Two additional network access control methods are used as a means for ensuring a mobile device can or cannot connect to a WLAN. Although these methods are supported and recommended by many 802.11 equipment vendors they are not defined in the 802.11 specification: Broadcast of SSID MAC address authentication 1-9
April 2, 2008
Technical Education
2.1.3 Broadcast of SSID

An SSID can be loosely defined as a network name used for identifying one WLAN from another. It is an identifier used to logically separate WLANs. Mobile devices wishing to join a specific WLAN must be configured with that WLANs SSID. In an open network the AP broadcasts the SSID in its beacons and any mobile device within signal range can learn the SSID and attempt to connect to the WLAN. In a closed network the AP does not broadcast the SSID in its beacons and therefore only those mobile devices configured with the SSID can connect to the WLAN. Administrators configure the APs to either broadcast or not broadcast the SSID. The use of SSIDs is strictly for ensuring that a mobile device is attempting to connect to the correct WLAN. SSIDs do not provide any authentication or encryption capabilities.
2.1.4 MAC address authentication

MAC address authentication verifies the MAC address of a mobile device against a list of allowable addresses configured on the AP, or external authentication server. If the MAC address of a mobile device is defined in the list of allowed addresses, then the mobile device is permitted access to the WLAN via that AP. If the MAC address is not defined in the list then the mobile device is denied access.
2.2 802.11 WEP

The primary goal of the WEP protocol is to protect the confidentiality of data (at the datalink layer) as it travels across the wireless medium, and is intended to provide the same level of functionality as the security mechanisms inherent to a wired network. The WEP protocol is intended to achieve three main security goals: 1. Data Confidentiality The fundamental goal of WEP is to protect data from casual eavesdropping. 2. Access Control The 802.11 specification includes an optional feature to discard all packets that are not properly encrypted using WEP. 3. Data Integrity An integrity checksum value (ICV) is included in transmitted messages to prevent tampering of the message. WEP uses the RC4 stream cipher to encrypt data and the Cyclical Redundancy Checksum (CRC-32) algorithm to ensure that data is not tampered with or modified during transmission. 1-10
April 2, 2008
Technical Education
WEP requires that each 802.11 device share the same key for proper encryption and decryption of data, and is based on a 40-bit encryption key length. When the 802.11 specification was ratified (approved) in 1997 it was illegal to ship products that used 128bit encryption outside of the U.S. As a result, the specification defines the use of a 40-bit key length. Today, however, 802.11 products support WEP key lengths of 104 bits, offering both 40 bit and 104 bit WEP encryption. 104-bit WEP keys do provide more security, but even 104-bit keys are susceptible to attack.
2.2.1 WEP RC4

The WEP protocol uses the RC4 stream cipher to encrypt data. Stream ciphers operate by taking a secret key and expanding it into a pseudorandom keystream that is the same length as the plain-text message. The exclusive OR (XOR) boolean function is then applied to the keystream and plain-text message to generate the cipher-text message (encrypted message).
Figure 4. illustrates the RC4 stream cipher operation.
Figure 4. The RC4 Stream Cipher Operation
The strength (security) of stream ciphers rests entirely on the randomness of the keystream; therefore, the design of the secret key-to-keystream operation is very important. Unfortunately, the major weakness with any stream cipher is the reuse of keystreams; that is, encrypting two different plain-text messages with the same keystream creates similar patterns in the cipher-text messages. This introduces a security threat because attackers can analyze the patterns in the cipher-text messages.
1-11
April 2, 2008
Technical Education
If the attacker manages to obtain the contents of one of the plain-text messages, then they can decipher the contents of the second plain-text message based on the patterns in the cipher-text messages and the known plain-text message. To overcome the possibility of keystream reuse, WEP uses an Initialization Vector (IV) to alter the keystream so that no one keystream will be the same. The IV is a dynamically 24 generated 24-bit numeric value which generates 2 or 16, 777, 216 possible keystream values and is concatenated to the key before the keystream is generated. Every time the IV changes, so does the keystream, despite using the same key. The IV provides two functions as part of the WEP protocol: It is the mechanism used to generate a new, unique keystream for every plaintext message. It provides synchronization by keeping the encryption / decryption process synchronized in the event of lost or retransmitted messages. In the final steps of the WEP encryption process the IV is transmitted in clear-text along with the cipher-text message so that the receiving device will know the value of the IV and be able to decrypt the received cipher-text message.
2.2.2 WEP CRC-32

The WEP protocol also uses an Integrity Checksum Value (ICV) to ensure that data is not tampered with or modified as it travels across the wireless medium. The ICV is based on the CRC-32 algorithm and is calculated using the data to be transmitted. The checksum value is then concatenated to the data to produce the plain-text message. The complete WEP encryption process consists of the following transactions: 1. The ICV is calculated using CRC-32 and the data. 2. The ICV is concatenated to the data to produce the plain-text message. 3. The RC4 stream cipher generates a keystream based on the configured key and dynamically generated IV. 4. The XOR function is applied to the keystream and plain-text message to obtain the cipher-text message 5. The cipher-text message and IV are transmitted in the 802.11 frame.
Figure 5. illustrates the 802.11 WEP encryption process which incorporates the Initialization Vector and Integrity Checksum Value.
1-12
April 2, 2008
Technical Education
Figure 5. The 802.11 WEP Encryption Process
Although it is commonly referred to as 64-bit and 128-bit WEP encryption (40-bit key + 24-bit IV or 104-bit key + 24-bit IV) the strength of the keys are actually only 40 bits and 104 bits because the 24-bit IV is sent unencrypted in the frame header. To decrypt the message, the receiving device simply reverses the encryption process: 1. The receiving device generates a keystream based on its configured WEP key and the IV sent in the frame header of the message. 2. The receiving device then applies the XOR function to the keystream and ciphertext message to recover the initial plain-text message. 3. It then separates the plain-text message into the data and ICV and computes an integrity checksum value on the received data and compares the calculated ICV to the received ICV. 4. If the two checksum values match the receiving device accepts the message as valid data and places the data on the wired LAN. For proper encryption and decryption of data all devices must be configured with the same key.
802.11 management frames are sent in clear-text (unencrypted) even when WEP encryption is enabled.
1-13
April 2, 2008
Technical Education
Weaknesses in 802.11 Security
1-14
April 2, 2008
Technical Education
3.0 Weaknesses in 802.11 Security

It is important to emphasize that when security mechanisms were being defined for the 802.11 specification the primary concerns being addressed by the specification were interoperability and ease of use. As a result, the security mechanisms defined in the specification are relatively weak by todays standards. Beginning in 2001, several papers have been published on the Internet which expose the vulnerabilities of 802.11 security; including ways to compromise it. Numerous studies have shown that persistent attackers can quickly breach WLAN security even with WEP encryption enabled. The papers expose the vulnerabilities evident in the authentication services and WEP protocol defined in the 802.11 specification, as well as with SSID and MAC address authentication. The Wi-Fi Alliance warns against the use of WEP as the only means of security for a WLAN by stating: It is important to emphasize that WEP was never intended to be a complete endto-end security solution. It protects the wireless link between the client machines and access points. Whenever the value of the data justifies such concern, both wired and wireless should be supplemented with additional higher-level security mechanisms such as access control, end-to-end encryption, password protection, authentication, virtual private networks, or firewalls.
3.1 Weaknesses in 802.11 Authentication

Open authentication is designed to authenticate any mobile device that requests access to a WLAN, including an attackers wireless laptop. The AP has no way of determining whether the user of the mobile device is authorized to access the WLAN, or not. Once authenticated, an attacker can launch a utility such as Airsnort or WEPCrack to quickly determine the WEP key. Shared-key authentication is considered even less secure than Open authentication because of the challenge-text transaction. In late March 2001, the University of Maryland published a paper that focused on the vulnerability of Shared-key authentication. Shared-key authentication requires the mobile device use its configured WEP key to encrypt the challenge-text sent by the AP. The AP authenticates the mobile device by comparing the encrypted challenge-text sent by the mobile device and validating it against its own copy. If the copies match, the AP allows the mobile device access to the WLAN.
1-15
April 2, 2008
Technical Education
The Maryland paper explains that the process of exchanging the clear-text version and encrypted version of the challenge over the wireless medium is susceptible to a man-inthe-middle attack; the attacker uses sniffer software to capture both the clear-text version of the challenge and the encrypted response transmitted between the mobile device and AP. The attacker can then derive the keystream by simply performing the XOR function on the clear-text and encrypted challenges. The attacker then requests authentication to the AP, at which point the AP will send a clear-text challenge. The attacker then performs the XOR function on the clear-text challenge and the derived keystream to generate a valid authentication response. The attacker computes a new ICV and responds to the AP with a valid authentication response message. The AP authenticates the attacker and grants them access to the WLAN. At this point, the attacker has successfully associated to the AP without actual knowledge of the WEP key. Once successfully associated, the attacker can launch another attack to determine the WEP key, allowing them to transmit messages to the AP. Once an attacker has successfully executed a man-in-the-middle attack, mobile devices will view the attacker as an authorized AP and conversely the AP views the attacker as an authorized mobile device. Both the mobile device and AP fail to detect the attacker and continue transmitting information.
Figure 6. illustrates the vulnerability of Shared-key authentication to a man-in-the-middle attack.
Figure 6. Vulnerability of Shared-Key Authentication Due to the inherent vulnerability of Shared-key authentication, it is strongly recommended that it not be used. Shared-key authentication is part of the 802.11 specification and therefore vendors are required to support it to be 802.11 compliant. It is recommended that Open authentication be used with WEP encryption enabled as opposed to Shared-key authentication.
1-16
April 2, 2008
Technical Education
3.2 Use of SSID and MAC Address Authentication

The Maryland paper also elaborates on the issues associated with SSIDs and MAC address authentication. The SSID is simply a clear-text string used to logically separate one WLAN from another. It is not designed to provide any level of data encryption or authentication. With an open network, the SSID is broadcast in the APs beacons. An attacker within signal range can quickly learn the SSID and attempt to connect to the WLAN. In an effort to increase security, 802.11 equipment vendors have implemented the No broadcast SSID feature that prevents the AP from broadcasting the SSID. Only those mobile devices configured with the SSID can connect to the WLAN. However, this feature provides no defense against a man-in-the-middle attack because attackers can simply capture messages being transmitted between an AP and mobile device and quickly learn the SSID. MAC addresses are also transmitted in clear-text. As a result, WLANs using MAC address authentication are susceptible to MAC address spoofing attacks. MAC address spoofing is possible because many 802.11 network interface cards (NICs) allow the hard-coded MAC address of a device to be overwritten with a MAC address configured by the user. Once an attacker has captured enough messages, they can quickly learn the MAC address of an authorized mobile device and AP and overwrite their (the attackers mobile device) hard-coded MAC address with the MAC address of the authorized mobile device or AP. When spoofing an AP, the attacker appears as an authorized AP with the intent to associate with the authorized mobile device and access data on that device. When spoofing an authorized mobile device, the attacker appears as an authorized device, with the intent to gain unauthorized access to the WLAN through the AP.
3.3 Weaknesses with WEP

WEPs design flaws came to light when the Internet Security, Applications, Authentication and Cryptography (ISAAC) group at the University of California, Berkeley published a paper in February 2001 that described in detail the security weaknesses in the WEP protocol. WEP was found to be insecure due to its improper implementation of the RC4 stream cipher and the use of the Cyclical Redundancy Checksum (CRC-32) algorithm for data integrity. WEPs vulnerabilities are compounded by the fact that keys are manually configured and rarely changed because the 802.11 specification does not specify a key distribution mechanism.
1-17
April 2, 2008
Technical Education
3.3.1 Weaknesses with the RC4 Stream Cipher

The two primary weaknesses of WEPs implementation of the RC4 stream cipher are: The derivation (generation) of weak IVs Keystream reuse In 2001, crypto-analysts Fluhrer, Mantin, and Shamir published a paper that explained how a WEP key could easily be cracked due to WEPs poor implementation of the Key Scheduling Algorithm (KSA) of the RC4 stream cipher. In their paper, Fluhrer, Mantin, and Shamir describe in detail how the first byte in a subset of IVs, referred to as weak IVs, could be correlated with individual bytes of the WEP key and that if enough messages containing these weak IVs are captured, they can be statistically analyzed to derive the WEP key used for encryption. The 24-bit IV value generates 2 or 16, 777, 216 possible keystream values. Out of the 16 million IV values about 9,000 represent weak IVs. Many WEP cracking tools such as Airsnort and WEPCrack analyze captured messages for the existence of these weak IVs. Researchers at AT&T/Rice University as well as the developers of the Airsnort application put this vulnerability to the test and verified that WEP keys of either 40 or 104-bit key lengths can be derived after analyzing as few as 100,000 packets encrypted with weak IVs. For high-usage WLANs, this translates to roughly 3-4 hours until a 104bit WEP key is cracked. In addition to the weak IVs, it was determined that encrypting two messages using the same RC4 generated keystream would reveal information about both messages; a phenomenon referred to as keystream reuse. Researchers at the University of California, Berkeley found that WEPs 24-bit IV was inadequate in preventing keystream reuse because the same IV would be reused within a relatively short period of time. As mentioned, the 24-bit IV yields 16, 777, 216 unique IV values. Given a network running at 11 Mbps and constantly transmitting 1500-byte packets, an IV would be reused in approximately 5 hours, as explained by the following calculation: 11 Mbps (1500 bytes/pkt 8 bits per/byte) = 917 pkts transmitted each second 16,777,216 IVs 917 pkts/second = 18296 seconds required to use all IVs 18296 seconds 60 seconds/min. 60 min./hour = 5.08 hours to use up all IVs Recall that the IV is sent in clear-text along with the cipher-text message. Attackers can simply launch a man-in-the-middle attack and passively collect cipher-text messages until they have collected enough messages with the same IV. The attacker can then perform statistical analysis on the messages until they have successfully derived the keystream. Once the keystream has been determined, the attacker can use it to decrypt other captured messages with the same IV. This type of attack is referred to as an IV replay attack.
24
1-18
April 2, 2008
Technical Education
Since there are a little more than 16 million possible IV values, it is important how each IV is chosen in order to mitigate the attacks that focus on the weaknesses of the IV. Unfortunately, the WEP protocol doesn't specify how IVs are chosen or how often theyre changed. Some 802.11 vendor implementations start the IV at zero and increase it incrementally for each packet, rolling back to zero after the 16 millionth packet has been sent. Some vendor implementations choose IVs randomly which sounds like a good idea but really isn't because with a randomly chosen IV theres a 50% chance of keystream reuse after less than 5,000 packets.
3.3.2 CRC-32
The Berkeley paper goes on to describe the weaknesses in the CRC-32 checksum algorithm. The researchers show that the CRC-32 algorithm is inadequate in ensuring data integrity because it is a linear checksum and is susceptible to a bit-flip or replay attack. To execute a bit-flip/replay attack, an attacker uses wireless sniffer software to capture encrypted messages transmitted between a mobile device and AP. The following steps describe how a bit-flip attack is executed: 1. The attacker sniffs a frame on the WLAN and flips random bits in the data payload of the frame. 2. The attacker modifies the ICV (detailed later). 3. The attacker transmits the modified frame. 4. The receiver (either a mobile device or AP) receives the frame and calculates the ICV based on the frame contents. 5. The receiver compares its calculated ICV with the value in the ICV field of the frame. 6. The receiver accepts the modified frame. 7. The receiver de-encapsulates the frame and processes the Layer 3 packet. 8. Because bits are flipped in the Layer 3 packet, the Layer 3 checksum fails. 9. The receiver IP stack generates a predictable error. 10. The attacker sniffs the wireless LAN looking for the encrypted error message. 11. Upon receiving the error message, the attacker derives the key stream as with the IV replay attack.
Figure 7. illustrates a bit-flip/replay attack.
1-19
April 2, 2008
Technical Education
Figure 7. Bit-Flip/Replay Attack The basis of the bit-flip attack is in the failure of the CRC-32 algorithm. If the change to the ICV reflects the change to the data payload, then the modified message will go undetected by the AP. The attacker is able to calculate the correct ICV by performing the following operations: 1. A captured frame (F1) has an ICV (C1). 2. A new frame is generated (F2) the same length as F1, with bits flipped. 3. Frame F3 is produced by XORing F1 and F2. 4. The ICV for F3 is calculated (C2). 5. The correct ICV (C3) for F3 is generated by XORing C1 and C2 Figure 8. illustrates the steps for calculating the correct ICV during a bit-flip attack.
Figure 8. Calculating the ICV for a Bit-Flip Attack
1-20
April 2, 2008
Technical Education
3.3.3 Lack of Key Distribution

The 802.11 specification does not define a method for how keys are generated and distributed. As a result, keys must be manually configured on all devices which makes it increasingly more difficult to manage and update keys as more devices and APs join the wireless network; therefore keys are rarely updated. The randomness and strength of the keystream is dependant on the value of the IV and key. If the value of the key remains constant, then it increases the risk of keystream reuse. Infrequent updates to the key allows attackers to build decryption dictionaries; a table of keystreams corresponding to each IV. A dedicated attacker can easily accumulate enough data to build a full decryption dictionary. It then becomes possible to launch a dictionary attack and quickly decrypt each subsequent cipher-text message with little effort.
1-21
April 2, 2008
Technical Education
Enhanced Wireless Security Solutions for 802.11 WLANs
1-22
April 2, 2008
Technical Education
4.0 IEEE 802.1X (Port-Based Network Access Control)

The IEEE 802.1X standard defines a mechanism for port-based network access control and is supported by a number of IEEE 802 infrastructures such as Ethernet, Token-Ring, FDDI and 802.11. 802.1X provides an authentication framework on top of which various authentication methods such as certificates and one-time passwords are used to provide authentication services, and prevents access in cases where authentication and authorization fails. The 802.1X standard brings a number of enhancements to 802.11 networks to address the shortcomings of the original 802.11 security mechanisms described earlier, such as user authentication and a method for dynamic distribution of encryption keys. 802.1X has three components that combine to deliver strong authentication: 802.1X Supplicant Authenticator Authentication Server (WZC, Summit Client Utility, Odyssey Access Client) (PTX 9160, autonomous AP, WLAN controller) (Microsoft IAS, Cisco ACS)
With respect to 802.11, the supplicant is represented by the mobile device and the authenticator is represented by the AP in an autonomous (Thick AP) environment, or by the wireless controller in a centralized, controller-based environment. The most common type of authentication server is RADIUS (Remote Authentication Dial-In User Service). Figure 9. illustrates the IEEE 802.1X setup.
Figure 9. IEEE 802.1X setup

1-23
April 2, 2008
Technical Education
802.1X uses the Extensible Authentication Protocol (EAP) to pass authentication information between the mobile device and the authentication server. EAP effectively creates a session between the mobile device and authentication server, allowing the user to forward their credentials to the authentication server. If the EAP authentication method used supports mutual authentication, then the authentication server also provides its credentials to the mobile device within the same session. The EAP session provides the mobile device limited access to the network for authentication purposes only. Once the user of the mobile device has successfully authenticated to the network, the session is terminated and the user is granted access. The encapsulated form of EAP, known as EAP over LAN (or EAPOL), is used for communication between the mobile device and authenticator. The authenticator acts as an EAP proxy between the mobile device and authentication server, accepting EAPOL packets from the mobile device and forwarding them to the authentication server over a protocol such as RADIUS. The authentication server confirms the users credentials and directs the authenticator to allow the mobile device access to the network. In turn, the authenticator forwards all authentication server EAP packets over EAPOL to the mobile device. RADIUS is a widely deployed protocol for enabling centralized authentication, authorization and accounting for network access. The authenticator sends the users credentials and connection parameter information in the form of a RADIUS message to the RADIUS server (authentication server). The RADIUS server authenticates and authorizes the authenticators request and sends back a RADIUS message response. RADIUS messages are never sent between the mobile device and authenticator. RADIUS messages are sent as User Datagram Protocol (UDP) messages. UDP port 1812 is used for RADIUS authentication messages and UDP port 1813 is used for RADIUS accounting messages. Some RADIUS servers support UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. Only one RADIUS message is included in the UDP payload of a RADIUS packet. The following provides a brief description of the various RADIUS message types: Access-Request Sent by the authenticator to request authentication and authorization for network access. Access-Accept Sent by the RADIUS server (authentication server) in response to an Access-Request message. This message informs the authenticator that the connection attempt is authenticated and authorized. Access Reject Sent by the RADIUS server in response to an Access-Request message. This message informs the authenticator that the connection attempt is rejected. The RADIUS server sends this message if either the users credentials are not authentic or the connection attempt is not authorized.
1-24
April 2, 2008
Technical Education
Access-Challenge Sent by the RADIUS server in response to an Access-Request message. This message is a challenge to the authenticator that requires a response provided by the mobile device. Accounting-Request Sent by the authenticator to specify accounting information for a connection that was accepted. Accounting-Response Sent by the RADIUS server in response to the AccountingRequest message. This message acknowledges the successful receipt and processing of the Accounting-Request. To provide additional security, the authenticator and authentication server are configured with a shared secret. The shared secret is used to secure RADIUS traffic and is typically configured as a text string on both the authenticator and authentication server.
4.1 802.1X Authentication Process

802.1X has the effect of creating two logical points of access to the authenticators physical point of attachment to the network. The two logical points of access are referred to as the controlled port and uncontrolled port. Uncontrolled ports and controlled ports are considered part of the same physical point of attachment to the network. In 802.11 terms, the physical point of attachment is represented by the association between the mobile device and AP.
Figure 10. illustrates how 802.1X has the effect of creating two distinct logical points of access to the authenticators physical point of attachment to the LAN.
Figure 10. Authenticators controlled and uncontrolled ports
1-25
April 2, 2008
Technical Education
802.1X authentication typically occurs after the mobile device has established a connection to the authenticator (i.e. associated to the AP) at startup or after roaming. Upon detecting the mobile devices connection, the authenticator enables the mobile devices port and forces the port into an unauthorized state so that only EAP traffic is forwarded; all other traffic is blocked. The mobile device at this point is unable to send any network traffic - including critical traffic like DHCP requests - until the 802.1X authentication process is complete and the user of the mobile device has been successfully authenticated. The controlled port only accepts packets from authenticated devices and can be thought of as a logical switch. If the user is authenticated, then the switch is closed and traffic may flow through that port. If the user is in the process of authentication or fails authentication, then the switch is open and traffic may not flow through that port. The authenticator uses the uncontrolled port to exchange EAP protocol information between the mobile device and authentication server. Protocol exchanges between the authenticator and authentication server can be conducted via one or more of the authenticators controlled or uncontrolled ports. A pair of controlled ports one on the AP or WLAN controller and one on the mobile device is created for each mobile device connected to the AP or WLAN controller. This creates a one-to-one relationship between the authenticator and each of its associated mobile devices. Once the user is authenticated and authorized, the mobile device is granted network access and can transmit data to the network through its controlled port.
4.2 Dynamic Encryption Keys

Encryption protocols can be used in conjunction with 802.1X. This is because the 802.1X standard provides a mechansim for transmitting encryption keys in circumstances where encryption is enabled. EAP authentication methods that support mutual authentication introduce strong improvements to how encryption keys are generated, managed and distributed by enabling dynamic per-packet keying. Heres how dynamic per-packet keying works: Once mutual authentication between the mobile device and authentication server is successfully complete, a session key is mutually computed in both the authentication server and mobile device during the 802.1X authentication process. The authentication server sends a success message to the authenticator along with the session key. Using the session key, the mobile device and authenticator derive the same encryption key for encrypting unicast traffic. The session key is never transmitted over the wireless link. In addition to the unicast encryption key the authenticator also generates an encryption key for encrypting broadcast traffic, which it encrypts using the session key and forwards to the mobile devices.
1-26
April 2, 2008
Technical Education
The length of a session is defined on the authentication server. When a session expires or the mobile device roams from one authenticator to another, re-authentication occurs and a new session key is generated, which in turn generates new encryption keys. If, somehow, an attacker does manage to intercept an encryption key, a new key is generated after a specified period of time rendering the captured key invalid. Figure 11. illustrates the 802.1X mutual authentication process with dynamic per-packet keying.
Figure 11. 802.1X authentication with dynamic per-packet keying
4.3 EAP Authentication Methods

EAP is an authentication framework which supports multiple authentication methods. EAP typically runs directly over the data-link layer without requiring IP. While EAP was originally developed for use with PPP, it is also used with IEEE 802 based networks and is the authentication framework of choice for protecting wireless and wired networks, remote dial-up, and VPNs. EAP authentication provides the means of securing an 802.11 connection. EAP is a general protocol and is extensible in that it supports multiple authentication methods. The actual EAP authentication method used is unknown to 802.1X. This allows 802.1X to support future developed EAP authentication methods without the need for changes to the 802.1X standard.
1-27
April 2, 2008
Technical Education
The EAP authentication methods that are commonly used today include: EAP-TLS EAP PEAP-MSCHAPv2 LEAP (Cisco proprietary) EAP-FAST The EAP authentication method used during the 802.1X authentication process is negotiated between the mobile device and authentication server (i.e. EAP authentication methods are configured on the mobile device and authentication server). The authenticator simply acts as a pass-through device passing EAP messages between the mobile device and authentication server. The actual processing of EAP messages occurs at the mobile device and authentication server, not the authenticator. The advantage of using EAP over RADIUS is that EAP authentication methods do not need to be configured on the authenticator. The authenticator need only support the capabilities to pass EAP messages between the mobile device and authentication server.
Figure 12. illustrates the EAP structure.
Figure 12. EAP structure
1-28
April 2, 2008
Technical Education
4.3.1 EAP-TLS
EAP-TLS is a two-way (mutual) authentication protocol in which the mobile device authenticates the authentication server, and in turn, the authentication server authenticates the user. EAP-TLS is one of the original authentication methods specified by the IEEE when 802.1X and EAP were initially proposed and established as a standard. TLS is used in many environments and is intended to be an alternative to the Secure Sockets Layer (SSL) security protocol. EAP-TLS relies on a Client Certificate for authenticating the user and a Server Certificate for authenticating the authentication server. Certificates are issued by a Certificate Authority (CA) which is typically part of a Public Key Infrastructure (PKI); a system of certificates, certificate authorities and other registration authorities that verify and authenticate the validity of each user involved in transactions and exchanges of information. As part of the EAP-TLS authentication process, the mobile device and authentication server perform a TLS handshake to establish a secure, encrypted TLS tunnel through which user credentials are forwarded for authentication. The nature of the encrypted TLS tunnel secures against man-in-the-middle-attacks, and the use of certificates secures against dictionary attacks. Figure 13. illustrates the EAP-TLS authentication process
Figure 13. EAP-TLS Authentication Process

1-29
April 2, 2008
Technical Education
Encryption keys are dynamically generated and distributed after successful authentication to encrypt subsequent data transmissions. EAP-TLS is an ideal authentication solution in environments which already have a PKI deployed for user authentication. It is unlikely, however, that a customer would deploy a PKI to support authentication of wireless devices only. Advantages of EAP-TLS include: Encrypted TLS tunnel secures against man-in-the-middle attacks. Certificates provide strong authentication; secures against dictionary attacks. Widely supported. Disadvantages of EAP-TLS include: Certificates must be installed and managed on each mobile device; too cumbersome. Requires a Certificate Authority.
4.3.2 EAP PEAP-MSCHAPv2

EAP PEAP-MSCHAPv2 is also a two-way (mutual) authentication protocol. PEAPMSCHAPv2 relies on a Server Certificate for authenticating the authentication server and uses MSCHAPv2 based user credentials (username and password) for authenticating the user. As part of the PEAP-MSCHAPv2 authentication process, the mobile device and authentication server perform a TLS handshake to establish a secure, encrypted TLS tunnel through which the users credentials are forwarded for authentication. The TLS tunnel secures against man-in-the-middle-attacks. The PEAP-MSCHAPv2 authentication process occurs in two phases: 1. The mobile device and authentication server perform a handshake in which the authentication server forwards its Server Certificate to the mobile device for server authentication and to establish the TLS tunnel. 2. The mobile device forwards MSCHAPv2 based user credentials to the authentication server through the TLS tunnel for user authentication. Encryption keys are dynamically generated and distributed after successful authentication to encrypt subsequent data transmissions.
Figure 15. illustrates the EAP PEAP-MSCHAPv2 authentication process.
1-30
April 2, 2008
Technical Education
Figure 15. EAP PEAP-MSCHAPv2 Authentication Process
Since MSCHAPv2 is a password-based authentication protocol it is important for administrators to configure strong passwords to prevent dictionary attacks. Characteristics of strong passwords include: A mixture of uppercase and lowercase letters. At least one numeric character (0-9) or non-alphanumeric characters (! @ # &). At least one special character within the password; not at the beginning or end. No resemblance to the users name or user ID. A word that is not found in the dictionary. PEAP-MSCHAPv2 can be deployed against any user database that supports the MSCHAPv2 format, such as Windows NT and Active Directory. Since Microsoft credentials can be used with PEAP-MSCHAPv2, mobile devices may be configured to use Windows login credentials to authenticate to the network. Advantages of PEAP-MSCHAPv2 include: Encrypted TLS tunnel secures against man-in-the-middle attacks. Client Certificates not required; simplifies end user / device management. Can be deployed against existing authentication database. Widely supported. Disadvantages of PEAP-MSCHAPv2 include: Strong passwords must be used.
1-31
April 2, 2008
Technical Education
4.3.3 Cisco LEAP

LEAP is a Cisco proprietary authentication protocol that follows the 802.1X standard and provides mutual authentication between the mobile device and authentication server. The mobile device sends a challenge to the authentication server via the authenticator. The authentication server must correctly respond to the challenge for the mobile device to validate the server. User authentication is based on MSCHAP username and password credentials. Encryption keys are dynamically generated upon successful authentication to encrypt all subsequent data transmissions. Cisco strongly recommends the use of strong, unique passwords to mitigate against dictionary attacks; no common names, phrases or easily guessed strings. When used in conjunction with a strong password policy, Cisco LEAP provides a secure authentication solution.
Figure 16. illustrates the LEAP authentication process.
Figure 16. Cisco LEAP Authentication Process
1-32
April 2, 2008
Technical Education
Advantages of Cisco LEAP include: Simple to deploy and operate; password-based. Disadvantages of Cisco LEAP include: Not supported by Microsoft. Cisco proprietary; not supported by all hardware vendors. Susceptible to dictionary attacks; strong passwords must be used.
4.3.4 EAP-FAST
EAP-FAST is an EAP authentication protocol developed by Cisco to support organizations that cannot enforce a strong password policy as required by LEAP, and who wish to deploy an authentication method that does not require certificates. EAP-FAST is a mutual authentication protocol that encrypts EAP messages via a TLS tunnel. The tunnel is established using strong secrets called Protected Access Credentials (PACs) which the authentication server generates using a master key known only to the server. EAP-FAST authentication occurs in 3 phases: Phase Zero (Automatic PAC Provisioning) Phase zero is a means for dynamically providing a mobile device with a PAC. A secure tunnel is established based on an anonymous Diffie-Hellman key exchange between the mobile device and authentication server whereby the server sends the mobile device a PAC through the secure tunnel. Providing a PAC to the mobile device is the only purpose for phase zero. Automatic provisioning of the PAC via phase zero is referred to as in-band provisioning. Phase zero is optional. PACs can also be manually set up on each mobile device. This method is referred to as out-of-band provisioning. Administrators can control whether the authentication server supports phase zero by enabling automatic PAC provisioning on the server. Phase zero relies on the MSCHAPv2 protocol to authenticate the user from which the secure tunnel is established and the PAC is sent. Therefore, it may be necessary to use manual provisioning if youre using a non-Microsoft-format user database such as LDAP, which does not support MSCHAPv2. It is important to understand that the initial user authentication performed in phase zero is strictly done for the purposes of establishing the secure tunnel through which the PAC is sent. The end result of phase zero is the distribution of the PAC to the mobile device, not user authentication required for access to the network.
1-33
April 2, 2008
Technical Education
After the PAC is successfully sent to the mobile device, the authentication server issues an authentication failure to the authenticator and the mobile device is disassociated from the WLAN. The mobile device then re-initiates an EAP-FAST authentication request with the WLAN using the newly provisioned PAC. The process of authenticating the user to the network begins with phase one. Figure 17. illustrates EAP-FAST automatic PAC provisioning via phase zero.
Figure 17. EAP-FAST Phase Zero: Automatic PAC Provisioning
Phase One In phase one, the authentication server and mobile device establish a TLS tunnel based on the PAC. The authentication server sends the mobile device an Authority ID (A-ID) and the mobile device selects the correct PAC from its storage by correlating the provided A-ID with its saved PACs, and a TLS tunnel is established. Phase Two In phase two, the users credentials are forwarded to the authentication server through the TLS tunnel for user authentication to the network. EAP-FAST only supports EAP based user credentials within the TLS tunnel. The following EAP based user credentials are currently supported with EAPFAST: o o o EAP-MSCHAPv2 (PACs manually or automatically provisioned) EAP-GTC (PACs manually provisioned) EAP-TLS (PACs manually provisioned)
Keep in mind that although user authentication occurs frequently, the provisioning of PACs to mobile devices occurs infrequently and is based on policies configured on the authentication server. A mobile device will use the same PAC many times when reauthenticating to the network.
1-34
April 2, 2008
Technical Education
Figure 18. illustrates phase one and two of EAP-FAST.
Figure 18. EAP-FAST Phase One and Phase Two
EAP-FAST was not intended to replace LEAP. It was designed for organizations wishing to deploy a secure authentication solution without the need for strong passwords or certificates. Advantages of EAP-FAST include: Encrypted TLS tunnel secures against man-in-the-middle attacks. Digital certificates not required. Strong passwords not required. Disadvantages of EAP-FAST include: Limited vendor support; not supported by Microsoft
1-35
April 2, 2008
Technical Education
Table 1. provides a comparison summary of the EAP authentication methods described.
Table 1. Comparison of commonly used EAP authentication methods
4.4 A little bit about importing Certificates

As mentioned earlier, several EAP authentication methods rely on Client and CA certificates for authentication. Certificates are issued by a Certificate Authority (CA) and are secure, confidential items which are not normally given to PTX personnel without cooperation and assistance from the customer. Client certificates are typically in a .pfx file format and CA certificates are typically in a .cer file format. Client certificates contain a private key which make them problematic to import on Windows CE based mobile devices when using either CEs native Wireless Zero Config. (WZC) or the Summit Client Utility (SCU), as CEs WZC and the current version of SCU dont support a certificate import utility for importing Client certificates in CE. The Odyssey Access Client, however, does contain an import utility which allows administrators to import Client certificates into Windows CE based mobile devices via the Odyssey Access Client.
1-36
April 2, 2008
Technical Education
Windows Mobile operating systems do contain a native certificate import utility. The native import utility automatically detects certificates. Therefore, there are no issues with importing Client certificates on Windows Mobile based devices when using WZC or SCU. CA certificates on the other hand dont contain private keys and therefore pose no issues to import into Windows CE or Windows Mobile based mobile devices when using WZC, SCU, or the Odyssey Access Client. Importing Client certificates on mobile devices is only an issue when deploying TLS authentication. PEAP-MSCHAPv2 requires the mobile device contain only the CA certificate, which raises no issue.
4.5 Advantages of 802.1X Authentication

Control at the network Edge 802.1X allows a network to restrict access at the edge, where it is most easily managed. Controlled ports, wired or wireless, stop attackers from ever gaining access to your network. Because 802.1X provides access control for various networking technologies such as Ethernet, Token Ring, FDDI and 802.11, it allows organizations to create a security policy that can be implemented across their wired and wireless networks. Dynamic Encryption Key Management 802.1X provides a framework that allows a WLAN to dynamically generate and distribute encryption keys, periodically change encryption keys, and periodically re-authenticate users. This enhances security by eliminating static encryption keys and mitigating attacks targeted at collecting large amounts of data encrypted with the same key. Low Overhead 802.1X is only employed during authentication and it permits encryption to be employed only between the APs and mobile devices, so it adds no per-packet overhead other than that imposed when enabling encryption and can be implemented on existing switches and APs with little performance impact. The primary considerations for determining which EAP authentication method to deploy in a WLAN are: The authentication mechanism that is in place in the enterprise; PKI, passwordbased database. Whether the authentication mechanism is suitable for or adaptable to authentication of wireless users. The EAP authentication methods supported by the mobile devices. The amount of impact on device performance that is tolerable.
1-37
April 2, 2008
Technical Education
5.0 Wi-Fi Protected Access

The Wi-Fi Alliance introduced WPA to address the weaknesses in the security mechanisms defined in the original 802.11 specification. WPA is a subset of the IEEE 802.11i security standard and addresses security requirements for AP-based 802.11 networks (infrastructure). It was introduced to fill the security gap until the ratification of the 802.11i standard. The idea behind WPA was to bring to market a security solution that took advantage of the stable components of 802.11i while the IEEE 802.11i task group continued their work to ratify the complete 802.11i standard, as illustrated in Figure 19.
Figure 19. WPA WPA provides an architectural framework on top of which standards-based security protocols are used to deliver authentication and encryption services for 802.11 networks. The following key components make up WPA: Mutual Authentication Either using 802.1X authentication or Pre-Shared Keys (PSK). Unicast and Broadcast Encryption Keys Keys derived upon successful authentication for the encryption of unicast and multicast data. Dynamic Key Management Dynamically generated per user, per session, per packet encryption keys. Temporal Key Integrity Protocol (TKIP) and Message Integrity Check (MIC) Protocols that combine to provide strong data encryption and data integrity. Larger IV Key Length Initialization Vector is expanded from 24 bits to 48 bits.
1-38
April 2, 2008
Technical Education
5.1 WPA Authentication

The initial WPA authentication process is essentially identical to standard 802.11 authentication and association. The primary difference with WPA is in the initial association request (probe request) the mobile device and authenticator send. As part of WPA compliance, the authenticator must advertise its security capabilities within its 802.11 beacons. The security capabilities advertised describe the encryption protocols and authentication methods supported. The mobile device and authenticator must agree on a security scheme during the association process. WPA supports two authentication services: 802.1X/EAP Pre-Shared Key (PSK) In an enterprise environment, WPA relies on 802.1X authentication, as described in section 4.0, to provide centralized access control and management. This is referred to as WPA Enterprise. In a smaller, cost-sensitive environment where there is no central authentication server or EAP framework, such as a home or small office, WPA can be run in Pre-Shared Key mode (PSK) which relies on a manually configured passphrase on the mobile device and wireless router. The administrator or home user simply configures a passphrase on their wireless router and each mobile device. The use of PSK for authentication is referred to as WPA Personal. Successful authentication of the mobile device and wireless router is based on a matching passphrase. The passphrase must be 8 to 63 ASCII characters long; the longer the passphrase the less susceptible the WLAN is against a dictionary attack.
5.2 WPA TKIP

The Temporal Key Integrity Protocol (TKIP) is an enhancement to WEP and WEPs implementation of the RC4 algorithm. TKIP essentially acts as a wrapper around the WEP protocol to maximize the security of the encryption itself. TKIP was chosen as the primary encryption cipher suite for WPA because it is easily deployed and supported in legacy 802.11 hardware compared to other available encryption protocols. Since the RC4 stream cipher is used for both WEP and TKIP, hardware that supports WEP encryption may be upgraded to support TKIP encryption. TKIP support on most legacy hardware is made available through a firmware or software upgrade.
1-39
April 2, 2008
Technical Education
The goal of TKIP is to address all of WEPs known problems: Correct WEPs mis-use of encryption; RC4 implementation. Prevent IV roll-over; keystream reuse. Prevent bit flip and replay attacks. Ensure data integrity; prevent frame forgeries. To do this, TKIP surrounds the WEP protocol with four new elements: 1. An extended 48-bit IV and IV sequencing rules (compared to WEPs 24-bit IV). 2. Two additional key mixing functions. 3. A method for generating and distributing encryption keys. 4. A Message Integrity Check (MIC) algorithm a.k.a. Michael to ensure messages havent been tampered with during transmission.
Figure 20. illustrates the WPA TKIP encryption process
Figure 20. WPA TKIP Encryption Process
TKIP increases the key size from 40 bits to 128 bits and replaces WEPs single static key with a key that is dynamically generated. In addition, TKIP uses a key hierarchy and key management methodology that removes the predictability which attackers relied on to exploit the WEP key; that is, TKIP replaces WEPs single, manually configured key for some 500 trillion possible keys that can be used on a given data packet.
1-40
April 2, 2008
Technical Education
The protocol employs two S-box mixing functions from which a base key, a 48-bit IV and MAC address of the transmitting device are used to derive the unique 128-bit key. The base key is derived using either the Pairwise Transient Key (PTK) or Group Transient Key (GTK) generated during the 802.1X or PSK authentication process. The S-box mixing functions are designed to prevent weak IV attacks described in section 3.3.1. TKIPs use of an extended 48-bit IV addresses WEPs issue in which the 24-bit IV would roll over in a short period of time resulting in the same keystream being reused to encrypt different messages. With a 48-bit key length the probability of an IV roll-over is highly unlikely, thus making an attack impractical. To further reduce this probability, TKIP mandates that the base key be changed before the IV rolls over, thus preventing the same keystream value from ever being generated. Furthermore, IV sequencing rules specify how IVs are selected and verified. The IV is used as a sequence number and acts as an increasing 48-bit counter. A receiving device will discard any packet associated with the same key where the IV value is less than a previously received packet. TKIPs use of a 48-bit IV and sequencing rules defends against bit flip and replay attacks.
5.2.1 Message Integrity Check

MIC is a cryptographic checksum designed to make it computationally infeasible for an attacker to alter data. The MIC protocol uses an algorithm called Michael, which uses a unique MIC key to generate the MIC value itself, which is then concatenated to the data payload; as illustrated in Figure 21. MIC is an efficient, lightweight algorithm making it inexpensive to implement on radio firmware or wireless NIC cards.
Figure 21. Message Integrity Check

1-41
April 2, 2008
Technical Education
The receiving device checks the CRC, ICV and IV of all packets first before checking the MIC; therefore a MIC failure almost always means an active attack. In addition, TKIP supplements MIC with countermeasures that reduce the rate at which an attacker can make message forgery attempts down to two tries every 60 seconds. If a mobile device detects a MIC failure on the packets received, it sends a MIC failure report. If the WLAN records two MIC failures (i.e. MIC failure reports or failures on received packets) within 60 seconds of each other, all mobile devices are disassociated from the WLAN and will not be allowed to re-associate for the next 60 seconds. Stopping traffic for 60 seconds makes it impossible for an attacker to recover the MIC key. After the 60 second timeout new keys are generated to ensure the attacker cannot obtain any information about the key from the attack.
5.3 Advantages of WPA

Scalable WPA effectively addresses WLAN security requirements for both large enterprise environments and smaller, cost-sensitive environments. Investment Protection WPA can be implemented on most legacy 802.11 hardware via a software or firmware upgrade. Enhanced Security WPA brings three security enhancements to 802.11 networks to address the weaknesses of the original 802.11 security mechanisms; 1. Authentication services provided by 802.1X/EAP secures against man-in-themiddle attacks. 2. Stronger encryption and data integrity provided by TKIP and MIC secures against weak IVs, keystream reuse and bit-flip/replay attacks. 3. Dynamic, per packet encryption keys secures against dictionary attacks.
All Psion Teklogix terminals support WPA security
1-42
April 2, 2008
Technical Education
6.0 IEEE 802.11i (WPA2)

The IEEE 802.11i security standard, adopted by the Wi-Fi Alliance as WPA2, incorporates strong authentication and data encryption mechanisms and effectively represents second-generation 802.11 security to address security concerns for legacy and new 802.11 hardware in AP (infrastructure) and ad-hoc based 802.11 networks. WPA2 supports the following authentication services: 802.1X/EAP Pre-Shared Key (PSK) And supports the following data encryption protocols: TKIP AES-CCMP Although TKIP improves security significantly for legacy hardware, a stronger solution was needed for newer 802.11 hardware. The IEEE 802.11i Task Group members wanted a FIPS (Federal Information Processing Standards) certified solution. As a result, the 802.11i Task Group decided on the Counter-Mode / CBC-MAC Protocol (CCMP). CCMP is based on the Advanced Encryption Standard (AES) block cipher, a FIPS-197 certified encryption algorithm approved by the National Institute of Standards and Technology (NIST). For data encryption AES operates in Counter-Mode and for data integrity AES operates in Cipher Block Chaining-Message Authentication Code (CBCMAC). AES itself is a very strong block cipher, but Counter-Mode makes it extremely difficult for an attacker to spot patterns in messages and CBC-MAC ensures that messages have not been tampered with. Just as with TKIP, AES-CCMP increases the key length from 40 bits to 128 bits. Because 802.11i supports more than one encryption protocol, the standard provides a way for mobile devices and authenticators to negotiate which protocol to use during specific traffic circumstances (i.e. unicast or broadcast traffic) and to discover any unknown security parameters. The mobile device and authenticator must agree on a security scheme during the association process. Other features supported by 802.11i include: Key caching Pre-authentication
1-43
April 2, 2008
Technical Education
Mobile devices often roam back and forth between APs (authenticators). This has a negative effect on the WLANs performance. The basic concept behind key caching is that the mobile device and authenticator maintain their authentication status even when the mobile device roams away from the authenticator. Essentially, key caching stores user information so that if they leave and come back to an authenticator, they don't need to re-enter all their credentials. When the mobile device roams back to the authenticator, the security association can then be restarted. Key caching is based on the fact that the mobile device has previously been associated to an authenticator. Pre-authentication on the other hand enables a mobile device to establish a security association with an authenticator with which the mobile device has never been associated to by sending a pre-authentication packet that's routed through the authenticator the mobile device is currently associated with. Pre-authentication provides a way to establish a security association to a new authenticator before a mobile device has actually roamed to that authenticator allowing for faster roaming between authenticators. It is important to note that not all vendor implementations of 802.11i (WPA2) support features like pre-authentication.
All Psion Teklogix terminals with an 802.11g radio support 802.11i (WPA2) security
1-44
April 2, 2008
Technical Education
7.0 Cisco Compatible Extensions

In early 2003, Cisco introduced their Cisco Compatible Extensions (CCX) program, a nocost licensing program for 802.11 silicon manufacturers. Through the CCX program, Cisco makes their innovative WLAN technology and security features available to participating 802.11 silicon manufacturers, who in turn integrate Cisco WLAN technology into their 802.11 radio reference designs. The CCX program is intended for 802.11 client products only; designed to take full advantage of Ciscos features when implemented in a Cisco WLAN environment. Participants in the CCX program design their client products around CCX Compatible radio reference designs then submit their client products to Ciscos independent thirdparty testing centre to undergo extensive testing. This testing helps to ensure support for Ciscos technology as well as full interoperability with Cisco WLAN infrastructure products. Each CCX version provides new features that improve performance, security, mobility and management. Each new version builds upon the previous version. In addition to Ciscos own unique WLAN technology, CCX also specifies IEEE and Wi-Fi standards such as WEP, IEEE 802.1X, EAP, WPA and IEEE 802.11i (WPA2). Figure 22. illustrates the various features available with each CCX version.
Figure 22. CCX versions and features.

1-45
April 2, 2008
Technical Education
Ciscos CKIP and CMIC are pre-standard versions of WPAs TKIP and MIC and were introduced by Cisco to resolve the known issues with WEP before WPAs standardsbased TKIP and MIC were available. The Cisco Centralized Key Management (CCKM) protocol is Ciscos proprietary key management protocol that provides fast secure roaming of mobile devices in a Cisco based WLAN.
With the integration of the RA2041 802.11g CF radio from Summit, Psion Teklogix mobile devices have received CCX v4 certification status. The RA2041 radio is now available in the following PTX mobile devices: 7530 G2 7535 G2 8525 and 8530 G2 WAP G1 and WAP G2 8515 Ikon
1-46
April 2, 2008
Technical Education
8.0 Putting It All Together

Generally speaking, when you configure any supplicant (Summit Client Utility, Odyssey Access Client, Wireless Zero Config.) you typically configure an authentication method such as PEAP-MSCHAPv2 with an encryption protocol such as AES. Unfortunately, not all supplicants (and radio cards) support all, or the same, authentication and encryption combinations. When making recommendations to the customer, you need to look at the big picture to determine which authentication / encryption combination to deploy. You need to consider all the components that make up the solution; the RADIUS server, the AP / WLAN controller, the supplicant (and radio card), and the backend database. For example, take LEAP authentication with WEP encryption. You can configure this combination using the Summit Client Utility (with the RA2041 radio) and Odyssey Access Client (with the RA2040 radio), but if you are using a Microsoft RADIUS server with a 9160 AP this solution won't work because the Microsoft RADIUS server and 9160 AP don't support LEAP. Another example is EAP-FAST. As mentioned earlier, this authentication method supports a feature known as automatic PAC provisioning, which is supported by the Summit Client Utility. However, if you're using an LDAP backend database, you can't use automatic PAC provisioning, because the LDAP database doesn't support the protocol scheme required by automatic PAC provisioning. In addition to knowing which Psion Teklogix terminals will be deployed, it will also be important to familiarize yourself with the customers infrastructure to determine which security combinations are supported by that infrastructure and which combination offers the most robust security.
1-47
April 2, 2008
Technical Education
9.0 Glossary
ACS (Cisco): AES: AP: CA: CCX: CF: CRC-32: DHCP: EAP: EAPOL: FAST: FDDI: GMK: GTC: GTK: IAS (Microsoft): IBSS: ICV: IEEE: ISAAC: Access Control Server Advanced Encryption Standard Access Point Certification Authority Cisco Compatible Extensions Compact Flash Cyclical Redundancy Checksum 32 Dynamic Host Configuration Protocol Extensible Authentication Protocol Extensible Authentication Protocol over LAN (EAP over LAN) Flexible Authentication through Secure Tunneling Fiber Distributed Data Interface Group Master Key Generic Token Card Group Transient Key Internet Authentication Service Independent Basic Service Set Integrity Checksum Value Institute of Electrical and Electronics Engineers Internet Security, Applications, Authentication and Cryptography Group Initialization Vector Key Scheduling Algorithm
IV: KSA:
1-48
April 2, 2008
Technical Education
LDAP: LEAP: MAC: MIC: MS-CHAPv2:
Lightweight Directory Access protocol Light-weight Extensible Authentication Protocol Media Access Control Message Integrity Check Microsoft Challenge-Handshake Authentication Protocol version 2 Novell Directory Service Network Interface Card One Time Password Protected Access Credential Protected Extensible Authentication Protocol Public Key Infrastructure Pairwise Master Key Point-to-Point Protocol Pre-Shared Key Pairwise Transient Key Remote Authentication Dial-In User Service Summit Client Utility Service Set Identifier Secure Sockets Layer Temporal Key Integrity Protocol Transport Layer Security User Datagram Protocol Virtual Local Area Network Virtual Private Network
NDS: NIC: OTP: PAC: PEAP: PKI: PMK: PPP: PSK: PTK: RADIUS: SCU: SSID: SSL: TKIP: TLS: UDP: VLAN: VPN:
1-49
April 2, 2008
Technical Education
WEP: WLAN: WPA: WZC:
Wired Equivalent Privacy Wireless Local Area Network Wi-Fi Protected Access Wireless Zero Configuration (Microsofts native Windows wireless configuration manager) Exclusive OR (Boolean function)
XOR:
1-50
April 2, 2008

Wireless Security White Paper

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Wireless Security White Paper

Загружено:

Авторское право:

Доступные форматы

Technical Education

An Introduction to 802.11 Wireless Security

TT145 802.11 Wireless Security

TT145 802.11 Wireless Security

TT145 802.11 Wireless Security

TT145 802.11 Wireless Security

TT145 802.11 Wireless Security

TT145 802.11 Wireless Security

2.0 802.11 Security

2.1 802.11 Authentication

Figure 1. illustrates the 802.11 authentication process.

Figure 1. 802.11 authentication process

TT145 802.11 Wireless Security

2.1.1 Open Authentication

Figure 2. Open Authentication using different WEP keys

TT145 802.11 Wireless Security

2.1.2 Shared-Key Authentication

Figure 3. illustrates the shared-key authentication process.

TT145 802.11 Wireless Security

2.1.3 Broadcast of SSID

2.1.4 MAC address authentication

2.2 802.11 WEP

TT145 802.11 Wireless Security

2.2.1 WEP RC4

Figure 4. illustrates the RC4 stream cipher operation.

Figure 4. The RC4 Stream Cipher Operation

TT145 802.11 Wireless Security

2.2.2 WEP CRC-32

TT145 802.11 Wireless Security

Figure 5. The 802.11 WEP Encryption Process

TT145 802.11 Wireless Security

Weaknesses in 802.11 Security

TT145 802.11 Wireless Security

3.0 Weaknesses in 802.11 Security

3.1 Weaknesses in 802.11 Authentication

TT145 802.11 Wireless Security

Figure 6. illustrates the vulnerability of Shared-key authentication to a man-in-the-middle attack.

3.2 Use of SSID and MAC Address Authentication

3.3 Weaknesses with WEP

TT145 802.11 Wireless Security

3.3.1 Weaknesses with the RC4 Stream Cipher

Figure 7. illustrates a bit-flip/replay attack.

TT145 802.11 Wireless Security

Figure 8. Calculating the ICV for a Bit-Flip Attack

TT145 802.11 Wireless Security

3.3.3 Lack of Key Distribution

TT145 802.11 Wireless Security

Enhanced Wireless Security Solutions for 802.11 WLANs

TT145 802.11 Wireless Security

4.0 IEEE 802.1X (Port-Based Network Access Control)

Figure 9. IEEE 802.1X setup

TT145 802.11 Wireless Security

4.1 802.1X Authentication Process

Figure 10. Authenticators controlled and uncontrolled ports

TT145 802.11 Wireless Security

4.2 Dynamic Encryption Keys

TT145 802.11 Wireless Security

Figure 11. 802.1X authentication with dynamic per-packet keying

4.3 EAP Authentication Methods

Figure 12. illustrates the EAP structure.

Figure 12. EAP structure

TT145 802.11 Wireless Security

Figure 13. EAP-TLS Authentication Process

4.3.2 EAP PEAP-MSCHAPv2