fast and secure roaming in wlan - diva portal

Final thesis

Fast and Secure Roaming in WLAN

Performed for Ericsson AB

byMagnus Falk

LITH-IDA-EX--04/116--SE

2004-12-22

i

Final thesis


by Magnus Falk

LiTH-IDA-EX--04/116--SE

Supervisors: Bo KvarnstromCPE Products & Solutionsat Ericsson ABDavid ByersDivision for Database and InformationTechniquesat Linkoping university

Examiner: Nahid ShahmehriDepartment of Computer and InformationScienceat Linkoping university

iii

Abstract

This thesis investigates how Ericsson AB should do to achieve fast and secure han-dover when roaming in a WLAN. It also provides a security analysis of the systemthat the wireless access point is part of.

The reason for this is that Ericsson is selling an access point called the ABS2200 aimed at the public hotspot market. The premise was that they wanted astandardized way of handling the roaming issue. At the outset the 802.11F standardlooked like a good alternative (in fact the only standardized alternative). Towardslast stages of the work though, it was discovered that the 802.11F standard is nolonger supported by IEEE.

Despite this fact, the conclusion is that secure and fast roaming can be attainedif 802.11F is combined with the security standard 802.11i.

The security analysis concludes that Denial Of Service is a major threat toWLAN hotspots. It also points out the link between the access point and authenti-cation server is the weakest link in the system. The recommendation is that this linkreceives an additional layer of protection through IPsec with ESP. The algorithmrecommendations for ESP are AES for confidentiality and SHA-1 for integrity.

This thesis can also be used as a primer on security in WLAN and contains anextensive glossary making it useful as a reference when reading 802.11 standards.

Keywords: 802.11, 802.11i, 802.11F, IAPP, WPA, WPA2, RADIUS, EAP-SIM,WLAN, 802.1X

v

Acknowledgments

First I would like to thank my supervisors at Ericsson: Bo Kvarnstrom and RasmusAxen. Both have been very helpful with comments and discussions around differenttopics in the report. My supervisor at the university, David Byers, for helping outwith a lot of little oddities and my examiner, Nahid Shahmehri.

I would also like to thank Stefan Rommer and Sten Sjoberg at Ericsson inGoteborg for expertise on the 802.11F, 802.11i and WPA standards. Jesse Walkerat Intel and 802.11 Task Group r at IEEE for discussions about security in 802.11in general and 802.11F in particular.

Gustaf Oldburg, Peter Agzz and Mikael Tallbent for help with proofreading (andthe others in team286 for general comments).

And finally my wonderful girlfriend Jonna for being the strictest proofreader ofthem all and generally great support throughout the process.

vii

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 System Overview 32.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 The 802.1X Standard . . . . . . . . . . . . . . . . . . . . . . 42.1.2 The RADIUS Protocol . . . . . . . . . . . . . . . . . . . . . . 52.1.3 The Extensible Authentication Protocol . . . . . . . . . . . . 6

EAP-SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 The 802.11i Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 The Four-Way Handshake . . . . . . . . . . . . . . . . . . . . 102.2.2 Robust Security Network . . . . . . . . . . . . . . . . . . . . 112.2.3 CCMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.4 Security Associations . . . . . . . . . . . . . . . . . . . . . . . 13

Pairwise Master Key Security Association . . . . . . . . . . . 13Pairwise Temporal Key Security Association . . . . . . . . . 14Group Temporal Key Security Association . . . . . . . . . . . 14Station Key Security Association . . . . . . . . . . . . . . . . 15

2.3 The Wi-Fi Protected Access Framework . . . . . . . . . . . . . . . . 152.3.1 The Temporal Key Integrity Protocol . . . . . . . . . . . . . 15

2.4 The 802.11F Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.1 IAPP Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.2 Network Packets . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.3 Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . 20

INITIATE and TERMINATE . . . . . . . . . . . . . . . . . . 20ADD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

CONTENTS

MOVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21CACHE-NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.4 Proactive Caching . . . . . . . . . . . . . . . . . . . . . . . . 222.4.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Security Analysis 273.1 The CIA Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Common Attack Methods . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 Man-In-The-Middle . . . . . . . . . . . . . . . . . . . . . . . 283.2.2 Session Hijack . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.3 Packet Manipulation . . . . . . . . . . . . . . . . . . . . . . . 293.2.4 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.5 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.6 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.7 Authentication Method Downgrading . . . . . . . . . . . . . 30

3.3 The Different Links Involved . . . . . . . . . . . . . . . . . . . . . . 303.3.1 ClientÀAccess Point . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 ClientÀAuthentication Server . . . . . . . . . . . . . . . . . 313.3.3 Access PointÀAccess Point . . . . . . . . . . . . . . . . . . . 313.3.4 Access PointÀAuthentication Server . . . . . . . . . . . . . . 32

3.4 Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.1 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.2 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.3 IAPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.4 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.5 EAP-SIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 Threat Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Results 394.1 Secure Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Security Recommendations . . . . . . . . . . . . . . . . . . . . . . . 40

5 Discussion 415.1 Secure Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Security Recommendations . . . . . . . . . . . . . . . . . . . . . . . 415.3 Further Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Glossary 43

Bibliography 59

1

Chapter 1

Introduction

1.1 Background

Ericsson AB is currently developing a product called the ABS 2200. This is a wire-less access point (AP) designed to provide Internet access in public areas. Suchzones of access are usually called Hotspots and are comprised of several APs clus-tered together in order to achieve good signal strength everywhere in the intendedarea. In order for this solution to work, there needs to be a transparent way for asession to be moved from one AP to another. Ideally this is done without the userever noticing the switch. The focus in this report will be how to achieve this in asecure manner.

1.2 Purpose

The purpose of this thesis is to investigate how Ericsson should go about sendingencrypted messages over a network consisting of wireless APs. This is called forwhen the client is roaming from one AP to another. The encryption keys then needto be securely transported to the new AP to get a seamless transition.

A secondary purpose is to provide an overview of the system with a focus onsecurity, to determine where the weakest link is and whether there is an appropriatelevel of security throughout the system.

1.3. Problem

1.3 Problem

Wireless networks are by nature insecure as all traffic is essentially broadcasted andanyone with an antenna can pick it up. It is therefore imperative that all traffic isencrypted in order to protect the privacy of the users.

Currently, roaming in the ABS 2200 is handled by forcing the client to make afull re-authentication. This re-negotiation of encryption keys is the main source oflatency in roaming. So while this is a working and secure solution, it is definitelynot a ideal one. In order to achieve the low latency desired, the encryption keyswould have to be transported to the next AP. Currently there is no way of doingthis securely.

3

Chapter 2

System Overview

This chapter will discuss all the parts of the system and their respective roles,foremost viewed from a security perspective.

The system to be examined is a wireless LAN. Other terms for it include Hotspotand ESS (Extended Service Set). There are a number of components involvedin this but the three main entities are the client, the access point (AP) and theauthentication server (AS). An overview of the system is shown in figure 2.1.

The client is the entity that wants to gain access to the network (also calledstation (STA) or supplicant depending on the context). Most often this is a laptopwith a wireless network card. The access point (AP) is the entity that provides thenetwork access and acts as the gatekeeper of the system. Finally, the authenticationserver (AS) is the entity that ensures that the client is authorized to utilize thesystem.

Authentication is a natural starting point for the description of this system. Thetools available to facilitate authentication and the manner in which they are appliedwill be outlined, followed an overview of the 802.11i standard and what security itadds to the system. This is followed by a brief section about what WPA is and howit relates to WPA2 (which is what Wi-Fi Alliance calls their approved interoperableimplementation of 802.11i). The chapter closes with a look at the 802.11F standardand how it facilitates fast roaming.

2.1 Authentication

Authentication is the act of ascertaining that an entity (called supplicant in thiscontext) actually is who it claims to be. If a supplicant passes this test of admission

2.1. Authentication

ClientStationSupplicant

Access PointAuthenticator Authentication Server

AAA Server

Figure 2.1: An overview of the system.

it is authenticated and is allowed access to the protected resource. To facilitate thisprocess a set of tools have been developed. The tools that will be examined are802.1X, EAP and RADIUS.

2.1.1 The 802.1X Standard

802.1X [17] is a standard for network access control through the use of ports. Itdefines three entities:

Supplicant - The entity that wants access, the client.

Authenticator - The entity that controls the access gate, the AP.

Authentication Server - The entity that decides on admission, also called anAAA server (Authentication, Authorization and Accounting).

When a Supplicant connects to an authenticator it is restricted to a port1 thatonly allows EAP (Extensible Authentication Protocol) traffic to the AS. 802.1Xacts as a gatekeeper taking orders from the AS. The actual authentication processcan now take place in a safe manner as the supplicant is only allowed to talk to thegatekeeper. The gatekeeper then handles all the communication to the AS. Whenthe AS finally authorizes the supplicant the other port is opened and the client is

1This is not a port in the TCP sense; it is only used as an abstraction of the 802.1X interface.

5

Authorize

Supplicant

Authenticator

AuthenticationServer

DistributionSystem

Figure 2.2: The 802.1X port interface.

allowed full access to the distribution system (DS). A model of the port interfacecan be seen in figure 2.2.

2.1.2 The RADIUS Protocol

RADIUS [27] stands for Remote Authentication Dial-In User Service and is anAAA protocol. This is the entity that perform the actual authentication. It alsoruns accounting on authorized entities but that functionality will not be coveredin this document as the focus is on security. RADIUS is a protocol originallydesigned to provide remote authentication for ISP modem pools. Instead of havingthe customers making long-distance calls to a centralized authentication server thecustomer could call a local modem pool that then used RADIUS to authenticate thecustomer. The scheme has since been extended to accommodate EAP in RFC 3579where EAP packets are simply encapsulated within RADIUS ones. With respect toauthentication RADIUS defines four message types:

Access-Request - Sent by the authenticator entity (in our case the AP) to theAS. It conveys information used to determine whether the user is allowedaccess or not.

Access-Accept - Sent by the AS to indicate successful authentication.

Access-Reject - Sent by the AS to indicate unsuccessful authentication.

http://www.ietf.org/rfc/rfc3579.txt

2.1. Authentication

Access-Challenge - Sent when the Access-Request message indicates that theuser wishes to use a Challenge-Response scheme to authenticate.

2.1.3 The Extensible Authentication Protocol

The Extensible Authentication Protocol [1] (EAP) is based on the Point to PointProtocol [29] (PPP) and is a protocol facilitating remote authentication. In itselfit is a rather simple protocol specifying only four different types of messages to besent:

Request - Used to send messages from AS to the supplicant.

Response - Used to send messages from supplicant to the AS.

Success - Sent by the AS to indicate that access is granted.

Failure - Sent by the AS to indicate that access is refused.

Figure 2.3: A generalized picture of authentication using a Challenge-Responsescheme.

7

The authenticator only acts as a middle man, relaying all EAP messages betweenclient and AS. When the AS eventually sends an accept/failure the authenticatoracts accordingly. EAP only acts as a wrapper for the actual authentication methodleaving the field open for a large variety of schemes. This report will only discussthe EAP-SIM method, which Ericsson deems the most appropriate choice for theABS 2200.

EAP-SIM

The EAP-SIM [11] method is an interesting technique as it involves already estab-lished technology. All GSM-SIM cards have a pre-shared key installed providing asimple solution to the key sharing problem. This is convenient for the users as theydo not need to bother with any certificates or other authentication schemes. Ad-ditionally, the same billing system used for the subscription can be used to chargethe WLAN-access.

Authentication in GSM Even though GSM was originally designed for voicecommunications rather than data transfer, the authentication procedure looks a lotlike the ones used in data security. The authentication uses a Challenge-Responsescheme whereby the GSM server (GSM AC) sends a random value which the phoneencrypts with its shared key and sends back for verification.

When a phone wants to authenticate it first sends its identification number, orIMSI (International Mobile Subscriber Identity) to the network. The local networkthen forwards the IMSI to the GSM server that responds by sending a triplet backto the local network. The triplet is comprised by the following items:

