1

IEEE 802.11: Security

Akshay Garg

Abstract—This paper gives an overview of the securityfeatures in the IEEE 802.11 networking standard. We start bydescribing the Wired Equivalent Privacy (WEP) algorithm andemphasize on its security vulnerabilities. Next we specify thedesign goals behind the IEEE 802.11i security standard andexplain how it addresses the security risks of WEP. Section5 describes the Wi-Fi Protected Access (WPA) protocol andhighlights some basic differences between WPA and WPA2.WPA implements majority of the IEEE 802.11i standard, andwas intended as an intermediate measure to take the placeof WEP while 802.11i was being prepared. WPA2 certificationmark on the other hand indicates compliance with an advancedprotocol that implements the full 802.11i standard. Section 6describes the Extended Authentication Protocol. We concludeour paper by giving limitations of the 802.11i standard and thesteps that could be taken to resolve these issues.

I. Wired Equivalent Privacy

WEP is a security protocol for the IEEE 802.11based wireless local area networks (WLANs). It is aLink layer (Layer 2) protocol and was designed to givewireless networks the equivalent level of privacy asa comparable wired network. The three basic securityservices defined by IEEE for a Wireless LAN environmentare: Authentication, Confidentiality and Integrity. WEPtries to address all three issues [1]:

1) Authentication: A primary goal of WEP was con-firming the identity of all the communicating clientstations. This prevents access to the network byuntrusted clients that cannot authenticate properly.

2) Confidentiality: Confidentiality was the second goalof WEP. The intent was to prevent information leakto unauthorized users.

3) Integrity: Another goal of WEP was to ensure thatthe messages are not modified in transit betweenwireless clients and access points.

A. Authentication

An access point must authenticate a station before thestation can associate with the access point or communicatewith the network. The IEEE 802.11 standard defines twotypes of WEP authentication: Open System and SharedKey [1].

1) Open System authentication (OSA): In OSA, accesspoint accepts a mobile station without verifying theidentity of the station. The following steps occurwhen two devices use Open System Authentication(see Figure 1):

• The station sends an authentication request tothe access point.

• The access point authenticates the station.• The station associates with the access point

and joins the network.

A client is authenticated if it simply responds witha MAC address during the two-message exchangewith an access point. During the exchange, theclient is not truly validated but simply respondswith the correct fields in the message exchange. Wecan see that OSA allows easy unauthorized accessto the network.

2) Shared key authentication (SKA): SKA is acryptographic technique for authentication. It isa simple "challenge - response" scheme based onwhether a client has the knowledge of a sharedsecret. The following steps occur when two devicesuse Shared Key Authentication (see Figure 2):

• The station sends an authentication request tothe access point.

• The access point sends challenge text to thestation.

• The station uses its configured 64-bit or 128-bitdefault key to encrypt the challenge text, and itsends the encrypted text to the access point.

• The access point decrypts the encrypted textusing its configured WEP key that correspondsto the station’s default key. The access pointcompares the decrypted text with the originalchallenge text. If the decrypted text matches theoriginal challenge text, then the access point andthe station share the same WEP key, and theaccess point authenticates the station. Otherwiseaccess is not granted.

• The station connects to the network.

The algorithm used in the cryptographic computa-tion and for the generation of the 128-bit challengetext is the RC4 stream cipher. It should be notedthat the authentication method described abovedoes not provide mutual authentication. That is, theclient does not authenticate the AP. Thus there isno assurance that a client is communicating with alegitimate AP and wireless network.

B. Confidentiality

The WEP cryptographic technique for confidentialityalso uses the RC4 symmetric key, stream cipher algorithm.When WEP is active in a wireless LAN, each 802.11

2

packet is encrypted separately with an RC4 cipher streamgenerated by a 64-bit RC4 key. This key is composedof a 24-bit initialization vector (IV) and a 40-bit WEPkey. The encrypted packet is generated with a bitwiseexclusive OR (XOR) of the original packet and the RC4stream. The IV is chosen by the sender and can be changedperiodically so every packet won’t be encrypted with thesame cipher stream. The IV is sent in the clear with eachpacket. The WEP privacy is illustrated in Figure 3. Asdefined in the 802.11 standard, WEP supports only a 40-bit cryptographic keys size for the shared key. However,many vendors offer nonstandard extensions of WEP thatsupport key lengths from 40 bits to 104 bits. The 104-bitWEP key, for instance, with a 24-bit Initialization Vector(IV) becomes a 128-bit RC4 key.

C. Integrity

