Wireless Local Area Network Security
– Obscurity Through Security
Abstract
Since the deployment of infamous Wired Equivalent Privacy (WEP), IEEE and vendors have developed a number of good security mechanisms to restore the public trust on WLANs. As a result, mechanisms, such as RSN, TSN, WPA, and TKIP, have seen the daylight. Unfortunately deploying the new features makes the system more complex. We now have enough security features for building obscure systems from them. The 'keep it simple' -principle is superseded by the new modified slogan. In WLAN networks 'Security through obscurity' has the potential to become 'obscurity through security'. The purpose of this paper is to assist in understanding complex wireless networks by collecting and
summarizing the publicly available information about WLAN security
mechanisms. I will introduce the different WLAN security mechanisms from WEP through WPA to 802.11i. I will also provide a mind-map visualization of the
relations between different specifications and terms. The reader may use the map as assistance while reading this whitepaper. This paper summarizes the flaws of WEP and how new security mechanisms fix or work around them. It serves as a basic introduction to the state-of-the-art security mechanisms in WLANs.
IEEE 802.1X standard related acronyms
o CCP - PPP Compression Control protocol [2]
o EAP - PPP extensible authentication protocol
o EAP-OTP - see OTP
o EAP-GTC - see GTC
o ECP - Encryption Control protocol [2]
o GTC - Generic Token Card
o OTP - One Time Passwords o PPP - Point-to-Point Protocol [3]
802.11b standard related acronyms
o BSS - AP (managed/infrastructure and so forth..) mode
o IBSS - Ad hoc / peer to peer mode o IV - initialization vector [1] Chapter 6.
o ICV - integrity check value [1] Chapter 6. (ICV is similar to the CRC, except that it is computed and added on before encryption
o WI-FI - Wireless Fidelity [3]
o WLAN - Wireless Local Area Network [3]
802.11i and WPA standard related acronyms
o AES - Advanced Encryption standard [1]
o ECB - Electronic Code Book [1]
o ESS - AP (managed/infrastructure and so forth..) mode
o ESN - Enhanced Security Network (Initial name for 802.11i defined net)
o GMK - Group Master Key
o PRF - Pseudo Random Function o TSN - transition security network [4]
o RSN - robust security network [1] Chapter 7.
o TKIP - a suite of algorithms surrounding WEP that is designed to achieve the best possible security on legacy hardware built to run WEP. TKIP adds four enhancements to WEP [5]
o PMK - Pairwise master key [1] Chapter 10. o WPA - Wi-Fi Protected access
o WPA-PSK - WPA Pre-shared key
Other
o ACU - Aironet Configuration Utility
o CMIC - Cisco Message Integrity Check (Different than in 'Michael' in TKIP) o CCKM - Cisco Centralized Key management (Related to roaming
enhancements)
o IAPP - Inter Access Point Protocol (Cisco) [6] o LAN - Local Area Network
o MIC - Message Integrity Check [7]
o MPDU - MAC protocol data unit, MAC -> air [1] Chapter 6. o MPPE - Microsoft Point-to-Point Encryption Protocol[1]
o MSDU - MAC service data unit, software <-> MAC[1] Chapter 6.
o WDS - Wireless Domain Services (Related to roaming enhancements)
o WLCCP - Wireless LAN Context Communication Protocol (WLCCP)
IEEE 802.11 security features
Earlier, the security features in 802.11 were mostly based on Wired Equivalent Privacy (commonly known as WEP) encryption. WEP can no longer satisfy the WLAN users need to feel secure. Consultants have been preaching for years that cracking the WEP encryption is trivial. This probably is the case, but lets consider another viewpoint. According to the 802.11 specification [8][p. 63], Wired
Equivalent Privacy is used to provide data confidentiality comparable to the confidentiality of a wired medium (LAN) without encryption. It was meant to protect the traffic from casual monitoring, nothing more. Additionally, we have learned years ago how to take care of the confidentiality of the data in wired networks anyway. Is the threat in wireless networks so dramatically different that all the fear, uncertainty and doubt is necessary? And more importantly, is
providing unbreakable encryption in data link layer so vital that it justifies all the complexity we are about to implement in WLAN networks? In the following subsections, we will have a brief look on WEP and it's problems.
Wired Equivalent Privacy in general
Original design goals of WEP were [1][p. 13] {IEEE99}[p. 63]:
o It is reasonably strong
o It is self synchronizing
o It is efficient (computationally) o It may be exportable
o It is optional
WEP encryption uses a symmetric stream cipher called RC4. The key is a static shared secret appended to a dynamic 24 bit value, called the initialization vector (IV). With a completely fixed key, RC4 would always produce the same output from a fixed input. [1]. 4 different keys can be pre-configured to WLAN devices. One of the keys will be the active key, which is used for both, encryption and decryption. Rest of the keys may be used for decryption, if necessary.
If manufacturers have implemented the Key Mapping Keys -support, each mobile device can have unique keys. However, according to Edney and Arbaugh,
configuring and maintaining the keys is difficult. Thus many manufacturers do not support Key Mapping Keys. [1]. When key mapping keys are used, two separate keys are required for efficient transmission of packets. One for unicast
messages, and the other for multicast (including broadcast) messages, where message are sent to a group of WLAN devices. Multicast traffic is encrypted with a key known by every mobile device in that multicast group. Unicast traffic is encrypted with a key that is only known by the access point and the
sending/receiving mobile station.
How is RC4 used in WEP?
In RC4 encryption, the secret key, prefixed with a constantly changing initialization vector, is used directly to initialize a Pseudo Random Number Generator (PRNG). The PRNG produces a keystream, which is combined with the plaintext data by using exclusive OR function. It is the keystream that is used for encryption, not the static secret. In decryption, the encrypted message is combined with the same keystream. To calculate the keystream, the receiving party needs to know only the shared secret key in advance as the initialization vector is transmitted unencrypted with the message.
Original secret key length in WEP was 40 bits. 40 bit keylength was considered to be too small for RC4, so manufacturers increased the keylength by 64 bits. However, many manufacturers advertise WEP key length of 128bits. Since when is 40 + 64 = 128? There is an explanation for this breakthrough in mathematics. With longer keylengths 24 bit IV is sometimes added to the final value in the feature list. (Sometimes, it is not.) That is how 104 bits gets the final value of 128 bits. [1].
RC4 is considered to be strong if it is used correctly [1][p.27]. However, making mistakes is not that difficult, as we will later see.
Authentication: Open Authentication and Shared key authentication
The authentication features in 802.11 are simple: 1) In open authentication, mobile station just requests authentication and access point authenticates the station without further questions. When using open authentication it is possible that the mobile station is really authenticated by some other means.
Manufacturers can use proprietary extensions, such as MAC address filters and so forth. 2) In shared key authentication, WEP is utilized. First the station
requests authentication. Then the access point sends a challenge message, a random number which is called the challenge text. The station encrypts the challenge text with WEP and sends the encrypted message back to the access point. Access point decrypts the encrypted challenge and checks that the number was encrypted with correct key. Unfortunately no-one checks if the base station has the correct key. In security terms, there is no mutual authentication. Thus you can set up your own base station and start collecting the responses from the mobile stations. Knowing the contents of the RC4 encrypted message helps cracking the WEP key. Wi-Fi alliance dropped shared key authentication from Wi-Fi compatibility-testing. Probably the only benefit gained from using this feature would be the error message that user gets if he tries to join the network with wrong key. [1] p. 14. Without the shared key authentication, user may
associate with the base station, but the base station silently ignores the data sent with the wrong WEP key. This is explained further in following chapter.
WEP Security Features
Access control is often confused with authentication. [1] p.32. 802.11 does not define how access control is implemented. Many systems implement simple MAC address filtering. However, it is trivial to forge MAC addresses, so it can't be considered a reliable security mechanism. Thus the access control depends on WEP privacy feature. When WEP encryption is in use, all data must be
encrypted. If the mobile station does not have the correct WEP key, the integrity check value in the packet will be incorrect and the base station drops the packet silently.
WEP has no replay protection, so the attacker can re-send already seen packets. It is also possible to modify these packets. However it is not as trivial as simply resending. WEP includes a checkfield called the integrity check value (ICV). Check value is computed from the plaintext data before encryption. The value is appended to the plaintext, and encrypted among with rest of the data. The idea of ICV was to provide integrity protection - since ICV is also encrypted, you can not correct it if you modify the content. However, it turned out that it is possible to predict which bits in the ICV will change if you modify a single bit in the message. And if you just change the bits in ICV, you don't need to know its plaintext value. Due to the way of using XOR in RC4, bit flipping encrypted text will have a corresponding effect in plaintext. [1][p. 33-34].
WEP privacy has some weaknesses. According to Edney and Arbaugh [1], there are three ways to attack RC4 privacy in WEP. 1) IV reuse, 2) RC4 weak keys
and 3) Direct key attack. The idea behind using IV reuse attack is following: RC4 with a static key is a bad idea, since it outputs the same keystream per encrypted frame. If the attacker figures out the keystream produced with that key, he can decrypt every frame without knowing the actual key. XORing the known
keystream and the encrypted message gives the plaintext. If we add IV value to the key every time RC4 is initialized, we get different key stream for every frame. Almost. The amount of IVs is limited and they will be reused. Over a period of time, the attacker will be able to collect several frames encrypted with the same IV. That helps in guessing substantial portions of the key stream and decoding the message will become easier and easier. And if the attacker succeeds in decrypting one complete frame with certain IV, he will be able to decrypt all frames using that IV. Additionally, the attacker can send forged frames with that IV. [1]
RC4 weak keys
In RC4, generating proper pseudo random key streams is important. The pseudo random number generator algorithm used in RC4 is powerful[1] [p. 34]. However, there are some issues that need to be taken into account. For instance, with certain IV values, you get less entropy than with others. The weak IV attack is based on this fact.
For proper encryption, even a slightest change in the encryption key should result in a totally different keystream. Fluhrer et al. [9] have shown that this is not the case with certain key values in RC4. The first bytes in certain keys correlate to the first bits in the pseudo random keystream. Since the IV is public (sent within the frame) in WEP, the attacker can monitor for weak keys and directly attack the key. With network traffic there is also a twist. The contents of first bytes in each frame are easy to guess, since they contain very predictable protocol headers. If the attacker collects the frames with weak IV:s and he can guess the part of the content of the encrypted message, he will be able to figure out the secret key byte by byte. According to Edney and Arbaugh [1] p. 37, this is the most serious flaw in WEP.
IEEE 802.11i
IEEE 802.11i introduces a new set of security mechanisms for wireless networking. It should solve several problems in 802.11b and WEP:
o Poor Privacy
o Lack of encryption key management o Weak authentication and authorization
o No Accounting
"IEEE 802.11i defines a new type of wireless network called Robust Security Network (RSN)" [1]p. 40. The Robust Security Network brings the concept of security contexts to WLANs. It means that after authentication, the authenticated entity will have a set of privileges for a limited amount of time. The idea is similar
to the passport system. The government authenticates citizens and gives them passports, that expire after certain amount of time. Citizens can use passports to get access from one country to another. In traditional 802.11 networks, there is no unambiguous way of checking the identity of a WLAN user. There are only users possessing the shared secret and users who do not. The access point ignores without warning the users with the wrong key. [1].
Devices joining in a RSN need a set of new capabilities. One of them is support for a new security protocol built around the Advanced Encryption Standard (AES). The new protocol is called Counter Mode-CBC MAC protocol (CCMP). Unfortunately upgrading WEP enabled products to CCMP requires hardware upgrades. Old 802.11 devices provide only RC4. CCMP requires AES support. To address this problem RSN allows the use of TKIP, which uses RC4 but has several workarounds for the weaknesses in WEP.
In a true Robust Security Network, only those devices that support the RSN requirements may join the network. To support the transition from WEP to TKIP, a network model called Transition Security Network was defined. Transition Security Network allows so called Pre-Robust Security Network Associations. This means that WEP users using RC4 can coexist within the same wireless local area network with 1) CCMP users who use AES and 2) TKIP users who use RC4 and security enhancements. [4].
Key hierarchy
Just like in WEP, 802.11i security features are based heavily on encryption and encryption keys. However, 802.11i has a disparate mind-set. Encryption keys are generated by using a more complicated set of algorithms. Keys are changed periodically and users get unique encryption keys. In 802.11i, WEP is replaced with another encryption scheme. RC4 will be replaced with AES, although RC4 can be used for backward compatibility. If RC4 is used, it is used in a way that works around the known weaknesses of WEP. The ciphersuite which provides the workarounds is called TKIP.
802.11i uses unique encryption keys for different tasks. Keys are derived either from a preshared secret or they are generated with the help of a more
complicated upper layer authentication infrastructure. The correct terms for the keys are preshared keys and server-based keys. There is a fundamental difference between preshared keys in 802.11i and the shared secret in WEP. Preshared keys are not used directly in encryption. They are used to generate unique keys per mobile device. The actual encryption keys can change
frequently. Dynamically changing encryption keys are called the Temporal Keys. The advantages of Temporal Keys will be discussed next.
Since mechanisms for generating keys are available, we can generate unique keys for each mobile device. With TKIP, separate keys are used for encryption and integrity whereas AES-CCMP uses single key for both. AES has integrity and encryption combined into a single calculation. [1][p. 121] For efficient communication we also create non-unique keys for multicast traffic. Otherwise
the base station should send the multicast message separately to each mobile station. This completely defeats the advantage that comes from using multicasts. Fortunately having several keys is possible since the original WEP standard allowed storing up to four keys to the mobile device.
As a summary, key hierarchy has the following items for pairwise/group encryption/integrity:
o Pairwise Master Key (PMK) for pairwise communication. The key includes:
EAPOL-Key Encryption key EAPOL-Key Integrity key Data Encryption Key
Data Integrity key
o Group Master Key (GMK) for multicast traffic. GMK includes: Group Encryption key
Group Integrity key
AES-CCMP
CCMP is based on Advanced Encryption Standard (AES) in CCM-mode. This mode was developed for 802.11i, but it is can be used in wider scope. CCM-mode is submitted for NIST as a general CCM-mode for AES. IETF has also issued RFC 3610 - 'Counter with CBC-MAC (CCM)' - for using CCM mode with IPSec
[10]. Furthermore, AES itself is based on the Rijndael encryption algorithm. Rijndael allows 128, 192 and 256 key and block sizes. 802.11i favors simple implementations and minimizes user confusion by limiting the key and block size to 128. [1][p. 162] (Remember the WEP confusion: 40bit vs 104bit / '64bit' vs '128bit' sizes, some counted 24 bit IV, some didn't). AES has different modes of operation. It has for example a mode called Electronic Code Book (ECB). ECB-mode has the familiar problem: if input blocks have the same data, also the encrypted blocks will be the same. When encrypting data, we usually want to hide as much information as possible. Thus ECB-mode is not used widely.
CCM-mode uses counter mode and CBC-MAC. The counter mode works in a following way. Instead of directly encrypting the data, an arbitrary value called counter is encrypted. The message is then XORed with the encrypted value of counter. The counter value is changed for every block so even if the plaintext data blocks are similar, encrypted blocks are different. The counter is constructed from a nonce which includes the sequence counter, source MAC address and priority fields. This value is joined with Flag and Counter (Ctr) fields. The 16 bit Ctr value starts at 1 and increments as counter mode proceeds. Thus there will be unique counter values for 65536 blocks, which is well enough for the larges MPDU allowed in IEEE 802.11i [1]
CBC-MAC is used for verifying the integrity of the message. The method is simple: 1) take the first block of the message and encrypt it, 2) XOR the result with the second block and encrypt the result, 3) XOR the result with next block and so on. As a result, there is one 128-bit block that is dependent on all the data
in the message. If one bit of the message changes, the block will be completely different.
In CCMP frames that are actually transmitted over radio link are encrypted. Message integrity check (MIC) includes the Medium Access Control header, thus address spoofing is not as trivial as it is with 802.11b. CCMP header is included unencrypted. It provides information for the receiver to derive the nonce value that was used in encryption. Also in the case of multicast, CCMP header tells the receiver which multicast key was used.
In decryption, the selection of keys is based on the source MAC address. After the packet number value in CCMP header is verified, the decryption takes place. The counter value is calculated from the information available on the packet. The sequence number, source MAC address and priority values are used to create the nonce. The nonce is combined with known flag value and the start Ctr value to create the initial counter. After that the process is the same, except that the XOR reverses the previous encryption.
Wi-Fi Protected Access (WPA)
Originally, the Wi-Fi alliance was formed to ensure the compatibility of 802.11 devices. The specification had some ambiguities and left some room for vendors to make such implementation choices that products were not compatible
between each other. Wi-Fi certification required that products are compatible to the subset of 802.11 specification with some Wi-Fi extensions [1] Chapter 7.
Now Wi-Fi alliance offers a subset of IEE802.11i: Wi-Fi Protected Access (WPA). The Wi-Fi alliance created it because the industry could not wait until the lengthy process of 802.11i standard ratification was complete. Wi-Fi alliance adopted new security approach based on the draft version of RSN but only specifying the TKIP security mechanism [1].
WPA also has a simplified operation mode for users without centralized authentication. It is called WPA-PSK (PSK as preshared key). The difference between WPA and WPA-PSK is that in WPA-PSK you will use a preshared key locally in the access point. Again, what is the difference between WEP and WPA-PSK encryption key usage? You probably guessed the answer. Just like in 802.11i, the secret is not used directly for encryption. It is used for deriving the actual encryption keys.
Temporal Key Integrity Protocol (TKIP)
AES was selected for 802.11i before all the flaws in WEP were well known. It was thought that the time can take care of transition from WEP to AES. However, when all the flaws of WEP were unravelled, there was a sudden need to replace WEP faster than expected. This is where TKIP steps into the picture.
Edney and Arbaugh say that TKIP provides huge security improvements over WEP, while the same equipment can be used [1][p. 137]. TKIP can also be
applied in older Wi-Fi systems with firmware upgrades. The only reason it was developed was to allow WEP systems to be upgraded to be more secure. [1]. According to Cisco's access point configuration manual [6], the following workarounds are used to achieve this noble, worthy, goal:
A per-packet key mixing function to defeat weak-key attacks
A new IV sequencing discipline to detect replay attacks
A cryptographic message integrity check (MIC), called Michael, to detect forgeries such as bit flipping and altering packet source and destination
An extension of IV space, to virtually eliminate the need for re-keying
In addition, Edney and Arbaugh [1] mention also the mechanism to distribute and change the broadcast keys [1][p. 140].
WPA Integrity and Confidentiality key management
For providing confidentiality, WPA provides slightly different key management compared to plain 802.1X+WEP combination. According to Microsoft Knowledge Base Article - 815485: "With 802.1X, the rekeying of unicast encryption keys is optional. Additionally, 802.11 and 802.1X provide no mechanism to change the global encryption key used for multicast and broadcast traffic. With WPA, rekeying of both unicast and global encryption keys is required. For the unicast encryption key, the Temporal Key Integrity Protocol (TKIP) changes the key for every frame, and the change is synchronized between the wireless client and the wireless access point (AP). For the global encryption key, WPA includes a facility for the wireless AP to advertise the changed key to the connected wireless
clients." [11].
With WEP the integrity protection was poor. In WPA, a new method called Michael is used to protect message integrity. Microsoft describes the Michael as follows: "With WPA, a method known as Michael specifies a new algorithm that calculates an 8-byte message integrity code (MIC) using the calculation facilities available on existing wireless devices. The MIC is placed between the data portion of the IEEE 802.11 frame and the 4-byte ICV. The MIC field is encrypted together with the frame data and the ICV." [11].
According to Edney and Arbaugh [1] Michael is not a very strong algorithm. However, it was the best choice given the constraints: it should not be intensive for existing devices to process. Additionally, to get to the point where MIC is verified, the attacker needs to get past the IV replay protection and ICV
decryption check. However, the 802.11i task group considers the one in a million chance for the valid MIC to be large enough, that countermeasures are required for brute force attacks. In a case of brute force MIC attack, keys for the link are disabled and the Michael 'Blackout' rule dictates 60 second delay for new key generation.[1] The methods for detecting MIC attacks are rather simple. Both the supplicant and the access point may detect attacks using different methods. Due to the impracticality of the attack and the length limitations of this whitepaper, I
advise the reader to read the chapter 'Message Integrity Check' from the book by Edney and Arbaugh [1] to find out about the details of attack detection methods.
802.1X
Confusingly, 802.1X is not a 802.1 related substandard done by task group x. Instead, the capital X implicitly hints that 802.1X is a top-level IEEE standard. It is a very common mistake to use lower case in the specification name. IEEE
802.1X is a standard for providing port based access control to local area networks. By combining 802.11, 802.1X (which includes EAP and Radius) we have a wireless security solution which scales from home networks to large enterprises.
The following terms are essential in 802.1X:
o Supplicant - an entity that wants to have access
o Authenticator - an entity that controls the access gate
o Authentication server - an entity that decides where the supplicant is to be
admitted
PPP extensible authentication protocol (EAP)
EAP (RFC2284) is utilized heavily in 802.1X specification. It provides an extensible framework for utilizing upper layer authentication methods, such as TLS. EAP has 4 message types that are used for 1) signaling failure or success and 2) delivering upper layer methods between the authenticator and supplicant. The message types and some example subtypes are:
o Request
o Response o Success o Failure
Examples of subtypes for Request/Response that are defined in original EAP RFC are:
1. Identity 2. Notification
3. Nak (Response only) 4. MD5-Challenge 5. One-Time Password 6. Generic Token Card
Of these, types 1-4 are mandatory. [12]
EAP over Local Area Network (EAPOL)
According to Edney and Arbaugh[1], EAP was originally designed for dial-up authentication via modem. To utilize EAP in local area network context, 802.1X defines a protocol called EAP over LAN (EAPOL). EAPOL uses five different types of messages for aiding the use of EAP in Local Area Networks:
o Start o Key o Packet
o Logoff
o Encapsulated-ASF-Alert
Edney, J. and Arbaugh, W.. (2003). "Real 802.11 Security: Wi-Fi Protected Access and 802.11i". ISBN: 0-321-13620-9. .
Start may be used in initializing the authentication process. The EAPOL-Key is used by the authenticator to deliver encryption keys to supplicant when it has decided to allow the access. EAPOL-Packet carries the EAP packets. EAPOL-Logoff is used for signaling the authenticator that the supplicant is logging off from the network. However, spoofing EAPOL message sources is easy. Since the Logoff message has no additional means to verify the source, implementations typically ignore these messages. However, they listen to similar lower layer 802.11 disassociation requests. This renders the decision to ignore EAPOL-Logoff weird. Another ignored message is Encapsulated-ASF-Alert. It is used for sending management alerts to the system. Again, accepting
unauthenticated 'management' messages are not seen wise. Why you trust other messages, you may ask. Because with EAPOL-Key and EAPOL-Packet the integrity and confidentiality can be assured on upper layer. In other words, the content of these packets may be authenticated. EAPOL-Start is not
authenticated, but its purpose is just to initialize the authentication process, which should fail on later stages if something is wrong.
EAP methods
The purpose of this subsection is to summarize some of the EAP methods that have been fashionable during the last year or two. Basically the summaries are quotes from specifications (or drafts). I will also provide a link to those
specifications as a pointer for more information.
PPP EAP TLS Authentication Protocol (EAP-TLS)
EAP-TLS is one of the first EAP-authentication methods that was implemented. One of the aspects that was of interest to some was that the users would not need passwords. We could just install a certificate in the device and everything would be taken care of. Unfortunately this is a two-edged sword since proper certificate management is difficult.
EAP-TLS also introduced mutual authentication in the WLAN context. According to Aboba et al [2] EAP methods prior EAP-TLS had focused only on
authenticating the user. EAP-TLS was the first EAP method to provide mutual authentication.
"Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. This
document describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mechanisms within EAP." [2]
The EAP-TLS specification [2] does not list features explicitly.
o Mutual authentication o Key derivation
o ECP (Encryption Control Protocol) negotiation
Tunneled TLS Authentication Protocol (EAP-TTLS)
Soon after EAP-TLS, EAP-TTLS put username & password based user
authentication back in business. The network could still provide a certificate as proof of its identity. Funk and Blake-Wilson describe EAP-TTLS:
"EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection
established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication
infrastructures such as RADIUS. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other cryptographic attacks. EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake." [13]
PEAPv2
In version 7 of Protected EAP Protocol Version 2 Internet draft Palekar et al define PEAP as follows: "By wrapping the EAP protocol within TLS, Protected EAP (PEAP) Version 2 addresses these deficiencies in EAP or EAP methods. TLS provides per-packet encryption, authentication, integrity and replay
protection of the EAP conversation." [14]
Additionally, they list following benefits for PEAPv2:
o Dictionary attack resistance
o Protected negotiation o Header protection o Protected termination
o Fragmentation and Reassembly o Fast reconnect
o Sequencing of multiple EAP methods
o Protected exchange of arbitrary parameters (TLVs) [14]
EAP-FAST
Cam-Winget et al. [15] summarizes EAP-FAST in their Internet draft version 0:
" EAP-FAST enables secure communication between a client and a server by using the EAP based Transport Layer Security (EAP-TLS) to establish a mutually authenticated tunnel. However, unlike current existing tunneled authentication protocols, EAP-FAST also enables the establishment of a mutually authenticated tunnel by means of symmetric cryptography. Furthermore, within the secure tunnel, EAP encapsulated methods can ensue to either facilitate further provision of credentials, authentication or authorization policies by the server to the client."
Following features are listed as primary design goals in the draft:
o Mutual Authentication
o Immunity to passive dictionary attacks
o Immunity to man-in-the-middle (MitM) attacks
o Flexibility to enable support for most password authentication interfaces
o Efficiency (specifically when using wireless media) o Minimal deployment requirements
o Flexibility to support other provisioning mechanisms
[13]
EAP-SIM
Haverinen et al describe EAP-SIM [16] as follows: "This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the GSM Subscriber Identity Module (SIM). The mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support and a re-authentication procedure."
EAP-AKA
"This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authentication and session key distribution using the Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (AKA) mechanism. UMTS AKA is based on symmetric keys, and runs typically in a UMTS Subscriber Identity Module, a smart card like device."
"EAP AKA includes optional identity privacy support and an optional re-authentication procedure." [17]
Summary
The following table summarizes the explicitly advertised features in the open standards. Implicitly mentioned features are left out in order to avoid
interpretation mistakes. The names of the features are unified, so some of the features are not under exactly the same name.
Table 1.1: EAP type features as manifested in specifications
EAP type\feature EAP-PEAPv2 EAP-FAST EAP-TLS EAP-TTLS EAP-SIM EAP-AKA
Reference [14] [15] [2] [13] [16] [17]
Mutual authentication X X X X X X
Mandatory mutual auth - - - - X X
Inner EAP method X X - - - -
Optimized session resumption X - - - - - Fragmentation & reassembly X - - - - - Key Derivation X X X X X X Man-in-the-middle protection X X - X - - Fast reconnect X - - - X X Protected negotiation X - - - - - Header protection X - - - - - Protected termination X - - - - -
Dictionary attack resistance X X - X X X
Efficiency - X - - - -
User identity protection X X - X X X
Support for most password
interfaces X X - - - -
Minimize per user authentication state requirements - X - - - - Protected notification/termination X - - - - -
Sequences of EAP methods X - - - - -
Generic way to exchange arbitrary parameters in a secure channel
X - - - - -
References
[1]
Edney, J. and Arbaugh, W.. (2003). "Real 802.11 Security: Wi-Fi Protected Access and 802.11i". ISBN: 0-321-13620-9.
[2]
Microsoft. (1999). "PPP EAP TLS Authentication Protocol ".
Frontier_Whitepaper-wots_rfc2716.txt. [Accessed: 2004-03-31]. [3]
University College Cork. "Acronym Server". http://www.ucc.ie/cgi-bin/acronym. [4]
IEEE. (2003). "IEEE standard 802.11i draft 7". [5]
Cisco. (2004). "Configuring Cipher Suites and WEP".
http://www.cisco.com/en/US/products/hw/wireless/ps4570/products_configuration _guide_chapter09186a0080184aca.html. [Accessed 2004-02-23].
[6]
Cisco. (2004). "Cisco Fast Secure Roaming".
http://www.cisco.com/warp/public/cc/pd/witc/ao1200ap/prodlit/cifsr\_rf.pdf. [Accessed 2004-02-24].
Bowman B.. "WPA Wireless Security for Home Networks".
http://www.microsoft.com/WindowsXP/expertzone/columns/bowman/03july28.as. [8]
IEEE. (1999). "Wireless LAN medium access control (MAC) and physical layer (PHY) specifications. (IEEE Standard 802.11)".
[9]
Scott Fluhrer and Itsik Mantin and Adi Shamir. Weaknesses in the Key Scheduling Algorithm of RC4. (2001).
http://citeseer.nj.nec.com/fluhrer01weaknesses.html. [Accessed 2004-04-16]. Lecture Notes in Computer Science. 2259.
[10]
Whiting and Housley and Ferguson . (2003). "Counter with CBC-MAC (CCM) ".
Frontier_Whitepaper-wots_rfc3610.txt. [Accessed: 2004-06-14]. [11]
Microsoft. (2004). "Overview of the WPA Wireless Security Update in Windows XP". http://support.microsoft.com/?kbid=815485#8. [Accessed: 2004-05-17]. [12]
Network Working Group. ( 1998 ). "RFC2284".
http://www.faqs.org/rfcs/rfc2284.html. [Accessed: 2004-03-30]. [13]
Func Software Inc. (2003). "EAP Tunneled TLS Authentication Protocol".
Frontier_Whitepaper-wots_draft-ietf-pppext-eap-ttls-03.txt. [Accessed: 2004-03-31].
[14]
Cisco and Microsoft. (2004 ). "Protected EAP Protocol (PEAPv2) (draft) ".
Frontier_Whitepaper-wots_draft-josefsson-pppext-eap-tls-eap-07.txt. [Accessed: 2004-03-31].
McGrew D., Salowey J. and Zhou H.. ( 2004 ). "EAP Flexible Authentication via Secure Tunneling (EAP-FAST) (work in progress)". http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-00.txt. [Accessed: 2004-03-31].
[16]
Nokia and Cisco. (2003). "EAP SIM Authentication ". Frontier_Whitepaper-wots_draft-haverinen-pppext-eap-sim-12.txt. [Accessed: 2004-03-31]. [17]
Ericsson and Nokia. (2003). "EAP AKA Authentication ". Frontier_Whitepaper-wots_draft-arkko-pppext-eap-aka-11.txt. [Accessed: 2004-03-31].