• A random challenge (RAND).

• A response value (SRES) achieved by encrypting2 the RAND value with theshared secret.

• A 64-bit session key (Kc), generated from combining the shared secret withthe RAND value.

The local network then forwards the RAND to the phone which combines theshared secret with the RAND to compute the session key Kc and the SRES valuewhich it then sends back to the local network. The local network can now verifythat the phone knows the shared secret by comparing the two SRES values. Thesession can now be initiated by using the Kc session key for encryption.

2Actually it uses a Keyed Hash function.

2.1. Authentication

Authentication in WLAN In order to achieve satisfactory security levels for802.11i and WPA, the GSM authentication needs to be strengthened on a few points.The most obvious point is the key length: GSM only uses 64 bits whereas CCMP(the encryption algorithm used in 802.11i) uses 128 bits. The chosen solution is tosend more challenges and then concatenate the resulting keys into a session key ofarbitrary length.

Another concern is that the IMSI value is sent in plaintext. This enables anattacker to gather information by observing a large number of authentications.EAP-SIM suggests to solve this by, during the authentication, agreeing on a newsubscriber identity to be used in the next authentication. This new identity is calleda pseudonym.

The third concern is that the network is never explicitly authenticated, making itpossible for a rogue AP to replay old triplets it has obtained from eavesdropping onearlier authentications. This is resolved by letting the supplicant provide a Noncevalue (an unpredictable and unique number, used only once) at the start of theauthentication. The AP then has to incorporate this value into the session key laterwhich ensures that the triplets provided are fresh.

The actual EAP-SIM authentication procedure is shown in figure 2.4 and de-scribed here:

1. The supplicant starts by sending a EAP-Start packet (encapsulated withinan EAPOL (EAP Over LAN) packet) telling the AP it wants to log on.

2. The AP responds by telling the supplicant to submit its identity.

3. If this is the very first EAP-SIM contact the client sends its IMSIinformation, but all subsequent contacts pseudonyms will be used. Thedesired authentication method is also included.

4. Then the AP sends an EAP-Request/SIM/Start message telling thesupplicant that it is ready to proceed with EAP-SIM authentication.

5. The supplicant responds by sending the nonce value to be incorporated intothe session key.

6. The AP has several tasks to complete at this stage:

Get GSM-triplets - Contact the GSM Authentication Center (GSM AC)submitting the supplicants identity and ask for triplets.

Compute Session Key - Take the received Kc values and compute thesession key, called PMK (Pairwise Master Key). This is done byputting them and the nonce through a Keyed Hash function.

9

STA AP GSM AC

EAPOL-Start

Request/SIM/Start

IMSI or pseudonym

Request/Identity

NonceRequest triplets (x3)

GSM Triplet (x3)(RAND, SRES, Kc)

Request/SIM/Challenge(3xRAND, MIC, Psdnym)

SRES

AP creates asession key outof the Kc valuesand constructs a new pseudonym

Client calculatesthe session key from the RAND-challenge

EAP-Success

Figure 2.4: EAP-SIM authentication.

2.2. The 802.11i Standard

Create a new pseudonym - The AP also creates a new pseudonym to beused next time the client authenticates. This pseudonym is encryptedwith the session key.

7. After completing all the above tasks the AP sends anEAP-Request/SIM/Challenge containing the three RAND values, a MIC(Message Integrity Check) to protect the RAND values from tampering andthe encrypted new pseudonym.

8. Having received the RAND values the supplicant lets the SIM-card calculateboth the Kc values and the SRES values. The Kc values are then used toderive the session key, called PMK (Pairwise Master Key), using its own copyof the nonce. The SRES values are used for the actual Challenge-Response.With the PMK calculated the new pseudonym is also decrypted and stored.

9. The supplicant sends the SRES values back to the AP together with anotherMIC as confirmation that it actually possesses the shared secret.

10. Provided that the SRES values match the ones stored at the AP the client isauthenticated and the AP sends the EAP-Success message to tell thesupplicant that it is authorized to use the systems.

2.2 The 802.11i Standard

802.11i [15] is the security standard of 802.11 and updates the existing 802.11 stan-dard. It was designed to provide a more secure alternative to WEP (Wired Equiv-alent Protection) and WPA (Wi-Fi Protected Access, see section 2.3) while stillretaining backwards compatibility to WPA devices. It is sometimes referred to asWPA2 which is what Wi-Fi Alliance calls their approved interoperable implemen-tation of 802.11i.

The 802.11i architecture contains the following components: 802.1X for authen-tication (entailing EAP and an AS), RSN for keeping track of associations andCCMP to provide confidentiality.

2.2.1 The Four-Way Handshake

The authentication process leaves two considerations: the AP still needs to authen-ticate itself to the client and keys to encrypt the traffic needs to be derived. Theearlier EAP exchange has provided the shared secret key PMK (Pairwise MasterKey). This key is however designed to last the entire session and should be exposedas little as possible. Therefore the Four-Way Handshake is used to establish another

11

key called the Pairwise Transient Key (PTK). The PTK is generated by concate-nating the following attributes: PMK, AP nonce (ANonce), STA nonce (SNonce),AP MAC address and STA MAC address.

The handshake also yields the GTK (Group Temporal Key), used to decryptmulticast traffic. The actual messages exchanged during the handshake are depictedin figure 2.5 and explained here:

1. The AP sends a nonce-value to the STA (ANonce). The client now has allthe attributes to construct the PTK.

2. The STA sends its own nonce-value (SNonce) to the AP together with aMessage Integrity Check (MIC) to ensure that the packet has not beentampered with.

3. The AP sends the GTK and a sequence number together with another MIC.The sequence number is used to indicate the first encrypted packet sent lateron.

4. The STA sends a confirmation to the AP.

As soon as the the PTK is obtained it is divided into three separate keys:

EAPOL-Key Confirmation Key (KCK) - The key used to compute the MICfor EAPOL-Key packets.

EAPOL-Key Encryption Key (KEK) - The key used to provideconfidentiality for EAPOL-Key packets.

Temporal Key (TK) - The key used to encrypt the actual wireless traffic.

2.2.2 Robust Security Network

802.11i introduces the notion of a Robust Security Network (RSN). RSN is a net-work that only allows Robust Security Network Associations (RSNA). Two devicescan establish a RSNA if they use the four-way handshake to authenticate the asso-ciation. Robust security however, is not achieved unless all the devices within thenetwork use RSNAs. An ESS advertises its RSN capabilities via the RSN-IE (RSNInformation Element). Older network security solutions such as WPA and WEPare collected under what is called Transition Security Networks (TSN).


STA AP

SNonce + MIC

ANonce

STA constructs the PTK

AP constructs the PTK

GTK + MIC

Ack

Figure 2.5: The four-way handshake.

13

2.2.3 CCMP

CCMP is the encryption protocol in 802.11i. CCMP stands for Counter-Mode/CBC-MAC Protocol and it provides confidentiality, origin authenticity, integrity and re-play protection.

CCMP is based on the CCM mode in AES. CCM mode is a combination ofCounter Mode (CTR), which provides confidentiality and Cipher Block Chainingmode with MAC (CBC-MAC) which ensures integrity.

CCMP requires a fresh TK for each session and also a unique nonce for eachframe protected by a given TK. This provides replay protection. The nonce is a 48-bit packet number. To protect the MAC address (which has to be sent in plaintext)from spoofing, CCMP provides origin authentication through a method called AAD(Additional Authenticated Data). AAD incorporates the header data into the MICso that it too is safe from tampering.

2.2.4 Security Associations

802.11i uses the notion of a Security Association (SA, see RFC 2401 [18]) to describesecure operation. An SA is a set of policies and keys used to protect communications.The SA information is stored by each party and must be consistent between allparties. A STA in an RSN has up to four SAs:

PMKSA - A result of a successful 802.1X exchange, pre-shared PMKinformation, or PMK cached via some other mechanism.

PTKSA - A result of a successful four-way handshake.

GTKSA - A result of a successful group key handshake (or four-way handshake).

STAKeySA - A result of a successful STAKey handshake.

Pairwise Master Key Security Association

The PMKSA is used to create the PTKSA and is cached for up to its lifetime. Itis a bi-directional association, i.e. both parties use the association for both sendingand receiving. The PMKSA consists of the following elements:

• PMKID, a tag identifying the association.

• Authenticator MAC address.

• The Pairwise Master Key.



• Lifetime of the association.

• Additional parameters specified by the AS and local configurations; theseare only stored on the authenticator side.

Pairwise Temporal Key Security Association

The PTKSA is cached for the lifetime of the PMKSA. It is also a bi-directionalassociation. There can be only one PTKSA with the same supplicant and authen-ticator MAC addresses. The PTKSA is not created until the third message in thefour-way handshake is validated. The PTKSA consists of the following elements:

• The Pairwise Temporal Key.

• The cipher suite agreed upon.

• Supplicant MAC address.


Group Temporal Key Security Association

The GTKSA is unidirectional and is used for multicast packets distributed by theAPs. In an ESS, there is only one GTKSA. In an IBSS (Independent Basic ServiceSet, an ad-hoc network between wireless capable STAs) each STA defines their ownGTKSA for each peer STA. Each STA therefore maintains a list of all the others’GTKSAs in order to decrypt multicast traffic. The GTKSA consists of the followingelements:

• A direction vector (whether the GTK is used to transmit or receive).

• The group cipher suite agreed upon.

• The Group Transient Key.


• Additional parameters specified by local configuration.

15

Station Key Security Association

This association is used to communicate between two STAs in the same ESS. TheSTAKeySA is a unidirectional association from the initiator to the peer. There canonly exist one STAKeyAS with the same initiator and peer MAC addresses. TheSTAKeyAS is created after the first message in the STAKey handshake is validated.The STAKeySA consists of the following elements:

• STAKey.

• The cipher suite agreed upon.

• Initiator MAC address.

• Peer MAC address.

Since this is not an area of particular interest when it comes to the ABS 2200the STAKeySA will not be investigated further.

2.3 The Wi-Fi Protected Access Framework

WPA [3] is an intermediate standard framework developed in order to have a moresecure WLAN solution until the 802.11i standard was finished. WPA is based onparts from the early 802.11i drafts and is considered secure, given correct usage.

WPA uses 802.1X and EAP for authentication and a protocol called TKIP fortraffic encryption. TKIP is essentially WEP in a suit of armor that takes care of thecurrent problems with WEP. It is however a compromise and there are known weak-nesses, both in the underlying RC4 encryption algorithm [10] and in the temporalkey hash of TKIP [28]. No practical attacks have been presented yet.

2.3.1 The Temporal Key Integrity Protocol

TKIP enhances WEP in four ways:

1. The sender calculates a MIC (the MIC in TKIP is called Michael and ismost often referred to by that name) over the entire packet. This providesdefense against packet manipulation attacks.

2. Due to design constraints of the MIC, it is still possible to compromisemessage integrity. Therefore TKIP also implements countermeasures (seefigure 2.6). The countermeasures bound the probability of a successfulforgery and the amount of information an attacker can learn about a key.

2.4. The 802.11F Standard

3. TKIP uses a per-packet sequence counter called TSC (TKIP SequenceCounter). If the receiver receives a packet out of order it will drop it. Thisprovides replay protection.

4. TKIP also uses a cryptographic mixing function (an S-box) combining thetemporal key (TK), the transmitter address (TA) and the TSC into theWEP seed. This is done in order to avoid the weak keys in WEP.

The countermeasures are focused at detecting message integrity failures by look-ing at the MIC checksum. If the checksum does not add up a timer is started. Ifthere is another MIC failure before the timer reaches 60 seconds all STAs usingTKIP are deauthenticated and PTKs and the GTK are revoked. A new GTK isgenerated but not installed. The AP then waits for 60 seconds before installing thenew GTK and accepting new associations.

2.4 The 802.11F Standard

This section will discuss the 802.11F [14] standard and how it facilitates secure andfast roaming.

When a STA is roaming inside an ESS it can, according to the 802.11i standard,establish a new association by one of three schemes:

Re-authentication - (Re-)Association followed by 802.1X authentication, i.e.the normal process for an initial contact. This entails a full AS roundtrip aswell. The only difference is that the STA also deletes the old PTKSA it hadwith the previous AP.

Cached keys - STAs and APs can cache keys from earlier associations. So whenroaming to another AP the STA includes one or more PMKIDs in its 802.11(Re-)Association Request frame. If the AP has any of the PMKs cached802.1X authentication is skipped and the four-way handshake ensues.

Pre-authentication - A STA can, once it is authorized, establish PMKSAs withany of the other APs in the ESS. This is accomplished by doing regular3

802.1X authentication with the other APs and then caching the PMKSA.Re-association can then be handled as in the cached keys method. Whetheror not an AP supports pre-authentication is advertised through the RSN-IE.

3Actually it is not very regular at all: the authentication is run over the DS (DistributionSystem) instead of over the radio interface. This goes somewhat against the design intent of802.1X where the supplicant is allowed no access whatsoever until after authentication.

17

Wait for Michael MIC Failure

Timer = 0Log event

Timer <60 sec

Yes

No

Deauthenticate all if not an IBSSRevoke all PTK and GTKGenerate new GTK

Wait 60 sec

Configure new GTKEnable associations if not an IBSS

Figure 2.6: Authenticator Michael MIC countermeasures (taken from the WPAstandard [3]).


Ideally, roaming should be as fast as possible, and from that perspective pre-authentication looks very promising. The problem with it, however, is that pre-authentication is left entirely up to the client. Currently there is no reason to trustthat the client will actually do this. Here the need for IAPP (Inter Access PointProtocol) arises. IAPP is defined in the 802.11F standard and specifies how APscommunicate to facilitate fast and secure roaming.

The 802.11F standard was developed to allow for interoperability between APsfrom different vendors. It specifies desired operation and suggests implementationmodels without being too specific.

2.4.1 IAPP Structure

The communication in IAPP is divided into service primitives and actual packets.The packets are the messages sent over the network between APs. The serviceprimitives on the other hand, are messages communicated between the three entitiesthat reside inside each AP. These entities are the APME (Access Point ManagementEntity), the MLME (MAC-Layer Management Entity) and the actual IAPP entity.The APME is the entity “in charge” of IAPP operation, the MLME is the entitythat handles the network communication and the IAPP entity contains is the actualIAPP functionality.

Security is handled through the use of SAs coupled with ESP (EncapsulatedSecurity Payload, see RFC 2406 [19]). These are protocols taken from the IPsec suiteand have been well scrutinized by the security community since their introductionin 1998.

The standard also suggests three levels of deployment with increasing function-ality:

1. No AS present, each AP maintains a list of addresses for all other APs. Thislevel does not offer any security or administrative support.

2. AS is present, so address lookup is possible. All APs need to register withthe AS on startup. No security offered beyond this.

3. Full deployment. This level offers full confidentiality, integrity protection,replay protection and origin authenticity.

2.4.2 Network Packets

The following packets are defined by IAPP:


19

ADD-notify - This packet is sent to the IAPP IP multicast address in order toreach every AP in the ESS. The point of this packet is to get the receivingAPs to de-associate any STAs matching the one described in the packet, as aSTA is not allowed to maintain several associations. This packet needs to beprotected as it could easily be used to mount a Denial of Service attack.

MOVE-notify - This packet is sent each time a STA re-associates within anESS. Unlike the ADD-notify though, this packet is sent only to the AP itwas previously associated to with a MOVE-notify packet (from here onreferred to as the “old” AP). This causes the old AP to de-associate the STAand to send relevant context data about the STA to the new AP. Thispacket needs to be protected for the same reasons as ADD-notify.

MOVE-response - This packet is sent in response to a MOVE-notify packet. Itcontains context information about the re-associated STA such as PMK andmust be protected for obvious reasons.

Send-Security-Block - This packet is sent by the new AP to the old one inroaming situations in order to provide the old AP with means to set up anSA with the new AP and to encrypt and decrypt ESP packets. The packet isencrypted using the old AP’s BSSID secret.

ACK-Security-Block - This packet is sent from the old AP to the new one,encrypted with the new AP’s BSSID secret. It contains only an IV(Initialization Vector, more or less the same as a Nonce) to provide replayprotection and a New-AP-ACK-Authenticator block. This block is copiedfrom the Send-Security-Block packet and is encrypted with the new AP’sBSSID secret in order to show that the old AP has installed the encryptionkeys.

CACHE-notify - This packet is sent to all neighboring APs so that handoverlatency is low in the event of roaming. This packet contains essentially thesame information as a MOVE-response packet and is protected in the samemanner.

CACHE-response - This packet is sent in response to the CACHE-notifypacket. It only contains status indication about whether the information wasalready present in the cache or not. This is the only packet that is notprotected, because there is very little to be gained by manipulating thispacket.


2.4.3 Service Primitives

The service primitives are invoked in response to certain events, such as the AP beingturned on or a STA wishing to associate with the AP. There are five basic classesof primitives: INITIATE, TERMINATE, ADD, MOVE and CACHE-NOTIFY.

INITIATE and TERMINATE

These two first classes are straightforward and work as would be expected. Theyinitialize and terminate the APME when the AP is turned on or shut off. If thereis an AS present they also register and unregister the AP with the AS.

INITIATE.request - APME→MLME - Initializes the APME and providesstartup parameters.

INITIATE.confirm - MLME→APME - Result indication of theINITIATE.request.

TERMINATE.request - APME→MLME - Shuts the IAPP entity down.

TERMINATE.confirm - MLME→APME - Result indication of theTERMINATE.request.

ADD

Whenever a STA associates with the AP the ADD.request primitive is invoked.Upon the receipt of ADD.confirm the MLME broadcasts an ADD-notify packet onthe DS (Distribution System). The ADD.indication primitive is then generated inthe receiving APs. The ADD.indication contains a MAC address and a sequencenumber. The sequence number is provided to aid each APME in determining wherethe STA is currently associated.

ADD.request - APME→IAPP - Invoked when when the MLME detects that aSTA wants to perform a full association procedure with this AP.

ADD.confirm - IAPP→APME - Result indication of the actions following anADD.request.

ADD.indication - MLME→APME - Invoked when the MLME detects anADD-notify packet on the DS.

21

MOVE

Whenever a roaming situation occurs the MLME of the AP the STA roamed tosends a RE-ASSOCIATE.indication to the APME in that AP. This invokes theMOVE.request primitive that then tries to contact the old AP. This is done inorder to get the old AP to send relevant information about the STA over to the newAP (for instance, the PMK).

MOVE.request - APME→IAPP - Invoked when the MLME detects that a STAhas roamed over to this AP.

MOVE.confirm - IAPP→APME - Result indication of the actions following aMOVE.request.

MOVE.indication - MLME→APME - Invoked when the MLME detects aMOVE-notify packet on the DS, indicating that a STA has roamed from thisAP to another in the ESS.

MOVE.response - APME→IAPP - Invoked in response to a MOVE.indication.IAPP then tells the MLME to send relevant information about the STA thatroamed from this AP to the one that sent the MOVE-notify packet.

When proactive caching (see section 2.4.4) is used the APME should first lookin the cache to see if there if the STA’s context is already stored. If that is thecase no MOVE.request is issued until an 802.11 Reassociation Response frame issent (from the old AP the STA was associated with prior to this one). The MACaddress of the old AP is also added to the neighbor graph.

CACHE-NOTIFY

Whenever a STA associates with an AP the CACHE-NOTIFY.request primitiveis invoked. This sends a CACHE-notify packet to each of the neighboring APstelling them to cache the included context. The neighboring APs all answer witha CACHE-response indicating whether the information was already present in thecache or not. The purpose of this class of primitives is explained more thoroughlyin the following section.

CACHE-NOTIFY.request - APME→IAPP - Invoked when the MLMEdetects that a STA associates or re-associates with this AP. IAPP then tellsthe MLME to send CACHE-notify packets to all neighboring APs.


CACHE-NOTIFY.confirm - IAPP→APME - Invoked when the MLME hasreceived CACHE-response packets from all the neighboring APs or atimeout has occurred.

CACHE-NOTIFY.indication - IAPP→APME - Invoked when the MLMEreceives a CACHE-notify packet.

CACHE-NOTIFY.response - APME→IAPP - Invoked by the APME whenthe IAPP entity has finished the actions triggered by theCACHE-NOTIFY.indication. This causes IAPP to tell the MLME to send aCACHE-response packet back as an answer to the CACHE-notify packet.

2.4.4 Proactive Caching

The point of proactive caching is to support fast roaming. This is done by storingthe context information for each STA in the neighboring APs. Each AP maintainsa neighbor graph that is a set of neighbors relative to a given AP. This graph is bestpopulated through dynamic learning by listening for 802.11 Reassociation Requestframes that the STA sends when re-associating with a new AP. The AP can filterout rogue APs by only adding those that get a RADIUS Access-accept message.

Figuring out which APs that are neighbors is done by maintaining a LeastRecently Used (LRU) cache. This will over time weed out neighbors that are mis-identified due to STA moves without radio operation, e.g. when a laptop is closed.Another benefit of a LRU cache is that the size is fixed and therefore easily managed.

2.4.5 Security

The security in 802.11F is based around the AS. Each AP in the ESS has its ownshared secret with the AS, called RADIUS secret4 and at startup they need toregister themselves with the AS. The APs can then later use the AS to establishSecurity Associations (SAs) with each other. As all SAs are verified through the ASthey provide origin authenticity. ESP (Encapsulated Security Payload) is then usedto provide confidentiality through encryption, integrity through MICs and replayprotection through the use of replay counters. The algorithms used for encryptionand MIC generation are unspecified, so any proven algorithm can be used.

4Actually there is a bit of confusion surrounding this. The 802.11F standard use RADIUSBSSID secret and BSSID secret interchangeably. But there is actually another attribute that isalso called BSSID secret that is used to encrypt packets that need to be sent securely betweenAPs. So in this report BSSID secret will signify the encryption secret and RADIUS secret willsignify the secret shared with the RADIUS server.

23

As the RADIUS protocol is the de facto standard there are six packets defined tosupport RADIUS usage: Registration Access-Request, Registration Access-Accept,Registration Access-Reject, Access-Request, Access-Accept and Access-Reject. Thefirst three are only used when IAPP is initiated, the last three each time a SAbetween two APs needs to be established or renewed. In the interest of concisenessonly the last three will be presented in detail. The differences are small and will bepointed out in the text. Details about the other three can be found in the 802.11Fstandard [14]. The messages here map directly to the messages discussed in section2.1.2:

Access-Request - This message is sent to RADIUS when the IAPP entityreceives a MOVE.request primitive. The purpose of this message is twofold:

1. To establish whether or not the old AP is a valid member of the newAP’s ESS.

2. To establish a secure channel to the old AP to allow for contexttransfer.

An important note to make is that this only verifies that the old AP islegitimate, not the STA. The packet contains the following attributes:

User-Name - This is the BSSID represented as a text string containing theMAC address of the AP.

User-Password - As the AP is already authenticated by the pre-sharedsecret and RADIUS has already logged the BSSID secret there is noneed for this attribute in this packet. It is therefore set to NULL. Inthe registration request messages this attribute contains the sharedRADIUS secret.

NAS-IP-Address - The IP address of this AP. Both this and theNAS-Identifier attribute are optional but at least one of them must bepresent in the packet.

Service-Type - Represents the purpose of this message, in this case“IAPP-AP-Check”.

IAPP-Liveliness-Nonce - A nonce provided to ensure that the traffic isnot replayed. This attribute is “Vendor Specific” meaning that onlyIAPP uses it. In the registration request there are three “VendorSpecific Attributes” (VSAs): SSID and cipher suite selectors for boththe encryption and the MIC.

Called-Station-Id - A text string containing the new AP’s MAC addressconcatenated with the SSID and separated by a “:”.