The IEEE 802.11 WEP standard also provides a meanto ensure data integrity for messages transmitted betweenwireless stations and access points. Integrity services weredesigned to reject any message that had been changed byan adversary in the middle. This technique uses a simpleencrypted Cyclic Redundancy Check (CRC) approach,where a CRC-32, or frame check sequence, is computedon each payload prior to transmission (see Figure 3).The payload along with the CRC is then encryptedusing the RC4 key stream to provide the cipher-textmessage. On the receiving end, decryption is performedand CRC is recomputed on the payload portion of thereceived message. This CRC is then compared with theone attached to the payload. If CRCs are not the same,it indicates that packet has been modified in transit,and it should be discarded. This seems a simple way ofensuring message integrity however it is not as secure asusing a hash function or a Message Authentication Code.CRC calculation is briefly explained below [19].

1) CRC Calculation: To compute an n-bit binaryCRC, line the bits representing the input in a row, andposition the (n+1) bit pattern which is the CRC’s divisorunderneath the left-hand end of the row. First calculationfor computing a 3 bit CRC is shown below [19]:

If the input bit above the leftmost divisor bit is 0, donothing and move the divisor to the right by one bit.If the input bit above the leftmost divisor bit is 1, thedivisor is exclusive-ORed into the input. The divisor isthen shifted one bit to the right, and is XORed withthe result of the previous stage. This process is repeateduntil the divisor reaches the right-hand end of the input

row. Given below is the last calculation:

Since the leftmost divisor bit zeroes every input bitit touches, when this process ends the only bits in theinput row that can be nonzero are the n bits at the right-hand end of the row. These n bits are the remainderof the division step, and will also be the value of theCRC function. More information on the calculation andmathematics behind CRC functions can be found in [19].

II. Security Vulnerabilities of WEP

In course of time, a number of security vulnerabilitieswere identified in the WEP protocol. In the year 2000-2001 a series of papers were published that proved thatWEP and the RC4 algorithm it used, failed to providethe security it claimed to ensure [16]. We will look at thesecurity vulnerabilities of WEP in the three major areasreferenced earlier.

A. Authentication

The shared-key authentication method of WEP isdeficient in providing a secure means of authenticatinga station to an access point. Not only is it insecure, butit uses the same WEP key for authentication challengesand encryption. This leaves the door open for attacksduring the authentication exchange that can lead to theloss of integrity of the entire process. Using a passiveeavesdropping attack, an attacker can listen in on one-part of the authentication exchange. The attacker canthen decipher the secret key used to XOR the plaintext.The process is as follows [9]:

1) An attacker obtains the plaintext challenge (P) thatthe access point sends to the station during step 2of the authentication phase (see Figure 2).

2) During step 3, the station XORs the plaintext (P)with the secret key (S) to create ciphertext (C).The attacker also has the encrypted response at thispoint.

3) Using the fixed structure of the protocol, theattacker can do P ⊕ S = C to decipher the WEPkey used in the exchange.

After these vulnerabilities were discovered, it wasdeemed that the shared-key authentication process wasinsecure and unnecessary. Insecure because of the abilityto spoof the identity of an attacker as a valid client andunnecessary because it caused more harm than good. Byallowing the discovery of the WEP key during the au-thentication process, the integrity of the entire encryption

3

process is compromised due to the fact that the same WEPkey is used for both authentication and WEP encryption.Few users now use shared-key encryption and simply settheir wireless devices to open authentication allowing thedevices to negotiate their association with a predeterminedkey. This at least prevents an attacker from discoveringthe WEP key by intercepting the authentication exchange.

B. Encryption

1) IV Reuse: Given the limitation of Shared KeyAuthentication suppose a user opts for Open SystemAuthentication (OSA). The most critical part stillremains the protection of the WEP key used in theencryption process. To ensure this the RC4 stream cipheris initialized to a different state everytime we encrypt apacket. This is done by adding a random value known asInitialization Vector (IV) to the WEP key. IV is changedbefore every frame encryption. This combined with theuse of the RC4 algorithm provides confidentiality toWLAN communication.

However, recently the security community has raisedsome issues with IV reuse [20]. As mentioned before, theIV used in WEP is 24 bits long. This gives WEP thepossibility of 224 different IV values. The fact that the IVis 24 bits creates a very real possibility for IV collision.IV collisions occur when duplicate IVs are used. Thechances of duplicate IVs are as follows [20]:

• 1% after 582 encrypted frames• 10% after 1881 encrypted frames• 50% after 4,823 encrypted frames• 99% after 12,430 encrypted frames

Once an attacker begins to find duplicate IVs, theycan begin to create an IV-WEP key combinationdatabase that can be used to either inject packets intoa conversation or simply decode broadcast traffic. Acomplete database of WEP keys of any length with theircorresponding IVs can easily be stored on todays typicalhard drives.