NAS-Identifier - The name of the AP (optional, see NAS-IP-Address).NAS-Port-Type - Used by RADIUS to identify the calling protocol; for

IAPP this attribute is set to 25. This attribute is not present in aregistration request.

Message-Authenticator - The MIC of the packet.

Access-Accept - At reception of this packet the new AP has all the tools itneeds to communicate securely with the old AP. IAPP defines different SAsin each direction so the packet also contains all the information the old APneeds to establish an SA to the new one. The full contents of the packet isthe following:

User-Name - The BSSID of the old AP.Framed-IP-Address - The IP address of the old AP. The registration

accept also has a Service-Type attribute saying that it is anIAPP-Register message.

New-BSSID-Security-Block - SA information for the link going from thenew AP to the old AP. Encrypted with the new AP’s BSSID secret.This attribute is a VSA.

Old-BSSID-Security-Block - SA information for the link going from theold AP to the the new AP. Encrypted with the old AP’s BSSID secret.This block is forwarded to the old AP. This attribute is also a VSA. Aregistration accept has a few more VSAs detailing the encryption keysand the SPI.

Message-Authenticator - The MIC of the packet. The registration acceptalso has a timeout attribute defining the lifetime of the SA.

Access-Reject - This packet is only sent if the old AP is found not being a validmember of of the ESS.

Essentially RADIUS defines and controls all SAs on the APs internal network.All the SAs are then cached in the respective APs so that roaming can be handledefficiently with small latencies. STA context information is, for the same reason,also cached through the proactive caching mechanism. Both the SAs and the cachedcontexts have timeouts associated with them and have to be periodically refreshed.

The actual chain of events triggered in a roaming situation is depicted in figure2.7.

1. The client gets too far away from its currently associated AP and decides tore-associate with another. It then sends a 802.11 Reassociation Requestframe to the new AP.

25

1. Reassociation request

4. Send-Security-Block

5. ACK-Security-Block

3. Access- Accept

2. Access- Request

6. MOVE-notify

7. MOVE-response

8. CACHE-notify multicast to all neighbors

9. All neighbors answer with CACHE-response

New AP Old AP

Roaming Station

Authentication Server

Figure 2.7: A roaming example.


2. The new AP does not have the context information of this client cached andtherefore sends an Access-Request message to the RADIUS server. Themessage tells RADIUS that the new AP wants to know if the old AP islegitimate and if so communicate with it.

3. RADIUS checks if the old AP has a legitimate registration and sends anAccess-Accept back if that is indeed the case. The Access-Accept containsall that the new AP needs to communicate with the old AP. The messagealso contains all that the old AP needs in order to communicate with thenew AP (encrypted so that only the old AP can read it).

4. The new AP sends the part of the message that the old AP needsencapsulated in an Send-Security-Block.

5. The old AP sends back an ACK confirming that it got the security block.

6. The new AP sends a MOVE-notify message over the now secure connectionsaying that “the client that was previously associated with you has nowmoved over to me; please hand over relevant information about this client”.

7. The old AP then sends a MOVE-response message back containing allrelevant information (for instance the PMK).

8. The new AP then sends a CACHE-notify message to all its neighbors tellingthem that “this client just moved over to me, here is the relevant informationabout it in the event that it would roam over to any of you”. This actuallyrequires active security associations with each one of the new APs neighbors,but in this example it is assumed that they are already in place.

9. All the neighbors answer with an CACHE-response that is basically just anACK saying whether or not the client already was cached at them.

27

Chapter 3

Security Analysis

This chapter will provide a general threat overview followed by an examination ofthe different links and the protocols responsible for them. At the end there is alsoa general threat assessment that evaluates the different threats.

3.1 The CIA Model

The analysis of this system will be based on the CIA model. The CIA model isthe generally accepted model for assessing risks in a system. The model has threecomponents:

Confidentiality - Information should only be available to those with the properauthorization.

Integrity - Information should not be altered in any way except by thoseauthorized to do so.

Availability - Information should be accessible to authorized users any time thatit is needed.

The most common way to ensure confidentiality is to encrypt the data but othermethods like physically protecting the link over which the information is sent areequally valid. In a wireless network, however, anyone with an antenna can listenin on the traffic, so the only feasible way of ensuring confidentiality is throughencryption.

Integrity on the other hand, is very hard to ensure (solutions would need toinvolve self-correcting codes), so the most common solution is to detect it rather than

3.2. Common Attack Methods

enforce it. Detecting integrity failures is done through message integrity checksums(MICs).

Availability is probably the hardest one of all. There is little to do but to havea good redundancy and robust systems. Load-balancing servers, for instance, canbe used on traffic-intense systems to alleviate availability problems.

3.2 Common Attack Methods

This section will lists some of the most common attack methodologies and what canbe done to prevent them.

3.2.1 Man-In-The-Middle

A Man-In-The-Middle (MITM) attack is when an attacker tricks a client into be-lieving that he is the entity that the client wants to connect to, in this case an accesspoint. The attacker then takes the authentication information it receives from theclient and logs on to a genuine AP and establishes himself as the man in the middle.The attacker can then eavesdrop on the traffic or simply hijack the session. Thisattack has been a problem especially in tunneled EAP methods such as EAP-TTLSand EAP-PEAP [4]. For a more detailed attack scenario using MITM see section3.2.2.

In order for this attack to be successful the authentication process needs to beone-sided, i.e. only the client is authenticated and not the AP. In order for eaves-dropping to work though, the authentication needs to be simple enough that theattacker can decode and install the session key. Mutual and robust authenticationprevents this attack.

3.2.2 Session Hijack

This type of attack is used by the attacker to gain control of a legitimate user’ssession and use it as his own. It is often used in conjunction with MITM and anattack scenario using a challenge-response protocol can look as follows: An attackerconnects to an AP and receives a challenge. The attacker then poses as an AP toget a client to connect to it. When a client connects to the attacker it gets the samechallenge as the attacker did. The client encrypts it and then sends it back to theattacker. The attacker then forwards the response to the genuine AP and is allowedto log on. As a final act the attacker sends a logoff-message to the client which hasno reason to suspect foul play (and even if it did, there is little, save switching to abetter authentication method, it could do).

29

The conditions necessary to prevent this attack are the same as for MITM.

3.2.3 Packet Manipulation

This is when an attacker takes a sent packet and manipulates the content in somemanner. This is especially easy in wireless systems as all traffic is effectively broad-casted. An attack scenario is as follows: Alice writes a check for $50 to Eve andsends it to her bank. Eve intercepts the check and adds a zero to it to read $500.

This attack can be prevented through the use of MICs.

3.2.4 Replay

This attack is performed by recording a series of packets, for instance an authen-tication exchange, and then replaying them at a later time in order to gain accessillegitimately.

This attack type is handled through the use of replay counters, which is amonotonically increasing counter inserted into each packet. This counter is thenincluded into the MIC. So in order to replay a packet the attacker would not onlyhave to figure out the correct counter value but modify the MIC as well.

3.2.5 Spoofing

Spoofing is when an attacker fakes the origin of a packet in order to achieve some-thing. It can also assume a different identity by switching to a different MACaddress. If an AP only uses MAC association as authentication method this is avery trivial way to gain access to the network. MAC association means that theAP has a list over the MAC addresses that are allowed; packets sent from othersare just thrown away. This technique is often used to facilitate other attacks, forinstance MITM, where the attacker uses spoofing to impersonate an AP to lureclients to connect to it.

The spoofing itself is hard to stop as there exists no network-level method ofascertaining that an entity actually is who he says he is. But spoofing on its ownis rarely a major problem: it has to be combined with some other kind of attack inorder to be really damaging.

3.2.6 Denial of Service

Denial of Service (DoS) is exactly what it sounds like: it is about denying someoneaccess to a service. It can be as easy as setting up a jamming beacon to disrupt theAP’s signals to deny them access to the network. There are basically two kinds of

3.3. The Different Links Involved

DoS attacks: the ones that exploit flaws in the protocols and the ones that use bruteforce to overwhelm the resource. There is no universal panacea for this categoryof attacks; tools designed to cope with them most often analyze traffic and act onanomalous events. But it is hard as some attacks are very subtle and problematicto detect. Having a robust system that is deployed correctly using proven securityprotocols goes a long way against mitigating the DoS threat.

3.2.7 Authentication Method Downgrading

This is a technique employed by an attacker to weaken the defense of a system. Theattacker makes the system believe that it has to use the authentication alternativewith the lowest level of security. This leaves the system more vulnerable to othermeans of attack.

3.3 The Different Links Involved

This section examines the different links in the system. It will look at the protocolsthat are responsible for transport over them and what level of security they provide.

3.3.1 ClientÀAccess Point

This link is the first to be initiated before authentication has taken place. It is avery tricky link to protect since without exchanging encryption keys there can beno protection.

The protocol used on this link is EAPOL (EAP Over LAN), which has no builtin security measures except for the EAPOL-Key frame type. EAPOL-Key framesare used to transport keying information to the client after authentication, anduse RC4 for encryption. They are used (with slight modifications, see the 802.11istandard [15] for details) to protect the traffic during the four-way handshake in802.11i. Earlier, in connection with WEP (section 2.3), it was mentioned that RC4has documented weaknesses. In this case, however, the key is of adequate length(the EAPOL-Key Encryption Key) and the amount of information is so small thatthe risk of exposure is negligible.

The attacks possible on this link are mainly DoS attacks. One potential attackis for an attacker to spoof the MAC address of any client trying to log on to theAP and send a EAPOL-Logoff message. The AP will then immediately shut downthe connection, shutting the client out. If this is done continually the attacker willhave the AP entirely to himself.

31

3.3.2 ClientÀAuthentication Server

This link is the second one (from the client’s perspective) to be established and itonly exists during authentication. The protocol used for this link is EAP but theactual traffic is encapsulated within other protocols during transport. From theclient to the AP traffic is encapsulated in EAPOL packets and from the AP to theAS inside RADIUS packets.

There are no native security mechanisms in the EAP protocol; they are leftentirely to the implemented authentication scheme, which in this case is EAP-SIM. There is an RFC draft detailing security requirements for EAP methods [30],according to which an EAP method must support the following criteria:

1. Session keys must be generated, rather than transported.

2. The effective key strength must be no less than 128 bits.

3. It must support mutual authentication.

4. The EAP peer and server must share the same state at all times during theauthentication process.

5. It must be resistant to dictionary attacks.

6. It must have protection against MITM attacks.

7. Cipher suite negotiation must be protected.

EAP-SIM conforms to all of the above criteria and to many of the recommendedcriteria.

3.3.3 Access PointÀAccess Point

Given a level 3 deployment, this link is taken care of by IPsec using ESP which pro-vides authentication of the APs, traffic confidentiality, traffic integrity, traffic originauthenticity, and replay protection. The encryption and integrity check algorithmsin ESP are unspecified so any proven algorithms can be used.

A level 2 deployment provides authentication of the APs but nothing more. Alevel 1 deployment provides no security at all.

Messages that fall outside the IAPP protocol, however, will not be protected.This would theoretically allow an attacker to connect a “silent” entity to the DSand then change the destination for a packet so that the AP routes it to the silententity on the DS. As the CCMP/TKIP/WEP encryption is only applied to packetssent over the radio interface the AP would then decrypt the packet and send it on

3.4. Known Issues

to the silent entity in plaintext. In order for this attack to work though, the replayprotection and the integrity protection would have to be flawed as they would bothindividually thwart this attack.

3.3.4 Access PointÀAuthentication Server

As RADIUS is the de facto standard for authentication servers the protocol forthis link is RADIUS. The protocol specifies that each Access-Request packet shouldcontain a nonce, called Request Authenticator, ensuring replay protection. This Re-quest Authenticator is then calculated into a MIC, called Response Authenticator,used to ensure integrity for the Access-Accept and Access-Challenge messages. Toensure confidentiality a Keyed Hash (MD5) is used as a stream cipher to encryptthe password field. The shared RADIUS secret is used as key.

There are also extensions to the protocol defined in RFC 2869 [26]. Security-wise there are a few additions, most notably a MIC for all messages. The RFCalso elaborates a little more on the security issues and discusses possible attacks.For instance if the MIC is not used the protocol is vulnerable to hijacking (section7.2.2 in RFC 2869), MITM attacks (section 7.2.3 in RFC 2869) and authenticationmethod downgrading (section 7.2.5 in RFC 2869).

These extensions are not mandatory and might not be implemented in all sys-tems. On the other hand most of the enumerated threats are mitigated with theuse of a robust EAP method such as EAP-SIM (see section 3.3.1 for EAP methodrequirements).

3.4 Known Issues

This section will discuss the known issues of the protocols and standards involved.

3.4.1 802.1X

A few comments about the 802.1X standard have been made by Arunesh Mishraand William A. Arbaugh [22]. The first comment is about the asymmetric natureof 802.1X where the client but not the authenticator is authenticated. The authorsmake the argument that this allows for a MITM attack. The 802.1X protocol ishowever not designed to be used on its own, but rather in conjunction with theEAP protocol. Most EAP methods today are safe from MITM attacks, includingthe EAP-SIM method.

They also comment on the lack of security for the low level signaling betweenthe AP and client. This enables an attacker to spoof a disassociate message to the





33

AP causing the client to lose its connection to the AP. They also claim that thismakes the session vulnerable to hijacking, but this is only true if the attacker alsorecovers the session key for the encryption. Without the session key, hijacking isnot possible.

Thirdly a number of DoS attacks are outlined. These will be covered in section3.4.2.

3.4.2 802.11i

802.11i addresses most security issues in 802.11; most significantly it offers strongconfidentiality and robust authentication. There are, however, still a few threats tothe availability of the system.

ChangHua He and John C. Mitchell point out a possible DoS attack on thefour-way handshake in 802.11i [12]. The attack takes advantage of the fact that thefirst message in the four-way handshake has no MIC and no confidentiality and istherefore easily forged. The attacker spoofs the MAC address of the AP and startssending forged first messages to the client. The reason this message lacks a MICis that since the PMK can be a static pre-shared key the system then would besensitive to replay attacks.

The impact of this attack depends on how the client implements the four-wayhandshake, i.e. if several sessions can exist simultaneously or not. Since Ericssonis developing an AP and this attack is entirely client dependent, it will not beexamined any further.

There are a few other possible DoS scenarios. The EAPOL-Logoff attack men-tioned earlier in section 3.3.1 is a good example. Another example is spoofing of802.11 management frames, especially the disassociate frame. This throws the clientout of the network and forces it to re-associate. Yet another attack involves EAP-Failure message spoofing. This causes an already authenticated supplicant to bede-authenticated and put into a HELD state. It will then be kept in this state for60 seconds before being allowed to re-authenticate [22].

Lastly, there is an attack that starts as many parallel authentications as possibleusing random MAC addresses to fill up the number of allowed associations or thememory of the AP, whichever occurs first.

3.4.3 IAPP

There are no known flaws in IAPP but there has been some talk about the practiceof sharing the PMK with all the APs the client roams to. This criticism has beenbrought forward by the group responsible for creating the new 802.11r standard(called TGr, or Task Group r) in a presentation at the September 2004 IEEE 802

3.4. Known Issues

Wireless Groups Interim Session in Berlin [32]. Their reasoning is that 802.11imakes the following security claims: Data origin authenticity, data integrity, replayimmunity and data confidentiality. They state that the last requirement is notfeasible without the prior three being true. They also state that the first threeassume that pairs of devices have pairwise keys. If they do not have pairwise keys,as the case is in 802.11F, “all the 802.11i security claims are voided”. With respectto 802.11F the complaint is that a client is not authenticated in roaming situations.The ABS 2200 however would combine 802.11F with 802.11i. 802.11i does an newfour-way handshake each time the client roams. An attack would then have to firstcrack the PMK and then crack the MIC as well in order to match the replay counter.

From a practical standpoint it is our opinion that even if this is not an idealpractice it does not pose any long term threat to the system. Aruba WirelessNetworksTM has presented a solution [23] which claims to incorporate a centralizedkey server that stores the PMK and then distributes the PTKs to the different APs.While this is not a standardized solution it appears to be a good one. This solutionis not suitable for the ABS 2200 as it is not designed to have a local server. TheABS is a rather “fat” AP with a lot of functionality and is designed to be part of apeer-to-peer environment. In order for it to work the AP responsible for the WANinterface would have to be redesigned to also work as a site switch. That would betoo expensive to be an option.

3.4.4 RADIUS

The current RADIUS implementation has a number of weaknesses as pointed out byJoshua Hill in his analysis of the RADIUS protocol [13]. His findings are summarizedbelow:

Flawed password protection - RADIUS uses a Keyed Hash (MD5) as a streamcipher primitive, something which it is not designed for. Hill enumeratesfour different attacks based on this vulnerability.

Flawed MIC generation - RADIUS uses MD5 to generate a MIC for allresponse messages. As MD5 has documented weaknesses [33] this is not agood idea.

Many clients create insufficiently unpredictable nonces - Much of thesecurity of RADIUS depends on the generation of the nonce called RequestAuthenticator. The RFC does not emphasize the importance of this enoughand the result is a plethora of poor implementations.

Bad shared secret hygiene - The RADIUS standard specifically permits use ofthe same shared secret by many clients (from this perspective the APs are

35

the clients). This is a bad idea as a single flawed client will allow for severalother to be compromised. This is possible as RADIUS provides noprotection for client or server address. Many implementations also artificiallylimit the shared secret entropy by only allowing ASCII input (where littlemore than a third of the 256 possibilities are readily available on a standardkeyboard) and limiting the length to 16 characters. This greatly reduces thekey space an attacker has to go through in order to find the shared secret.

Any RADIUS servers involved will be the property of the customers, so Ericssonwill only have limited influence over them. There are a few recommendations thatcan be made to the customers. First of all the RADIUS extensions detailed in RFC2869 should be implemented (see section 3.3.4 for details). There are also a fewguidelines when it comes to deployment of a RADIUS server outlined by JosephDavies [7] that can be applied without interfering with the normal function of theserver.

Steps should also be taken to ensure that the clients (in this case the APs)do their part in securing the traffic. Most notably a strong cryptographic PRNG(Pseudo-Random Number Generator) is recommended when constructing the Re-quest Authenticator. As this is done in the AP it is an easy issue to address.Another issue worth emphasizing is the shared secret. This is an area where it istempting to use a single password for all APs in order to simplify management. Aneffort should be made to make it easy for customers to have different passwordsfor each AP. All these changes can be implemented while remaining fully compliantwith the RADIUS protocol.

As mentioned in section 3.3.4, RFC 2869 also points out that the RADIUSprotocol is vulnerable to connection hijacking, in this case meaning that an attackercould inject packets into a conversation between the AP and RADIUS. This ispossible as not all packets are integrity protected. Since RADIUS does not provideend-to-end security, MITM attacks are possible where an attacker could alter EAPpackets in transit. Authentication method downgrading is also a threat if the ASaccepts low-security methods such as EAP-MD5. Customers should be made awareof this.

3.4.5 EAP-SIM

Sarvar Patel has in an analysis [24] pointed out two weaknesses in the EAP-SIMprotocol:

1. Despite concatenation, key strength is still only 64 bits.

2. Lack of session independence.



3.4. Known Issues

This criticism is based on an old draft of the EAP-SIM standard and is no longerentirely correct. The first item refers to the authenticator sending three identicalRAND challenges effectively making the key only 64 bits strong. This has beendisallowed in the later versions of the EAP-SIM draft. The AS is now obliged toprovide distinctly different RAND values and the client is also obliged to check themso that they really are different and not manipulated by an attacker.

The second point has also been addressed in later versions. Session indepen-dence means that even if someone compromises the session key they will not beable to decrypt any traffic beyond the ongoing session. This has been achievedby incorporating the client’s nonce value into the session key. Hence, even if theRAND challenges were to be reused at a later authentication the resulting sessionkey would still be different.

Something that could be a problem however, is if the same SIM chip is used forGSM or GPRS traffic. An attacker could then eavesdrop on the traffic and thatway obtain RAND and SRES values. He can then use brute force to obtain thecorresponding Kc key value for each of those RAND values. This attack is ratherserious and steps should be taken to inform customers that they should not usetheir SIM chips in this manner.

An active attacker could even mount a rogue GSM/GPRS base station attackand start sending previously seen RAND challenges to obtain the SRES values andthen brute force the Kc keys for them. This is possible since EAP-SIM does notprovide PFS (Perfect Forward Security). PFS is when an old session is secure evenif the master key is later discovered.

As this attack requires the attacker to actually build a rogue GSM base stationthe cost of this attack is rather significant. It can be very efficient though, due toseveral weaknesses in the GSM encryption algorithms. The effective key strengthof the Kc keys is much less than the expected 64 bits (no more than 40 bits if theA5/1 GSM algorithm is used [31]; an active attacker can also use authenticationdowngrading to get the client to use the weaker A5/2 algorithm which can be brokenin less than a second [5]).

EAP-SIM also requires that fresh keying material is used each session, i.e. theprobability that the RAND values are repeated is negligible. The EAP-SIM proto-col does not provide any mechanism with which the client can actually check thefreshness of the RAND values though. The functionality for this would have to beimplemented into the client.

37

3.5 Threat Assessment

The threat type that houses the largest quantity attacks is Denial of Service. Thisdoes not however, automatically mean that this is the primary threat to this system.One of the largest DoS attacks to date was mounted in March 2003 when the TVstation Al-Jazeera launched their new English-language website [20]. From themoment it went online it was beset by a constant flood of traffic in what is calleda DDoS attack (Distributed Denial of Service), making it impossible to reach. Theattack persisted over a period of several days until the DNS was redirected to afake, pro-American site. As the redirection also is a form of DoS, the attack is oneof the largest continuous DoS attacks ever. As soon as a DoS attack ceases though,the system returns to full functionality and from a technical standpoint all is wellagain.

There are however a few non-technical consequences that need to be taken intoaccount, especially for a commercial service:

• Loss of revenue while the service is unavailable.

• Customers turn to other services that demonstrate higher availability,leading to further loss of revenue.

• Loss of confidence in the service provider, leading to fewer new customers.

What also needs to be taken into account is how common DoS attacks are. AsDoS attacks are very hard to defend against there needs to be a significant threat ifcountermeasures are to make economical sense. There are tools such as Red-Detectfrom Red-M [25] that claim to detect and thwart many DoS attacks. These arehowever large standalone systems that probably would demand many months todevelop. This should still be an area of interest for Ericsson to look into as publichotspots are prime targets for these kind of attacks.

DoS attacks aside, the APÀAS link seems to be the weakest. When RADIUSis used without EAP, as it is when the APs register via IAPP and request SAswith the other APs, the security level is very low. As mentioned in section 3.3.4,the RADIUS protocol is vulnerable to MITM attacks, connection hijacking andauthentication method downgrading. This means that an attacker could, using nomore equipment than a computer with Internet access and an AP, make a MITMattack on the APÀAS link. Once established as a man in the middle the attackercan proceed and install his own AP and convince the other APs that it is legitimate.With the rogue AP in place he can then listen to all traffic going through the rogueAP and, for instance, collect passwords. Connection hijacking is not as serious,it would only enable the attacker to manipulate traffic going from AP to AS. At

3.5. Threat Assessment

most the attacker could then make the authentication fail, creating a form of DoS.Authentication method downgrading is a problem only if the AS allows low securityEAP-methods such as EAP-MD5. Customers should be informed that this is not agood policy.

39

Chapter 4

Results

This chapter will propose how to apply IAPP in order to solve the problems asso-ciated with roaming. It will also outline how to achieve a more balanced level ofsecurity throughout the system.

4.1 Secure Roaming