2) RC4 Weak Keys: In 2001 Scott Fluhrer, ItsikMantin, and Adi Shamir published a paper "Weaknessesin the Key Scheduling Algorithm of RC4" which identifiedvulnerabilities in the RC4 algorithm itself. They discov-ered that certain keys had bits that when changed hada greater effect on the XORed data than others. Therewere also bits that when changed had no effect whatsoeveron the output. They called these keys weakkeys. Thiscombined with that fact the keys are tied to IVs wouldguarantee that if a weakkey is found, it could be exploited.They also discussed an attack on WEP which searches fora weakkey and deciphers the secret key byte by byte. Thisattack is now exploited with products like Airsnort thatcan discover WEP keys in a matter of hours in some cases.

C. Integrity

Once the encryption mechanism of WEP is broken,any WEP packet can be decrypted. WEPs integritycheck mechanism i.e. the CRC can also be decipheredonce the key is public. An attacker can now intercept atransmission, tamper with the payload, and change theCRC to a new value to disguise the message as unchangedduring transmission.

III. IEEE 802.11i: Goals behind the Standard

As we saw in the previous section, WEP offers noprotection against even a casual hacker. Security risksassociated with WEP made IEEE and the Wi-Fi alliancerealize the need to create a new standard. They createdsomething known as 802.11i. An addendum to the 802.11standard, 802.11i when implemented correctly, createswhat are called RSNs or Robust Security Networks. Itintroduces policies that scale much better than WEP andacts as an international standard that can be followed tosecure WLANs. Basic goals behind the 802.11i standardwere as follows [22]:

1) Develop 802.11i through a process open to all

• Anyone must be able to fully implement theentire standard or any part of it i.e. no secretalgorithms

2) Market driven feature development

• Address all perceived security problems of WEP• Maximize the security achievable with existing

authentication databases• Do NOT address problems market does not care

about• Provide backward and forward compatibility• Deliver as rapidly as possible

3) Separation of concerns

• Do not duplicate work done elsewhere, like theIETF

4) Flexible architecture adaptable to different deploy-ment models

• Enterprise, Small business, consumer and home,and perhaps operator

5) Obtain outside review of design

• To minimize chances of another WEP

IV. IEEE 802.11i Framework

IEEE 802.11i specified new standards for authentica-tion, encryption, key management and message integrity.Given below is a detailed description of the 802.11i stan-dard wrt these features. We would differentiate betweenthe WPA and WPA2 versions of 802.11i in later sections.

4

A. Authentication (802.1x)

802.11i implements 802.1x for user authentication andkey distribution. 802.1x is a port-based authenticationmechanism used for both wired and wireless networks.802.1x can be used in conjunction with upper layerauthentication protocols (explained later) to provideaccess to the network. It can block access to networkresources until a station is properly authenticated toan access point. The 802.1x authentication model iscomprised of three types of roles assigned to 802.1x-enabled devices. These roles are supplicant, authenticator,and authentication sever [2].

1) A supplicant is a wireless client who is requestingaccess to network resources. The client must have802.1x capable software installed.

2) An authenticator can be a switch running 802.1x,but here we will assign the role to an 802.1x capableaccess point.

3) An authentication server, which for our purposeswill be a Radius server [17].

Figure 4 is an example of the integral devices and theroles they play in 802.1x authentication. 802.11i alsoallows an access point to fulfill multiple roles. For example802.11i capable access points can act as authenticatorsand authentication servers at the same time.

1) Controlled/Uncontrolled Ports: As mentioned,802.1x grants per-port access to clients requesting accessto network resources. There are two main types ofports in 802.1x: uncontrolled ports and controlled ports.Uncontrolled ports allow communication between deviceson a LAN without having to make an access controldecision. In a typical 802.11i environment, uncontrolledports are only used for the authentication exchangethat occurs between the devices shown in Figure 4. Acontrolled port is an entry point to the LAN resourcesa supplicant requests access to and the same resourcesan authenticator is there to protect. Until a client isauthenticated by the authentication server, the onlyport that allows communication is the uncontrolled port.Figure 5 provides a visual representation of the two typesof ports discussed above. This diagram shows both theuncontrolled port used for authentication requests and thecontrolled port in its pre-authentication setting (left) andpostauthentication setting (right.) As we can see, whena supplicant is successfully authenticated, the controlledport is considered authorized and communication throughthis port is allowed.

2) Authentication Message Exchange: Theauthentication exchange used in 802.1x takes placeover Extensible Authentication Protocol or EAP (seeSection 6). EAP is a protocol designed for transportingauthentication messages. In order for EAP messages tobe transported on a LAN, they need to be encapsulated.

IEEE 802.1x defined EAP over LAN or EAPOLto encapsulate EAP packets allowing them to betransported on a LAN. In a typical 802.1x authenticationexchange, EAPOL messaged must travel between thesupplicant (client), the authenticator (access point), andthe authentication server. Figure 6 is an example ofthe EAP message flow that occurs during the 802.1xauthentication [4].

3) Upper Layer Authentication: One of major defi-ciencies in WEP is that a clients identity is never trulyvalidated with any sort of integrity. 802.11i addressesthis issue by using upper-layer authentication. 802.11i’supper layer authentication guidance ensures flexibilityof the standard as well as provides a secure frameworkfor enterprise WLAN implementations. The Enterpriseis given the flexibility to choose the appropriate upperlayer authentication scheme (e.g. Kerberos, EAP-LEAP,EAP-PEAP, EAP-TLS, EAP-TTLS and EAP-SIM) basedon different factors including interoperability, cost andadministrative overhead. EAP extensions under the WPAenterprise are covered in a greater detail in later sections.

B. 802.11i Key Management

The key management schemes used in 802.11i arehierarchal by design. There are two types of keygeneration management systems as part of 802.11i. Theyare server-based keys that require the involvement of anauthentication server to generate and manage server-based keys or the use of pre-shared keys. Complete 802.11iimplementation requires the use of an authenticationserver to generate and manage keys. Smaller organizationsand home users can use pre-shared key management.

1) Server based Key Generation and Management: Theserver-based key hierarchy begins a Pairwise Master Key(PMK). PMK is generated during the 802.1x authorizationand authentication phase using the upper layerauthentication protocol. After the authenticationprocess is completed, both the server and the client havematching PMKs. A copy of this key is also sent to theaccess point (AP) using the Radius [17] protocol.

Even though the same key is shared amongst theentities that need to communicate, communication is notallowed yet. This is because access point still needs toauthenticate itself to the client, and the keys to encryptthe traffic need to be derived. We cannot use PMK as theencryption key because it is designed to last the entiresession and should be exposed as little as possible. PMKis thus used to create what are called TemporalKeyswhich would be used for encryption and integrity of thedata as well as the EAPOL authentication messages.TemporalKeys generated are as follows:

• Data Encryption key (DEK, 128 bits)• Data Integrity key (DIK, 128 bits)

5

• EAPOL-Key Encryption Key (KEK, 128 bits)• EAPOL-Key Integrity key (KCK, 128 bits)

To provide randomness to the creation of TemporalKeys,nonce are generated by both devices and added to thePMK to generate the temporal keys. The MAC addressesof both devices that have associated with each otherare also added to the computation of these temporalkeys. This is done to ensure that the keys are boundto the two devices that created them. Temporal keysare called so because they are generated every time adevice is associated to an access point in an RSN. The 4temporal keys when grouped together form what is calleda Pairwise Transient Key (PTK). PTK is constructedat both ends using a four way handshake procedure (seefigure 7):

1) The AP point sends a nonce-value to the client(ANonce). The client now has all the attributes toconstruct the PTK.

2) The client sends its own nonce-value (SNonce) to theAP together with a message integrity code (MIC),including authentication, which is really a MessageAuthentication and Integrity Code (MAIC).

3) The access point sends a group transient key (GTK)(see below) and a sequence number together withanother MIC. The sequence number is the sequencenumber that will be used in the next multicast orbroadcast frame, so that the receiving client canperform basic replay detection.

4) The client sends a confirmation to the access point.

Due to the fact that 802.11 communication also supportsbroadcast messages, 802.11i also standardizes a processfor Group Keys that ensure secure communication forbroadcast messaging. Group keys are created becausepairwise keys are unique to each device. Broadcastmessage encryption is more efficient when the same keyis used to encrypt and decrypt the message. While itis possible for clients to use their unique pairwise key,it is inefficient to have each client encrypt and decryptthe message before passing it on. The group keys usedin the network may need to be updated if the presettimer expires or a device leaves the network. Latter is toprevent the device from receiving any more multicast orbroadcast messages from the AP. To handle the updating,802.11i defines a Group Key Handshake that consists ofa two-way handshake:

1) The AP sends the new GTK to each client in thenetwork. The GTK is encrypted using the KEKassigned to that client and protects the data frombeing tampered using a MIC.

2) The client acknowledges the new GTK and repliesto the AP.

The process of key management and creation is the samefor TKIP and AES-CCMP (covered in the next section),the two encryption standards defined in 802.11i. The onlydifference that exists is the number of keys needed. Thisis due to the fact that AES-CCMP combines the processof integrity and encryption. Table 1 gives a summary andcomparison of the keys generated for both TKIP and AES-CCMP [9].

C. 802.11i Encryption and Integrity