A problem discovered a a late stage of this thesis work is that the 802.11F standard isdefunct since July 2004. The key words are Trial-Use that appears in the standard’sname. Trial-Use means that a standard is introduced on a trial basis and needsto be reaffirmed 24 months after its introduction. The 24 month-mark was in July2004 and no reaffirmation was made. The reason for this was probably that 802.11Fis not secure on its own due to the lack of robust authentication.

As one of the premises for this thesis work was that Ericsson wanted a stan-dardized way of handling roaming in a secure way, we cannot recommend 802.11F.That aside we still say that secure roaming can be attained by implementing IAPPin the ABS 2200 if it is combined with 802.11i. The different implementation lev-els provide a way of doing this step by step. This will provide authentication ofall APs on the DS as well as encryption of all traffic sent in roaming situations.IAPP uses IPsec (IP security) with ESP (Encapsulated Security Payload) to pro-vide security for the traffic between APs. ESP is the actual security scheme and isalgorithm independent, so for the actual algorithms we recommend AES to ensureconfidentiality and SHA-1 for integrity.

This solution will also be totally transparent to the end users which is a verydesirable property. Coupled with the use of EAP-SIM the whole system will be very

4.2. Security Recommendations

easy to manage for customers as well as end users.

4.2 Security Recommendations

As APÀAS link is the weakest one in the system we recommend putting an addi-tional layer of security around it. For this purpose we recommend using IPsec withESP exactly in the same manner as in IAPP. This will be more than enough tobring the security up to par with the rest of the system. The solution requires thatthe customer enables IPsec with the AS. If the customer is in some way unable todo this, the recommendation is to implement the RADIUS extensions in RFC 2869and to follow the best deployment practices provided by Joseph Davies [7].

As for the DoS threat we would like for it to be taken seriously. There aremany possible attacks, and there are countermeasures available. Since the counter-measures are complex and expensive, it all comes down to weighing threat againstcost. Our recommendation is that at least some amount of traceability should beprovided for when it comes to DoS attacks.

The chosen authentication method is EAP-SIM and it has been found to providea satisfactory security level. It should be pointed out to end users that they shouldnot use the SIM chip for GSM or GPRS traffic as it provides an avenue of attackon the system.

When it comes to compatibility there exists no actual standard that dictateshow an AP connects to the DS. This means that roaming will have to be handledthrough full reassociation (unless all APs have implemented IAPP). Roaming asidethough, the most common solution is to have a bridged Ethernet setup in order tohave APs from different manufacturers on the same DS.


41

Chapter 5

Discussion

This chapter will discuss the proposed solutions provided in chapter 4 and suggestareas of interest into which further research can be directed.

5.1 Secure Roaming

Since 802.11F is no longer a standard, the result might be a bit disappointing. Itis not a total waste though: IAPP is still the closest thing to a standard and theupcoming 802.11r standard will probably include something very similar to IAPP.

5.2 Security Recommendations

In conjunction with using IPsec there are steps that can be taken to improve theoverall security of the RADIUS protocol. These steps could also be taken on theirown in order to achieve some security. Even though it will not be an acceptable level,it will at least be something. Most steps, though, involves convincing customers toimplement the additions. As mentioned earlier, the document by Joseph Davies[7] contains best deployment practices when using RADIUS and is a good guide tofollow.

IPsec is a desirable solution for many reasons. There already exists IPsec codefor the WAN interface so extending it to the RADIUS should be quite easy. Theexact same setup is also used to secure IAPP traffic so essentially one of themwill come for free. IPsec is also used for security in the successor to the RADIUSprotocol, Diameter. By using IPsec at an early stage the eventual transition to

5.3. Further Research

Diameter will be much smoother. Finally, IPsec is mandatory when implementingIPv6 (IP version 6).

A possible scheme to mitigate DoS attacks on the ClientÀAP link could involvea small public key system designed to protect only the authentication process. Therewould still be a problem for the client to verify the certificate provided by the AP.There is also the fact that this would mean a proprietary solution, which Ericssonhas clearly stated that they do not wish to have.

5.3 Further Research

This report still leaves a few areas of interest to be researched:

• Customers will probably want to be able to use pre-RSN hardware in thehotspots. How will this be handled? Different SSIDs for different securitylevels?

• The ABS 2200 will soon be introducing multiple SSIDs. The problem is thatit in the first version will still have only one MAC address. This in turnrestricts the AP to only one beacon. Only one beacon means that the APcan only advertise one RSN-IE detailing security capabilities of the AP.What impact will this have on the availability and security? Will theavailability have to be restricted by only supporting certain cipher suites orwill the security have to be sacrificed to get a working solution?

• As RADIUS is getting old the successor Diameter is starting to look moreand more interesting. What would supporting the Diameter protocol involvefor Ericsson as well as the customers?

• With the growing 3G market an eventual shift from EAP-SIM to EAP-AKA(EAP Authentication and Key Agreement, which is the equivalent ofEAP-SIM in 3G systems) might be called for. Can they be supportedconcurrently and are there even more EAP-methods that are interesting?

• The ABS 2200 is designed to be remotely managed. How is security handledthen?

• 802.11i specifies a method of fast roaming called pre-authentication. Thisinvolves making the 802.1X exchange via the DS which somewhat goesagainst the design purpose of 802.1X. How does one go about making a802.1X exchange that is not over the radio interface?

43

Glossary

A

Access Point (AP)An entity that provides wireless access to a network. The term is moreor less interchangeable with BSS.See also: BSS, BSSID, Authenticator.

Access Point Management Entity (APME)The entity that handles IAPP communication in an AP.See also: MLME, IAPP.

Additional Authenticated Data (AAD)AAD is a method of ensuring integrity for header data. The headerdata is simply included into the MIC providing origin authenticationas well as integrity.See also: MAC, MIC.

Advanced Encryption Standard (AES)The encryption standard replacing the old Data Encryption Standard(DES). The standard was chosen by NIST out of 15 competing algo-rithms. The chosen algorithm is called Rijndael and is a block cipher.AES uses a 128 bit encryption key (even if Rijndael can support longerkeys) and is considered safe.See also: CCMP.

AuthenticationThe process of determining whether an entity is in fact the same as itclaims to be.See also: Authorization, Authenticator, AS.

GLOSSARY

Authentication, Authorization and Accounting (AAA)A service that can authenticate, authorize and run accounting on re-mote users.See also: AS, RADIUS, Diameter, Authorization, Authentication.

Authentication Header (AH)AH is a per-packet security protocol that provides integrity protection,origin authenticity and replay protection for a packet. AH is a part ofthe IPsec protocol suite and is described in RFC 2402.See also: IPsec, ESP, IKE.

Authentication Server (AS)The entity that shares the secret with the client. It does the actualmatching of these secrets. The AS then tells the Authenticator whetheror not to grant the client access. Most often this is a RADIUS serverbut sometimes the AS resides at the same machine as the authentica-tor.See also: Authenticator, RADIUS, Diameter, Authorization, Authen-tication.

AuthenticatorThe entity that authenticates a client. This entity forwards all au-thentication traffic to the Authentication Server that does the actualauthentication. If the client is who it says it is the AS tells the au-thenticator to grant the client access to the system.See also: Authentication, Authorization, AP.

AuthorizationThe act of granting an entity access to a protected resource. This ispreceded by an Authentication.See also: Authentication, Authenticator, Authentication Server.

B

Basic Service Set (BSS)A BSS is the basic building block of a WLAN. It can be seen as thearea covered by a single AP; the STAs that are connected to that APare then members of that BSS.See also: ESS, BSSID, SSID, IBSS.

Basic Service Set Identifier (BSSID)The“name”of a BSS. Most often the MAC address of the AP providing


45

the BSS.See also: ESS, BSS, SSID, IBSS.

C

Challenge-ResponseIn cryptography a method of authenticating a client by sending it arandom number. The client then needs to encrypt the number with ashared secret and return it.See also: AS.

Cipher Block Chaining (CBC)A mode of operation where each plaintext block is XORed with theprevious encrypted block in order to destroy patterns in the text be-fore encrypting it. This makes each encrypted block dependent on allprevious plaintext blocks.See also: Modes of Operation, CTR, CBC-MAC.

Cipher Block Chaining mode with MAC (CBC-MAC)A mode of operation for block ciphers using Cipher Block Chaining(CBC) for encryption and Message Authentication Code for messageintegrity check. CBC-MAC is described in RFC 3610.See also: Modes of Operation, CTR, CBC, MAC, MIC.

Counter Mode (CTR)A mode of operation that takes the output of a counter, concatenates itwith a nonce (same nonce is used for all blocks), encrypts the resultingvector and finally XORs it with the plaintext. This makes the blockcipher work like a stream cipher and ensures good confidentiality.See also: Modes of Operation, CBC.

Counter-Mode/CBC-MAC Protocol (CCMP)The protocol used for security in 802.11i. CCMP provides confiden-tiality, origin authenticity, integrity and replay protection.See also: CBC-MAC, CTR.

D

Denial of Service (DoS)A class of attacks targeting the availability of a system. Most oftenperformed by taking advantage of a security flaw in order to hang the


GLOSSARY

system or otherwise make it unavailable. It can also be as easy as usinga jamming beacon to disrupt the AP’s signal.

DiameterThe successor to the RADIUS protocol. Diameter is an AAA protocoljust as RADIUS is. It is designed to be backwards compatible withRADIUS while removing many of the functionality limitations imposedby the RADIUS protocol. Diameter has also removed all security func-tionality from the protocol and instead uses IPsec to provide security.Diameter is described in RFC 3588.See also: RADIUS, AS, AAA.

Distributed Denial of Service (DDoS)A large scale version of DOS. Often involving a large number of un-witting participants, called “zombies”, literally flooding a victim withtraffic. This makes it impossible for the victim to do anything elsethan serving all incoming requests.

Distribution System (DS)The internal network the APs are situated on.See also: ESS, AP.

Domain Name Service (DNS)The entity in an IP network that translates a common Internet name,e.g. www.cnn.com, into an IP address.

E

EAP Authentication and Key Agreement (EAP-AKA)The next generation of GSM authentication (3G). EAP-AKA offershigher security and faster authentication than EAP-SIM. EAP-AKAis still in draft status.See also: EAP, EAP-SIM, EAP-TTLS.

EAP Over LAN (EAPOL)A small protocol encapsulating EAP messages sent between supplicantand authenticator over a LAN. The protocol is specified in the IEEE802.1X standard, section 7.See also: EAPOW, EAP.

EAP Over Wireless LAN (EAPOW)Basically the same as EAPOL. The only difference is that EAPOL


www.cnn.com

47

is always broadcasted whereas with EAPOW you already know thereceptor’s address. Nine times out of ten however, the term EAPOLis used.See also: EAPOL, EAP.

EAP Subscriber Identity Module (EAP-SIM)An authentication method using SIM cards. All GSM mobile tele-phones use this technology so it is rather mature. EAP-SIM is still indraft status.See also: EAP, EAP-AKA, EAP-TTLS.

EAP Tunneled Transport Layer Security (EAP-TTLS)An EAP method that first sets up a tunnel to the AS using TLS.The actual authentication then takes place inside the tunnel using anydesired EAP method. EAP-TTLS is still in draft status.

EAPOL-KeyA class of EAPOL packets used to transport encryption keys.See also: EAPOL, EAP.

EAPOL-Key Confirmation Key (KCK)Derived from PTK using the first 128 bits. This is the key used tocompute the MIC for EAPOL-Key packets.See also: EAPOL, PTK, KEK, TK.

EAPOL-Key Encryption Key (KEK)Derived from the PTK using bits 128-255. This key is used to provideconfidentiality for EAPOL-Key packets.See also: EAPOL, PTK, KCK, TK.

Encapsulated Security Payload (ESP)This protocol is a part of the IPsec protocol suite and IAPP. It is usedto encrypt the payload part of a packet and ensures origin authenticity,integrity and confidentiality. ESP is described in RFC 2406.See also: IPsec, IAPP.

Extended Service Set (ESS)Also called Infrastructure Mode this is the normal operating mode fora wireless LAN. All APs belonging to the same hotspot form one orseveral ESSs. The point is to be able to offer several service providersthe use of the same hotspot. Each ESS then has its own SSID.See also: SSID, Hotspot.