Wi-Fi Alliance and the 802.11i workgroup introducedTKIP and AES-CCMP encryption standards in 802.11ito replace the weak RC4 encryption used in WEP.They integrated the Temporal Key Integrity Protocolor TKIP into their standard because it could easily beimplemented with the existing WLAN hardware. TheTKIP protocol continues to have RC4 at its core, butintroduces changes in the areas of message integrity,IV creation, and key management and plays the partof a wrapper to increase the security of WEP. WhileTKIP is considered secure, AES-CCMP is at the core of802.11i and is a mode created from scratch with AESat its center. In the following text, we will delve intoTKIP, AES-CCMP, and their encryption and integrityverification methods.

• TKIP IV: Even though TKIP has RC4 at its base,it improves over WEP’s encryption by using a largerIV (48 bits). This significantly decreases the chancesof an IV reuse. This increases the size of possibleIVs to 248 as opposed to 224 possible WEP IV values.

Increasing the IV length also addresses WEPsweak key vulnerability. It achieves this by splittingthe IV into two pieces. The first 16 bits of the IVare padded to create a 24-bit IV in a way thatavoids the use of weak keys. This process is calledper-packet key mixing. Note that the 24-bit IV is thesame length as the WEP IV. That IV is joined to amixed key that is calculated using the remaining 32bits of the TKIP IV. This ensures that every packethas a different set of IVs. Figure 8 depicts a TKIPencrypted packet. The 12 bytes added by TKIP arecomprised of the extended IV (4 bytes) and MIC(8 bytes.) The MIC is TKIPs implementation of amessage integrity check.

The IV in TKIP is also used in the implementationof a TKIP sequence counter or TSC. WEP wasextremely susceptible to replay attacks due to theeasy deciphering of WEPs secret key. The 802.11iresolves this issue by using IV as a counter. Theprocess works in a very linear fashion as a counteris started during transmission and a receiver rejectsevery packet that has a TSC less than or equal tothe previous packet. This makes replay attacks veryunlikely.

6

• TKIP Message Integrity Code: Another of WEPsdeficiencies was its use of a CRC based IntegrityCheck Value also known as an ICV. Weakness ofWEPs key management led to the compromise ofother processes and made ICV trivial as explainedearlier. The 802.11i working group as a result decidedto included a message integrity code (MIC) intothe TKIP standard. The standard was designedspecifically for use with TKIP. The 8-byte MIC iscalculated using the source MAC address, destinationMAC address, and the plaintext of a MAC ServiceData Unit (MSDU). This ties the MIC to both thesource and destination to ensure that any deviationin either MAC address will result in the rejection anddiscarding of the MSDU by either device. To ensurerandomness, the MIC is also seeded using the MICkey and TSC. Figure 9 is the TKIP encapsulationprocess in a greater detail. TKIP is consideredsecure, but due to the fact that it continues to haveRC4 at its core, the final 802.11i standard mandatesthe use of AES-CCMP.

• AES-CCMP: AES-CCMP is the mandatoryencryption standard in 802.11i. CCMP uses AESencryption algorithm with CCM as the mode ofoperation. The CCM mode combines Counter Mode(Figure 10) for confidentiality and Cipher BlockChaining Message Authentication Code (CBC-MAC)for authentication and integrity. All AES processingwithin CCMP uses AES with a 128 bit key anda 128 bit block size. CCM requires a fresh AEStemporal key (TK) for every session. CCM also needsa unique nonce value for each frame protected by agiven TK, and CCMP uses a 48-bit packet number(PN) for this purpose. Reuse of a packet number(PN) with the same TK voids all security guarantees.

• CCMP Encapsulation: CCMP encapsulates a plain-text MAC Protocol Data Unit (MPDU) using thefollowing steps [24]:

– It first increments the Packet Number (PN), toobtain a fresh PN for each MPDU.

– The fields in the MAC header are used toconstruct the Additional Authentication Data(AAD).

– Construct CCM Nonce block (initialization vec-tor) from the PN, A2 and the Priority of theMPDU.

– Encode the new PN and the KeyId into the 64Byte CCMP Header.

– Run CTR mode AES (see Figure 11) using thetemporal key (TK), AAD, Nonce and MPDUdata to form the ciphertext and Message IntegrityCheck (MIC).

– The Encrypted MPDU is formed byconcatenating the original MAC Header,the CCMP header, the Encrypted Data and the

MIC. Figure 12 depicts the CCMP encapsulationprocess.