GLOSSARY

Extensible Authentication Protocol (EAP)A transport protocol used for network access authentication. It sup-ports a number of different authentication schemes and is a part of the802.1X standard. EAP is described in RFC 3748.See also: EAP-SIM, EAP-AKA, EAP-TTLS.

F

Four-Way HandshakeThe process through which the Pairwise Transient Key is derived andGTK is established. This heightens the security of the system as theexposure of the actual session key (PMK), is minimized.See also: PMK, PTK, GTK.

G

Group Temporal Key (GTK)The cryptographic key used to encrypt and decrypt multicast trafficin an ESS.See also: PMK, PTK, Four-Way Handshake.

H

HotspotAn area with one or more wireless APs providing users with networkaccess.See also: ESS.

I

Independent Basic Service Set (IBSS)Two wireless-capable STAs can form their own BSS by connecting toeach other. This is called an IBSS.See also: STAKey, BSSID.

Initialization Vector (IV)An IV is the first block of bits that starts the encryption process whenusing a block cipher. The first block of plaintext is XORed with thisblock in order to mask the properties of the plaintext.See also: Modes of Operation.


49

IntegrityRefers to the validity of data, i.e. whether or not it has been alteredin any way since being entered.

Inter Access Point Protocol (IAPP)A protocol for signaling between APs in an ESS. It is used to facili-tate roaming and has functionality for encrypting the traffic. IAPP isdescribed in the 802.11F standard.See also: MLME, APME.

International Mobile Subscriber Identity (IMSI)A unique value identifying a GSM subscriber, rather like a MAC ad-dress.See also: EAP-SIM.

Internet Key Exchange (IKE)IKE is a protocol for setting up an shared session secret from whichcryptographic keys then can be derived. IKE uses the Diffie-Hellmankey exchange technique to do this. IKE is a part of the IPsec protocolsuite and is described in RFC 2409.See also: IPsec, ESP, AH.

IP security (IPsec)A collection of protocols designed to provide security to the InternetProtocol. It consists of three major parts: Authentication Header(AH), Encapsulated Security Payload (ESP) and Internet Key Ex-change (IKE).See also: AH, ESP, IKE.

IP version 6 (IPv6)The successor to the current Internet Protocol (IPv4). IPv6’s mainfeatures are a much larger address space (2128 compared to 232 inIPv4) and an obligatory security suite called IPsec.See also: IPsec.

K

Keyed HashA function that takes an arbitrary input together with a secret sharedkey and produces an output of fixed size. The properties of this outputis that it is mathematically infeasible to find the original message giventhis output. It is also infeasible to produce two messages that generate


GLOSSARY

the same output, also called a collision. Examples of well known keyedhash functions are SHA-1 and MD5.See also: MAC, MIC.

L

Least Recently Used (LRU)A rule determining which object in a fixed-size cache to flush when anew object enters. In this case the object that has been in the cachethe longest since it was last accessed. This rule is based on temporallocality - the observation that, the cache entry which has not beenaccessed for longest is least likely to be accessed in the near future.

LivenessA method of ensuring that temporal keys are going to be different eachsession, that old keys will no longer work. This is achieved by includingspecial values called Nonces in the computation. Sometimes livenessis referred to as liveliness.See also: Replay attack.

Local Area Network (LAN)A small office-sized network.See also: WLAN.

M

MAC-Layer Management Entity (MLME)The entity in an AP that sends and receives the actual IAPP packets.See also: APME, IAPP.

Man-In-The-Middle (MITM)A class of attacks where the attacker tricks a victim into believing thathe is a legitimate server for the victim to connect to. When the victimthen connects to the attacker, the attacker proceeds to connect to thereal server using the victim’s credentials. This places the attacker asthe “man in the middle” and enables a variety of attacks, for instancesession hijacking.

Master Key (MK)The key negotiated through the the secret shared between the AS andthe client. Used to compute the Pairwise Master Key (PMK).See also: PMK.

51

Media Access Control (MAC)A MAC address is a hardware address assigned to all network equip-ment, uniquely identifying it to the network.See also: MAC, MIC.

Message Authentication Code (MAC)A keyed hash calculated over a packet in order to ensure integrity(that it has not been tampered with). When dealing with networksit is often referred to as MIC (Message Integrity Check) in order toavoid confusion with MAC address (Media Access Control). In orderto avoid confusion the term MIC is used throughout this report.See also: MIC, Keyed Hash.

Message Integrity Check (MIC)A keyed hash calculated over a packet in order to ensure integrity(that it has not been tampered with). The MIC implemented in TKIPis called Michael. Normally in cryptography these hashes are calledMAC (Message Authentication Code) but when dealing with networksit has been renamed in order to avoid confusion with MAC address(Media Access Control). Another source of confusion is that the MACactually deals with integrity rather than authentication.See also: MAC, Keyed Hash.

Modes of OperationBlock ciphers operates on blocks of fixed length. In order to encryptlonger messages than the block size allows, different modes of operationare used. The modes are ways of ensuring confidentiality and in somecases also integrity. More information about modes of operation canbe found at http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation.See also: CTR, CBC, MAC, MIC.

N

Network Access Server (NAS)Used in RFC 2865 (RADIUS) to signify the authenticating entity, nor-mally the AP.See also: Authenticator, AP, RADIUS.

NonceActually a word from medieval times meaning a word which is only

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation


GLOSSARY

used “for the nonce” - to meet a need that is not expected to recur. Inthis context it signifies a number that is random and only used oncein order to achieve added randomness when computing cryptographickeys.

P

Pairwise Master Key (PMK)This key is derived from the Master Key (MK) that is the shared secretbetween the client and the AS. The PMK is unique for each sessionand tied to a specific AP-STA couple. The PMK is then transformedinto to the PTK by concatenating the PMK, a nonce from the AP, anonce from the STA and the respective MAC addresses of the AP andSTA. The string is then put into a Keyed Hash and the final result isthe PTK.See also: PTK, Keyed Hash.

Pairwise Transient Key (PTK)This key is derived from the PMK and is periodically renewed. ThePTK is divided up into three keys; EAPOL-Key Confirmation Key(KCK), EAPOL-Key Encryption Key (KEK) and a Temporal Key(TK)See also: PMK, KEK, KCK, TK.

Perfect Forward Security (PFS)Perfect Forward Security means that even if a shared secret is com-promised, earlier sessions encrypted with the same secret should notbe compromised.

Point to Point Protocol (PPP)A protocol used to establish a connection between two computers.Most often used by ISPs when providing dial-up access to modempools. PPP is described in RFC 1661.See also: EAP.

Pseudo-Random Number Generator (PRNG)An algorithm which generates a sequence of numbers, the elements ofwhich are approximately independent of each other. For obvious rea-sons a deterministic algorithm run on deterministic hardware can neverprovide truly random numbers, hence the name “pseudo-random”.


53

R

Remote Authentication Dial-In User Service (RADIUS)RADIUS is an AAA protocol that handles Authentication, Authoriza-tion and accounting of remote users. RADIUS is described in RFC2865.See also: AAA, AS, Authentication, Authorization.

Replay attackAn attack in which the attacker records a communication session andthen later replays the whole or parts of it. For instance, if Alice hastransferred money to Eve, Eve can then replay the transaction in orderto transfer more money.

RoamingA term to describe when a connected entity has to move its associationto another access point due to straying so far from the original AP thatthe signal strength is suffering.See also: IAPP.

Robust Security Network (RSN)A concept introduced with 802.11i, RSN is a network that only acceptssecure associations. Only CCMP is considered secure enough for fullRSN compliance. TKIP and WEP are collected under what is calledTSN (Transition Security Network). Other requirements are 802.1Xauthentication and key management using the four-way handshake.The algorithms that a specific AP supports are advertised through theRSN-IE.See also. RSN-IE.

RSN Information Element (RSN-IE)RSN/WPA systems have a specific Information Element that specifieswhat kind of security mechanisms are supported. If an AP supportseither RSN or WPA (or both) it advertises this in its beacon and proberesponses.See also: RSN.

S

Security Association (SA)A relationship between two or more entities that describe how theentities will utilize security services to communicate securely. Within



GLOSSARY

IPsec an SA is always used in conjunction with either AH or ESP.SAs are uni-directional so in order to secure a typical bi-directionalcommunication between two entities two SAs are required. There canbe up to two active SAs for the same link as fresh encryption keystakes time to propagate to all APs when the old ones have expired.The properties of a certain SA can be found in the SPI of an AH orESP packet.See also: SPI, ESP, AH, IPsec.

Security Parameter Index (SPI)An information element that identifies which SA that was used to senda packet.See also: SA, ESP.

Service Set Identifier (SSID)The SSID identifies an Extended Service Set. The SSID is broadcastedin the beacon of an AP.See also: Hotspot, ESS.

Station (STA)Synonymous to client, often used when speaking out of an AP per-spective.

Station Key (STAKey)The equivalent to PTK in an IBSS. STAKey is the key used for trafficencryption over that link.See also: IBSS.

Substitution Box (S-box)A basic component in most shared secret cryptosystems. Its used toobscure the relationship between plaintext and ciphertext. Basicallyit is a lookup table that takes m input bits and transforms them inton output bits.

T

Temporal Key (TK)Derived from the PTK using the last 256 bits if TKIP is used, the last128 bits if CCMP is used. This is the key used to encrypt the actualwireless traffic.See also: KEK, KCK, PTK.

55

Temporal Key Integrity Protocol (TKIP)TKIP is the encryption protocol in WPA. It acts as a wrapper to WEPand addresses all known flaws in WEP. It adds integrity protection,replay protection, active countermeasures and a mixing function thateliminates the weak keys of WEP. At the time of writing, there existsno practical attacks against TKIP.See also: WEP, WPA.

V

Vendor Specific Attribute (VSA)Used to signify attributes in a standard that are aimed at a specificvendor or protocol. 802.11F for instance, has several RADIUS specificattributes.See also: RADIUS.

Voice over IP (VoIP)A protocol for sending voice traffic over an IP network enabling tele-phony services. This places high demands on the network in terms oflow latencies and stability.

W

Wi-Fi Protected Access (WPA)An intermediate standard framework designed to address the variousweaknesses found in WEP. It is based upon an early draft of the 802.11istandard and involves 802.1X, EAP and TKIP.See also: EAP, TKIP.

Wired Equivalent Protection (WEP)The first attempt at securing wireless networks. This protocol hasmany weaknesses which led to the development of WPA and 802.11i.See also: TKIP, WPA.

Wireless Local Area Network (WLAN)The wireless equivalent to a LAN, if comprised of several APs it is alsocalled a Hotspot.See also: Hotspot, ESS, BSS, LAN.

BIBLIOGRAPHY

Bibliography

[1] Bernard Aboba, Larry J. Blunk, John Vollbrecht, James Carlson, and Hen-rik Levkowetz. RFC 3748 – Extensible Authentication Protocol, June 2004.Available at http://www.ietf.org/rfc/rfc3748.txt.

[2] Bernard Aboba and Pat R. Calhoun. RFC 3579 – RADIUS (Remote Authen-tication Dial In User Service) Support For Extensible Authentication Protocol(EAP), September 2003. Available at http://www.ietf.org/rfc/rfc3579.txt.

[3] Wi-Fi Alliance. Wi-Fi Protected Access. Version 2.0, April 2003. Availablethrough http://www.wi-fi.org/.

[4] Nadarajah Asokan, Valtteri Niemi, and Kaisa Nyberg. Man-in-the-Middle inTunneled Authentication Protocols, November 2002. Available at http://eprint.iacr.org/2002/163.pdf.

[5] Elad Barkan, Eli Biham, and Nathan Keller. Instant Ciphertext-Only Crypt-analysis of GSM, May 2003. Available at http://www.cs.huji.ac.il/labs/danss/presentations/GSM.ps.