• CCMP MIC: Message integrity in AES-CCMP isensured using CBC-MAC. It basically works bytaking the first 128-bit block of data and encryptingit using the AES algorithm. It then uses theciphertext to XOR the second 128-bit block. Thiscontinues until the entire message MIC value (128bits) is computed. This MIC value is then appendedto the message. At the receiving end, MIC isrecalculated on the message and is compared withthe transmitted MIC. If the values do not match,that means the message has been modified in transitand should be discarded. The chances of forgingthis MIC value are 1 in 1019 even at a 64-bit size.This ensures the integrity of the message in transit.Figure 13 depicts the creation of the MIC valueusing CBC-MAC. This diagram shows how the PNis used to create the MIC IV that seeds the AESencryption to encrypt the first block of data andcontinues to use the XORed values of the previousblocks to encrypted the proceeding blocks.

• CCMP Decapsulation Process: CCMP requires onlyAES encryption operations and not AES decryptionoperations. The decapsulation process succeeds whenthe calculated MIC matches the MIC value receivedin the Encrypted MPDU. Figure 14 shows the CCMPdecapsulation process.

V. Wi-Fi Protected Access (WPA)

One of the major problems that IEEE and Wi-FiAlliance faced while designing 802.11i was the fact that thestandard wasn’t going to be ready for ratification any timesoon and that consumers needed an alternative to WEPsooner, rather than later. Realizing this issue, the Wi-Fi Alliance decided to create their own subset of 802.11icalled WPA or Wi-Fi Protected Access. WPA was basedon portions of the 802.11i standard that were alreadydecided on before ratification of the standard. WPA wassupported by a large number of vendors and consumeralike because implementing it would simply require afirmware upgrade to most WLAN devices.

A. WPA2

In July 2004, however IEEE approved the full 802.11ispecification, which was quickly followed by a newinteroperability testing certification from the WiFiAlliance known as WPA2. WPA2 is based on the RobustSecurity Network (RSN) mechanism, which providedsupport for all of the mechanisms available in WPA, aswell as [23]:

• Strong encryption and authentication support forinfrastructure and ad-hoc networks (WPA is limitedto infrastructure networks);

7

• Reduced overhead in key derivation during the wire-less LAN authentication exchange;

• Support for opportunistic key caching to reduce theoverhead in roaming between access points;

• Support for pre-authentication, where a station com-pletes the IEEE 802.1X authentication exchange be-fore roaming;

• Support for the CCMP (Counter Mode with CipherBlock Chaining Message Authentication CodeProtocol) encryption mechanism based on theAdvanced Encryption Standard (AES) cipher as analternative to the TKIP protocol used in WPA.

As of March 2006, the WPA2 certification becamemandatory for all new equipment certified by the Wi-FiAlliance, ensuring that any reasonably modern hardwarewill support both WPA and WPA2.

VI. Extended Authentication Protocol

Extensible Authentication Protocol [11], or EAP, isa universal authentication framework frequently used inwireless networks and Point-to-Point connections. It isbest considered as a framework for transporting authenti-cation protocols, rather than as an authentication protocolitself. EAP can be used for authenticating dial-up andVPN connections, and also Local Area Network (LAN)ports in conjunction with IEEE 802.1X.

A. Fundamentals

EAP, uses the same authentication model of SectionIV(A). Authenticator demands the proof of authenticationfrom the supplicant. EAP defines four types of packet:request, response, success and failure (from [7]).Request packets are sent by the authenticator to thesupplicant and a response packet is expected in return.Any number of request-response exchanges may be usedto complete the authentication. If the authentication issuccessful, a success packet is sent to the supplicant,otherwise a failure packet is sent.

The basic EAP packet format is simple (see Figure15). A Code field indicates the type of packet, which canbe one of response, request, success or a failure. The IDis one byte for matching requests and responses. Lengthis the byte count including the code, ID, length and datafields. The data field format varies depending on the codefield. Types 3 and 4, Success and Failure have no datafield (0 bytes). Types 1 and 2 share the format shownin Figure 16. The type field here indicates the type ofdata being transported (see next paragraph), and thetype− data, consists of that data.

The EAP specification defines three basicauthentication EAP types (MD5 − Challenge, OTPand GTC) and three non-authentication types (Identity,NAK and Notification). The basic authentication typesare not considered secure for wireless environments.

Consequently other types should be used. The Identitytype is used by the authenticator to request the username claimed by the supplicant, and is typically the firstpacket transmitted. The NAK type is used by the peerto indicate that a type proposed by the authenticatoris unacceptable (e.g., the authenticator has proposedan authentication protocol which is not supported bythe client, or policy forbids its use). If this happensthen the authenticator may choose to try anothertype, thereby allowing supplicant and authenticator tonegotiate a mutually acceptable authentication protocol.The Notification type, which is rarely used, returns amessage that must be displayed to the user.

EAP also permits what is called pass-through au-thentication. This allows the authenticator to forwardall responses, using the RADIUS protocol [17], to aremote EAP server. This server assumes the role of theauthenticator for the remainder of the EAP session, andattempts to authenticate the supplicant against a userdatabase server. Passthrough authentication, therefore,permits centralized management of authentication againstlarge numbers of authenticators. Another advantage isthat the authenticator does not need to support the typenegotiated by the peer and the EAP server. An exampleEAP exchange is shown in Figure 17.

B. EAP Types TLS, TTLS and PEAP

EAP basic authentication types do not provide sufficientprotection for use on a shared network and, in particular,do not allow negotiation of the keying material requiredfor IEEE 802.11 wireless LAN encryption. Consequently,a number of more secure types have been developed. Ofthese, only three have been widely implemented: TLS[12], TTLS [13] and PEAP [14]. The TLS EAP type isbased on the Transport Layer Security (TLS) [15] protocol,which uses public key cryptography for authentication andnegotiation of keys that can be used to encrypt data.TLS is also the protocol used for securing HTTPS. Themain difference is that HTTPS is transported over TCP ,whereas EAP TLS is transported over the EAP sessionbetween the supplicant and EAP server. As in HTTPS,the supplicant authenticates the servers identity usinga locally stored root certificate. However, unlike mostHTTPS transactions, EAP TLS uses a user certificateto authenticate the supplicant to the server. This meansTLS can only be used by organizations with a CertificateAuthority (CA) that issues user certificates. Although thisoffers excellent security, EAP TLS is not widely deployed.Instead, two further EAP types, Protected EAP (PEAP )and Tunneled TLS (TTLS), work around this problem.Both of these types also use TLS for server authenticationand encryption, but avoid the need for user certificatesby using a second authentication protocol between thesupplicant and the server that is protected by the TLSencryption. This is very similar to conventional HTTPSauthentication, where the users plain-text credentials are

8

protected by TLS. The main difference between the typesis that PEAP can only protect other EAP types, whereasTTLS can protect almost any authentication protocol. Anoverview of the protocol layering is shown in Figure 18.

VII. IEEE 802.11i Limitations

This paper analyzes the IEEE 802.11i protocols fordata confidentiality, integrity, mutual authentication, andavailability. Considering the possibilities of threats likeTraffic Analysis, Message Injection, Message Deletion andInterception, Masquerading and Malicious AP, SessionHijacking, Man-in-the-Middle attack and Denial-of-Service attacks, 802.11i appears to provide effective dataconfidentiality and integrity when AES-CCMP is used.This however requires a legacy WEP user to upgradethe hardware. Furthermore, 802.11i adopts a RSNAestablishment procedure for mutual authentication andkey management, which appears to be satisfactorilysecure. However, several vulnerabilities might arise in areal implementation [8]:

• If the mutual authentication mechanism is not imple-mented appropriately, there might be a Man-in-the-Middle attack that reveals the shared secret.

• If a passphrase is used to generate a 256-bit PSK,an adversary might be able to find the passphrasethrough dictionary attacks. An adversary is alsoable to discover the shared RADIUS secret throughdictionary attacks.

• Furthermore, if Pre-RSNA and RSNA algorithmsare implemented in a system simultaneously withoutcareful considerations, an adversary is able to performa Security Level Rollback Attack to force the com-municating peers to use WEP, which is completelyinsecure.

• Moreover, if a wireless device is implemented to playthe role of both the authenticator and the supplicant,an adversary can construct a reflection attack on the4-Way Handshake. This scenario naturally appears inad hoc networks.

• Availability is another important security propertyin wireless networks. Since availability is not theprimary design goal, 802.11i appears vulnerable toDoS attacks even if RSNA is implemented. Somemight think that the DoS attacks seems to beinevitable due to the physical characteristics ofwireless links. However, as many DoS attacks can bemounted by an adversary with moderate equipments,and a successful DoS attack may facilitate otheradvanced attacks, such as Session Hijacking and Man-in-the-Middle (MitM), they should be considered asreal threats to a WLAN implementation. Many DoSattacks have been disclosed on the WLAN systemsfrom the Physical Layer to the Application Layer.The key point to mitigate these attacks is to imposerelatively higher cost for an adversary, e.g., morecomputation power, more message transmissions, or

more memory consumption, which could make theDoS attacks impractical.

Changhua He and John C Mitchell analyse the abovementioned limitations of the IEEE 802.11i in their pub-lication "Security Analysis and Improvements for IEEE802.11i" [8]. They also propose an improved variant of the802.11i standard, which is resistant to most of 802.11i’svulnerabilities.

References