[6] Pat R. Congdon, Bernard Aboba, Andrew Smith, Glen Zorn, and John Roese.RFC 3580 – IEEE 802.1X Remote Authentication Dial In User Service (RA-DIUS) Usage Guidelines, September 2003. Available at http://www.ietf.org/rfc/rfc3580.txt.

[7] Joseph Davies. RADIUS Protocol Security and Best Practices, January 2002.Available at http://www.microsoft.com/technet/itsolutions/network/security/radiusec.mspx.

[8] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. RFC 1750– Randomness Recommendations for Security, December 1994. Available athttp://www.ietf.org/rfc/rfc1750.txt.




http://www.wi-fi.org/

http://eprint.iacr.org/2002/163.pdf

http://eprint.iacr.org/2002/163.pdf

http://www.cs.huji.ac.il/labs/danss/presentations/GSM.ps

http://www.cs.huji.ac.il/labs/danss/presentations/GSM.ps



http://www.microsoft.com/technet/itsolutions/network/security/radiusec.mspx

http://www.microsoft.com/technet/itsolutions/network/security/radiusec.mspx


57

[9] Jon Edney and William A. Arbaugh. Real 802.11 Security : Wi-Fi ProtectedAccess and 802.11i. Addison Wesley, 1st edition, July 2003.

[10] Scott Fluhrer, Itsik Mantin, and Adi Shamir. Weaknesses in the Key Schedul-ing Algorithm of RC4. Lecture Notes in Computer Science, 2259:1–24, 2001.Available at http://www.crypto.com/papers/others/rc4_ksaproc.pdf.

[11] Henry Haverinen and Joseph Salowey. Extensible Authentication Proto-col Method for GSM Subscriber Identity Modules (EAP-SIM). Internetdraft (work in progress), October 2004. Available at http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-14.txt.

[12] ChangHua He and John C. Mitchell. 1 Message Attack on the 4-Way Hand-shake. IEEE document number 11-04-0497-00-000i, May 2004. Presented at theMay 2004 IEEE 802 Wireless Groups Interim Session, Garden Grove Californiaand available through http://grouper.ieee.org/groups/802/11/.

[13] Joshua Hill. An Analysis of the RADIUS Authentication Protocol, Novem-ber 2001. Available at http://www.untruth.org/~josh/security/radius/radius-auth.html.

[14] IEEE Std 802.11FTM-2003. IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol AcrossDistribution Systems Supporting IEEE 802.11TM Operation, 2003. Availableat http://standards.ieee.org/getieee802/download/802.11F-2003.pdf.

[15] IEEE Std 802.11iTM-2004. IEEE Standard for Information Technology –Telecommunications and Information Exchange between systems – Local andMetropolitan Area Networks – Specific Requirements Part 11: Wireless LANMedium Access Control (MAC) and Physical Layer (PHY) SpecificationsAmendment 6: Medium Access Control (MAC) Security Enhancements, 2004.Available through http://www.ieee.org/.

[16] IEEE Std 802.11TM, 1999 Edition. IEEE Standard for Information Tech-nology – Telecommunications and Information Exchange between Systems –Local and Metropolitan Area Network – Specific Requirements – Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)Specifications, 1999. Available at http://standards.ieee.org/getieee802/download/802.11-1999.pdf.

[17] IEEE Std 802.1X-2001. IEEE Standard for Local and Metropolitan AreaNetworks – Port-based Network Access Control, 2001. Available at http://standards.ieee.org/getieee802/download/802.1X-2001.pdf.

http://www.crypto.com/papers/others/rc4_ksaproc.pdf

http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-14.txt

http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-14.txt

http://grouper.ieee.org/groups/802/11/

http://www.untruth.org/~josh/security/radius/radius-auth.html

http://www.untruth.org/~josh/security/radius/radius-auth.html

http://standards.ieee.org/getieee802/download/802.11F-2003.pdf

http://www.ieee.org/

http://standards.ieee.org/getieee802/download/802.11-1999.pdf

http://standards.ieee.org/getieee802/download/802.11-1999.pdf

http://standards.ieee.org/getieee802/download/802.1X-2001.pdf

http://standards.ieee.org/getieee802/download/802.1X-2001.pdf

BIBLIOGRAPHY

[18] Stephen Kent and Randall Atkinson. RFC 2401 – Security Architecture for theInternet Protocol, November 1998. Available at http://www.ietf.org/rfc/rfc2401.txt.

[19] Stephen Kent and Randall Atkinson. RFC 2406 – IP Encapsulating Secu-rity Payload (ESP), November 1998. Available at http://www.ietf.org/rfc/rfc2406.txt.

[20] Robert Lemos. Al-Jazeera struggles against continued attacks. News arti-cle at ZDNet.co.uk, March 2003. Available at http://news.zdnet.co.uk/business/0,39020645,2132618,00.htm.

[21] Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. Handbookof Applied Cryptography. CRC Press, 5th edition, August 2001. Available athttp://www.cacr.math.uwaterloo.ca/hac/.

[22] Arunesh Mishra and William A. Arbaugh. An Initial Security Analysis of theIEEE 802.1X Standard, February 2002. Available at http://www.cs.umd.edu/~waa/pubs/1x.pdf.

[23] Aruba Wireless NetworksTM. Mobility in an 802.11i Enabled WirelessLAN, August 2004. Available at http://www.arubanetworks.com/pdf/802.11i-mobility.pdf.

[24] Sarvar Patel. Analysis of EAP-SIM Session Key Agreement, May 2003. Avail-able at http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf.

[25] Red-M. Red-DetectTM Wi-Fi and Bluetooth intrusion detection and preven-tion.

[26] Carl Rigney, Ward Willats, and Pat R. Calhoun. RFC 2869 – RADIUS Exten-sions, June 2000. Available at http://www.ietf.org/rfc/rfc2869.txt.

[27] Carl Rigney, Steve Willens, Allan C. Rubens, and William A. Simpson. RFC2865 – Remote Authentication Dial In User Service (RADIUS), June 2000.Available at http://www.ietf.org/rfc/rfc2865.txt.

[28] Vebjørn Moen, Havard Raddum, and Kjell J. Hole. Weaknesses in the TemporalKey Hash of WPA. Mobile Computing and Communications Review, April2004. Available at http://www.nowires.org/Papers-PDF/WPA_attack.pdf.

[29] William Allen Simpson. RFC 1661 – The Point-to-Point Protocol (PPP), July1994. Available at http://www.ietf.org/rfc/rfc1661.txt.





http://news.zdnet.co.uk/business/0,39020645,2132618,00.htm

http://news.zdnet.co.uk/business/0,39020645,2132618,00.htm

http://www.cacr.math.uwaterloo.ca/hac/

http://www.cs.umd.edu/~waa/pubs/1x.pdf

http://www.cs.umd.edu/~waa/pubs/1x.pdf

http://www.arubanetworks.com/pdf/802.11i-mobility.pdf

http://www.arubanetworks.com/pdf/802.11i-mobility.pdf

http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf



http://www.nowires.org/Papers-PDF/WPA_attack.pdf


[30] Dorothy Stanley, Jesse Walker, and Bernard Aboba. EAP MethodRequirements for Wireless LANs. Internet draft (work in progress),August 2004. Available at http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-04.txt.

[31] Lauri Tarkkala. Attacks against A5, 2000. Available at http://www.hut.fi/~ltarkkal/netsec.ps.

[32] Jesse Walker. Task Group r Security Requirements. IEEE document number11-04-1048-00-000r, September 2004. Presented at the September 2004 IEEE802 Wireless Groups Interim Session, Berlin and available through http://grouper.ieee.org/groups/802/11/.

[33] Xiaoyun Wang, Dengguo Feng, Xuejia Lai, and Hongbo Yu. Collisions for HashFunctions MD4, MD5, HAVAL-128 and RIPEMD. Cryptology ePrint Archive,Report 2004/199, 2004. Available at http://eprint.iacr.org/.

[34] Doug Whiting, Russel Housely, and Niels Ferguson. RFC 3610 – Counter withCBC-MAC (CCM), September 2003. Available at http://www.ietf.org/rfc/rfc3610.txt.

http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-04.txt

http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-04.txt

http://www.hut.fi/~ltarkkal/netsec.ps

http://www.hut.fi/~ltarkkal/netsec.ps



http://eprint.iacr.org/



Avdelning, institutionDivision, Department

DatumDate

SprakLanguage

2 Svenska/Swedish4 Engelska/English

2

RapporttypReport Category

2 Licentiatavhandling4 Examensarbete2 C-uppsats2 D-uppsats2 Ovrig rapport2

URL for elektronisk version

ISBN

ISRN

Serietitel och serienummerTitle of Series, Numbering

ISSN

TitelTitle

ForfattareAuthor

SammanfattningAbstract

NyckelordKeywords

ADIT, Department of Computer andInformation Science581 83 LINKOPING

2004-12-22

http://www.ep.liu.se/

LITH-IDA-EX--04/116--SE

Snabb och saker roaming i WLAN


Magnus Falk

This thesis investigates how Ericsson AB should do to achieve fast and secure handoverwhen roaming in a WLAN. It also provides a security analysis of the system that thewireless access point is part of.The reason for this is that Ericsson is selling an access point called the ABS 2200 aimedat the public hotspot market. The premise was that they wanted a standardized wayof handling the roaming issue. At the outset the 802.11F standard looked like a goodalternative (in fact the only standardized alternative). Towards last stages of the workthough, it was discovered that the 802.11F standard is no longer supported by IEEE.Despite this fact, the conclusion is that secure and fast roaming can be attained if 802.11Fis combined with the security standard 802.11i.The security analysis concludes that Denial Of Service is a major threat to WLANhotspots. It also points out the link between the access point and authentication serveris the weakest link in the system. The recommendation is that this link receives anadditional layer of protection through IPsec with ESP. The algorithm recommendationsfor ESP are AES for confidentiality and SHA-1 for integrity.This thesis can also be used as a primer on security in WLAN and contains an extensiveglossary making it useful as a reference when reading 802.11 standards.

802.11, 802.11i, 802.11F, IAPP, WPA, WPA2, RADIUS, EAP-SIM, WLAN, 802.1X


Copyright

Svenska

Detta dokument halls tillgangligt pa Internet - eller dess framtida ersattare - underen langre tid fran publiceringsdatum under forutsattning att inga extra-ordinaraomstandigheter uppstar.

Tillgang till dokumentet innebar tillstand for var och en att lasa, ladda ner,skriva ut enstaka kopior for enskilt bruk och att anvanda det oforandrat for ickekom-mersiell forskning och for undervisning. Overforing av upphovsratten vid en senaretidpunkt kan inte upphava detta tillstand. All annan anvandning av dokumentetkraver upphovsmannens medgivande. For att garantera aktheten, sakerheten ochtillgangligheten finns det losningar av teknisk och administrativ art.

Upphovsmannens ideella ratt innefattar ratt att bli namnd som upphovsmani den omfattning som god sed kraver vid anvandning av dokumentet pa ovanbeskrivna satt samt skydd mot att dokumentet andras eller presenteras i sadanform eller i sadant sammanhang som ar krankande for upphovsmannens litteraraeller konstnarliga anseende eller egenart. For ytterligare information om LinkopingUniversity Electronic Press se forlagets hemsida http://www.ep.liu.se/

English

The publishers will keep this document online on the Internet - or its possible re-placement - for a considerable time from the date of publication barring exceptionalcircumstances.

The online availability of the document implies a permanent permission for any-one to read, to download, to print out single copies for your own use and to use itunchanged for any non-commercial research and educational purpose. Subsequenttransfers of copyright cannot revoke this permission. All other uses of the docu-ment are conditional on the consent of the copyright owner. The publisher hastaken technical and administrative measures to assure authenticity, security andaccessibility.

According to intellectual property law the author has the right to be mentionedwhen his/her work is accessed as described above and to be protected against in-fringement. For additional information about the Linkoping University ElectronicPress and its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

c© Magnus FalkLinkoping, 10th January 2005



fast and secure roaming in wlan - diva portal

Documents