[1] Tom Karygiannis, Les Owens, "Wireless Network Security802.11, Bluetooth and Handheld Devices", NIST, Special Pub-lication 800-48

[2] "WLAN Solutions 802.1x and Bluesocket", URL:http://www.bluesocket.com/solutions/802.1x-Feature-Brief.pdf

[3] Eaton, Dennis "Diving into the802.11i Spec: A Tutorial, 26 Nov 2004.",http://www.commsdesign.com/printableArticle/?articleID=16506047

[4] Edney, Jon and Arbaugh, William. "Real 802.11 Security: Wi-FiProtected Access and 802.11i", Boston, Addison-Wesley, 2004.135

[5] "IEEE Std 802.11i/D3.0", URL:http://www.cs.umd.edu/ mhshin/doc/802.11/802.11i-D3.0.pdf

[6] "Counter Mode", URL: http://encyclopedia.thefreedictionary.com/Counter%mode[7] "Extensible Authentication Protocol, Fact Sheet", URL:

http://www.ja.net/documents/publications/factsheets/065-eap.pdf

[8] Changhua He, John C Mitchell "Security Anal-ysis and Improvements for IEEE 802.11i", URL:http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/NDSS05-1107.pdf

[9] Elio Perez "802.11i (How we got here and where are we headed)",GSEC Certification, Version 1.4b Option1, Orlando, FL, August21, 2004

[10] Cam-Winget, Nancy., et al. "IEEE802.11i Overview, 2004", URL:http://csrc.nist.gov/wireless/S10_802.11i/20Overviewjw1.pdf,2004.

[11] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz,Ed., "RFC3748 - Extensible Authentication Protocol, (EAP),2004"

[12] B. Aboba, D. Simon, "RFC2716 - PPP EAP TLS Authentica-tion Protocol, 1999."

[13] Paul Funk, Simon Blake-Wilson, "EAP Tunneled TLS Authen-tication Protocol, 2002."

[14] Ashwin Palekar, Dan Simon, Glen Zorn, Joe Salowey, Hao Zhou,S. Josefsson, "Protected EAP Protocol (PEAP) Version 2, 2003."

[15] T. Dierks, C. Allen, "The TLS Protocol Version 1.0, 1999."[16] Fluhrer, Scott, Mantin, Itsik, Shamir, Adi. "Weak-

nesses in the Key Scheduling Algorithm of RC4 2001",URL: http://www.drizzle.com/ aboba/IEEE/rc4_ksaproc.pdf(25 June 2004.).

[17] http://en.wikipedia.org/wiki/RADIUS[18] Wireless Networking Basics http://docs.netgear.com/reference/sve/wireless/[19] Wikipedia, Cyclic Redundancy Check,

http://en.wikipedia.org/wiki/Cyclic_redundancy_check[20] Jesse Walker, Intel Corporation. "IEEE P802.11Wireless LANs:

Unsafe at any key size; An analysis of the WEP encapsulation."[21] Wikipedia, IEEE 802.11i-2004,

http://en.wikipedia.org/wiki/802.11i[22] "802.11i Overview" URL: http://www.drizzle.com/ aboba/IEEE/11-

05-0123-01-0jtc-802-11i-overview.ppt[23] "Understanding WPA2" URL:

http://www.computerworlduk.com/technology/networking/protocols/in-depth/index.cfm?articleid=257

[24] "Counter CBC-MAC Protocol (CCMP) Encryption Algorithm"URL: www.vocal.com/CCMP.pdf

[25] Peter J. Welcher "Examining 802.1x and EAP" URL:http://www.netcraftsmen.net/welcher/papers/dot1x.html

Figure 1: WEP Open System Authentication, from [18]

Figure 2: WEP Shared Key Authentication, from [18]

1

Figure 3: WEP Privacy Using RC4 Algorithm, from [1]

Figure 4: from [25]

2

Figure 5: 802.1x state before (left) and after (right) successful mutual authen-tication, from [3]

Figure 6: EAP Message Flow, from [9]

3

Figure 7: 4 way Handshake, from [21]

Figure 8: TKIP Encrypted Packet, from [5]

4

Figure 9: TKIP encapsulation process, from [5]

Figure 10: Counter (CTR) Mode Encryption, from [6]

5

Figure 11: CCMP CTR-Mode Encryption, from [5]

Figure 12: CCMP Encapsulation Process, from [24]

6

Figure 13: MIC Calculation, from [5]

Figure 14: CCMP Decapsulation Process, from [24]

Figure 15: Basic EAP Packet Format, from [25]

7

Figure 16: Request, Response EAP Packet Format, from [25]

Figure 17: An example EAP authentication, from [7]

Figure 18: Protocol layering in EAPs PEAP and TTLS, from [7]

8