Fast and Secure Roaming in WLAN

Final thesis Fast and Secure Roaming in WLAN Performed for Ericsson AB by Magnus Falk LITH-IDA-EX--04/116--SE 2004-12-22

i Final thesis Fast and Secure Roaming in WLAN by Magnus Falk LiTH-IDA-EX--04/116--SE Supervisors: Bo Kvarnström CPE Products & Solutions at Ericsson AB David Byers Division for Database and Information Techniques at Linköping university Examiner: Nahid Shahmehri Department of Computer and Information Science at Linköping university

iii Abstract This thesis investigates how Ericsson AB should do to achieve fast and secure handover when roaming in a WLAN. It also provides a security analysis of the system that the wireless access point is part of. The reason for this is that Ericsson is selling an access point called the ABS 2200 aimed at the public hotspot market. The premise was that they wanted a standardized way of handling the roaming issue. At the outset the 802.11F standard looked like a good alternative (in fact the only standardized alternative). Towards last stages of the work though, 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.11F is combined with the security standard 802.11i. The security analysis concludes that Denial Of Service is a major threat to WLAN hotspots. It also points out the link between the access point and authentication server is the weakest link in the system. The recommendation is that this link receives an additional layer of protection through IPsec with ESP. The algorithm recommendations 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 an extensive 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 Kvarnström and Rasmus Axén. Both have been very helpful with comments and discussions around different topics in the report. My supervisor at the university, David Byers, for helping out with a lot of little oddities and my examiner, Nahid Shahmehri. I would also like to thank Stefan Rommer and Sten Sjöberg at Ericsson in Göteborg for expertise on the 802.11F, 802.11i and WPA standards. Jesse Walker at Intel and 802.11 Task Group r at IEEE for discussions about security in 802.11 in general and 802.11F in particular. Gustaf Oldburg, Peter Agzz and Mikael Tallbent for help with proofreading (and the others in team286 for general comments). And finally my wonderful girlfriend Jonna for being the strictest proofreader of them all and generally great support throughout the process.

vii Contents 1 Introduction 1 1.1 Background................................ 1 1.2 Purpose.................................. 1 1.3 Problem.................................. 2 2 System Overview 3 2.1 Authentication.............................. 3 2.1.1 The 802.1X Standard...................... 4 2.1.2 The RADIUS Protocol...................... 5 2.1.3 The Extensible Authentication Protocol............ 6 EAP-SIM............................. 7 2.2 The 802.11i Standard.......................... 10 2.2.1 The Four-Way Handshake.................... 10 2.2.2 Robust Security Network.................... 11 2.2.3 CCMP............................... 13 2.2.4 Security Associations....................... 13 Pairwise Master Key Security Association........... 13 Pairwise Temporal Key Security Association......... 14 Group Temporal Key Security Association........... 14 Station Key Security Association................ 15 2.3 The Wi-Fi Protected Access Framework................ 15 2.3.1 The Temporal Key Integrity Protocol............. 15 2.4 The 802.11F Standard.......................... 16 2.4.1 IAPP Structure.......................... 18 2.4.2 Network Packets......................... 18 2.4.3 Service Primitives........................ 20 INITIATE and TERMINATE.................. 20 ADD................................ 20

CONTENTS MOVE............................... 21 CACHE-NOTIFY........................ 21 2.4.4 Proactive Caching........................ 22 2.4.5 Security.............................. 22 3 Security Analysis 27 3.1 The CIA Model.............................. 27 3.2 Common Attack Methods........................ 28 3.2.1 Man-In-The-Middle....................... 28 3.2.2 Session Hijack.......................... 28 3.2.3 Packet Manipulation....................... 29 3.2.4 Replay............................... 29 3.2.5 Spoofing.............................. 29 3.2.6 Denial of Service......................... 29 3.2.7 Authentication Method Downgrading............. 30 3.3 The Different Links Involved...................... 30 3.3.1 Client Access Point....................... 30 3.3.2 Client Authentication Server................. 31 3.3.3 Access Point Access Point................... 31 3.3.4 Access Point Authentication Server.............. 32 3.4 Known Issues............................... 32 3.4.1 802.1X............................... 32 3.4.2 802.11i............................... 33 3.4.3 IAPP............................... 33 3.4.4 RADIUS............................. 34 3.4.5 EAP-SIM............................. 35 3.5 Threat Assessment............................ 37 4 Results 39 4.1 Secure Roaming.............................. 39 4.2 Security Recommendations....................... 40 5 Discussion 41 5.1 Secure Roaming.............................. 41 5.2 Security Recommendations....................... 41 5.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 wireless access point (AP) designed to provide Internet access in public areas. Such zones of access are usually called Hotspots and are comprised of several APs clustered together in order to achieve good signal strength everywhere in the intended area. In order for this solution to work, there needs to be a transparent way for a session to be moved from one AP to another. Ideally this is done without the user ever noticing the switch. The focus in this report will be how to achieve this in a secure manner. 1.2 Purpose The purpose of this thesis is to investigate how Ericsson should go about sending encrypted messages over a network consisting of wireless APs. This is called for when the client is roaming from one AP to another. The encryption keys then need to 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 on security, to determine where the weakest link is and whether there is an appropriate level of security throughout the system.

1.3. Problem 1.3 Problem Wireless networks are by nature insecure as all traffic is essentially broadcasted and anyone with an antenna can pick it up. It is therefore imperative that all traffic is encrypted in order to protect the privacy of the users. Currently, roaming in the ABS 2200 is handled by forcing the client to make a full re-authentication. This re-negotiation of encryption keys is the main source of latency in roaming. So while this is a working and secure solution, it is definitely not a ideal one. In order to achieve the low latency desired, the encryption keys would have to be transported to the next AP. Currently there is no way of doing this 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 Hotspot and ESS (Extended Service Set). There are a number of components involved in this but the three main entities are the client, the access point (AP) and the authentication 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 called station (STA) or supplicant depending on the context). Most often this is a laptop with a wireless network card. The access point (AP) is the entity that provides the network access and acts as the gatekeeper of the system. Finally, the authentication server (AS) is the entity that ensures that the client is authorized to utilize the system. Authentication is a natural starting point for the description of this system. The tools available to facilitate authentication and the manner in which they are applied will be outlined, followed an overview of the 802.11i standard and what security it adds to the system. This is followed by a brief section about what WPA is and how it relates to WPA2 (which is what Wi-Fi Alliance calls their approved interoperable implementation of 802.11i). The chapter closes with a look at the 802.11F standard and how it facilitates fast roaming. 2.1 Authentication Authentication is the act of ascertaining that an entity (called supplicant in this context) actually is who it claims to be. If a supplicant passes this test of admission

2.1. Authentication Access Point Authenticator Authentication Server AAA Server Client Station Supplicant Figure 2.1: An overview of the system. it is authenticated and is allowed access to the protected resource. To facilitate this process a set of tools have been developed. The tools that will be examined are 802.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. It defines 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 an AAA server (Authentication, Authorization and Accounting). When a Supplicant connects to an authenticator it is restricted to a port 1 that only allows EAP (Extensible Authentication Protocol) traffic to the AS. 802.1X acts as a gatekeeper taking orders from the AS. The actual authentication process can now take place in a safe manner as the supplicant is only allowed to talk to the gatekeeper. The gatekeeper then handles all the communication to the AS. When the AS finally authorizes the supplicant the other port is opened and the client is 1 This is not a port in the TCP sense; it is only used as an abstraction of the 802.1X interface.

5 Authenticator Supplicant Authorize Distribution System Authentication Server Figure 2.2: The 802.1X port interface. allowed full access to the distribution system (DS). A model of the port interface can be seen in figure 2.2. 2.1.2 The RADIUS Protocol RADIUS [27] stands for Remote Authentication Dial-In User Service and is an AAA protocol. This is the entity that perform the actual authentication. It also runs accounting on authorized entities but that functionality will not be covered in this document as the focus is on security. RADIUS is a protocol originally designed to provide remote authentication for ISP modem pools. Instead of having the customers making long-distance calls to a centralized authentication server the customer could call a local modem pool that then used RADIUS to authenticate the customer. The scheme has since been extended to accommodate EAP in RFC 3579 where EAP packets are simply encapsulated within RADIUS ones. With respect to authentication RADIUS defines four message types: Access-Request - Sent by the authenticator entity (in our case the AP) to the AS. It conveys information used to determine whether the user is allowed access or not. Access-Accept - Sent by the AS to indicate successful authentication. Access-Reject - Sent by the AS to indicate unsuccessful authentication.

2.1. Authentication Access-Challenge - Sent when the Access-Request message indicates that the user 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 Point Protocol [29] (PPP) and is a protocol facilitating remote authentication. In itself it is a rather simple protocol specifying only four different types of messages to be sent: 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-Response scheme.

7 The authenticator only acts as a middle man, relaying all EAP messages between client and AS. When the AS eventually sends an accept/failure the authenticator acts accordingly. EAP only acts as a wrapper for the actual authentication method leaving the field open for a large variety of schemes. This report will only discuss the EAP-SIM method, which Ericsson deems the most appropriate choice for the ABS 2200. EAP-SIM The EAP-SIM [11] method is an interesting technique as it involves already established technology. All GSM-SIM cards have a pre-shared key installed providing a simple solution to the key sharing problem. This is convenient for the users as they do not need to bother with any certificates or other authentication schemes. Additionally, the same billing system used for the subscription can be used to charge the WLAN-access. Authentication in GSM Even though GSM was originally designed for voice communications rather than data transfer, the authentication procedure looks a lot like the ones used in data security. The authentication uses a Challenge-Response scheme whereby the GSM server (GSM AC) sends a random value which the phone encrypts with its shared key and sends back for verification. When a phone wants to authenticate it first sends its identification number, or IMSI (International Mobile Subscriber Identity) to the network. The local network then forwards the IMSI to the GSM server that responds by sending a triplet back to the local network. The triplet is comprised by the following items: A random challenge (RAND). A response value (SRES) achieved by encrypting 2 the RAND value with the shared secret. A 64-bit session key (Kc), generated from combining the shared secret with the RAND value. The local network then forwards the RAND to the phone which combines the shared secret with the RAND to compute the session key Kc and the SRES value which it then sends back to the local network. The local network can now verify that the phone knows the shared secret by comparing the two SRES values. The session can now be initiated by using the Kc session key for encryption. 2 Actually it uses a Keyed Hash function.

2.1. Authentication Authentication in WLAN In order to achieve satisfactory security levels for 802.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 to send more challenges and then concatenate the resulting keys into a session key of arbitrary length. Another concern is that the IMSI value is sent in plaintext. This enables an attacker to gather information by observing a large number of authentications. EAP-SIM suggests to solve this by, during the authentication, agreeing on a new subscriber identity to be used in the next authentication. This new identity is called a pseudonym. The third concern is that the network is never explicitly authenticated, making it possible for a rogue AP to replay old triplets it has obtained from eavesdropping on earlier authentications. This is resolved by letting the supplicant provide a Nonce value (an unpredictable and unique number, used only once) at the start of the authentication. The AP then has to incorporate this value into the session key later which ensures that the triplets provided are fresh. The actual EAP-SIM authentication procedure is shown in figure 2.4 and described here: 1. The supplicant starts by sending a EAP-Start packet (encapsulated within an 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 IMSI information, but all subsequent contacts pseudonyms will be used. The desired authentication method is also included. 4. Then the AP sends an EAP-Request/SIM/Start message telling the supplicant that it is ready to proceed with EAP-SIM authentication. 5. The supplicant responds by sending the nonce value to be incorporated into the 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 the session key, called PMK (Pairwise Master Key). This is done by putting them and the nonce through a Keyed Hash function.

9 STA AP GSM AC EAPOL-Start Request/Identity IMSI or pseudonym Request/SIM/Start Nonce Request triplets (x3) AP creates a session key out of the Kc values and constructs a new pseudonym GSM Triplet (x3) (RAND, SRES, Kc) Request/SIM/Challenge (3xRAND, MIC, Psdnym) Client calculates the session key from the RANDchallenge SRES 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 be used next time the client authenticates. This pseudonym is encrypted with the session key. 7. After completing all the above tasks the AP sends an EAP-Request/SIM/Challenge containing the three RAND values, a MIC (Message Integrity Check) to protect the RAND values from tampering and the encrypted new pseudonym. 8. Having received the RAND values the supplicant lets the SIM-card calculate both the Kc values and the SRES values. The Kc values are then used to derive the session key, called PMK (Pairwise Master Key), using its own copy of 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 another MIC as confirmation that it actually possesses the shared secret. 10. Provided that the SRES values match the ones stored at the AP the client is authenticated and the AP sends the EAP-Success message to tell the supplicant 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 standard. It was designed to provide a more secure alternative to WEP (Wired Equivalent Protection) and WPA (Wi-Fi Protected Access, see section 2.3) while still retaining backwards compatibility to WPA devices. It is sometimes referred to as WPA2 which is what Wi-Fi Alliance calls their approved interoperable implementation of 802.11i. The 802.11i architecture contains the following components: 802.1X for authentication (entailing EAP and an AS), RSN for keeping track of associations and CCMP to provide confidentiality. 2.2.1 The Four-Way Handshake The authentication process leaves two considerations: the AP still needs to authenticate itself to the client and keys to encrypt the traffic needs to be derived. The earlier EAP exchange has provided the shared secret key PMK (Pairwise Master Key). This key is however designed to last the entire session and should be exposed as 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 concatenating 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 decrypt multicast traffic. The actual messages exchanged during the handshake are depicted in figure 2.5 and explained here: 1. The AP sends a nonce-value to the STA (ANonce). The client now has all the attributes to construct the PTK. 2. The STA sends its own nonce-value (SNonce) to the AP together with a Message Integrity Check (MIC) to ensure that the packet has not been tampered 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 later on. 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 MIC for EAPOL-Key packets. EAPOL-Key Encryption Key (KEK) - The key used to provide confidentiality 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 network that only allows Robust Security Network Associations (RSNA). Two devices can establish a RSNA if they use the four-way handshake to authenticate the association. Robust security however, is not achieved unless all the devices within the network use RSNAs. An ESS advertises its RSN capabilities via the RSN-IE (RSN Information Element). Older network security solutions such as WPA and WEP are collected under what is called Transition Security Networks (TSN).

2.2. The 802.11i Standard STA AP ANonce STA constructs the PTK SNonce + MIC GTK + MIC AP constructs the PTK 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 replay protection. CCMP is based on the CCM mode in AES. CCM mode is a combination of Counter Mode (CTR), which provides confidentiality and Cipher Block Chaining mode with MAC (CBC-MAC) which ensures integrity. CCMP requires a fresh TK for each session and also a unique nonce for each frame 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 MIC so 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 describe secure 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 all parties. A STA in an RSN has up to four SAs: PMKSA - A result of a successful 802.1X exchange, pre-shared PMK information, 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. It is a bi-directional association, i.e. both parties use the association for both sending and receiving. The PMKSA consists of the following elements: PMKID, a tag identifying the association. Authenticator MAC address. The Pairwise Master Key.

2.2. The 802.11i Standard Lifetime of the association. Additional parameters specified by the AS and local configurations; these are 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-directional association. There can be only one PTKSA with the same supplicant and authenticator MAC addresses. The PTKSA is not created until the third message in the four-way handshake is validated. The PTKSA consists of the following elements: The Pairwise Temporal Key. The cipher suite agreed upon. Supplicant MAC address. Authenticator MAC address. Group Temporal Key Security Association The GTKSA is unidirectional and is used for multicast packets distributed by the APs. In an ESS, there is only one GTKSA. In an IBSS (Independent Basic Service Set, an ad-hoc network between wireless capable STAs) each STA defines their own GTKSA 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 following elements: A direction vector (whether the GTK is used to transmit or receive). The group cipher suite agreed upon. The Group Transient Key. Authenticator MAC address. Additional parameters specified by local configuration.

15 Station Key Security Association This association is used to communicate between two STAs in the same ESS. The STAKeySA is a unidirectional association from the initiator to the peer. There can only exist one STAKeyAS with the same initiator and peer MAC addresses. The STAKeyAS 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 2200 the 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 more secure WLAN solution until the 802.11i standard was finished. WPA is based on parts 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 for traffic encryption. TKIP is essentially WEP in a suit of armor that takes care of the current problems with WEP. It is however a compromise and there are known weaknesses, both in the underlying RC4 encryption algorithm [10] and in the temporal key 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 is most often referred to by that name) over the entire packet. This provides defense against packet manipulation attacks. 2. Due to design constraints of the MIC, it is still possible to compromise message integrity. Therefore TKIP also implements countermeasures (see figure 2.6). The countermeasures bound the probability of a successful forgery 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 Sequence Counter). If the receiver receives a packet out of order it will drop it. This provides replay protection. 4. TKIP also uses a cryptographic mixing function (an S-box) combining the temporal key (TK), the transmitter address (TA) and the TSC into the WEP seed. This is done in order to avoid the weak keys in WEP. The countermeasures are focused at detecting message integrity failures by looking at the MIC checksum. If the checksum does not add up a timer is started. If there is another MIC failure before the timer reaches 60 seconds all STAs using TKIP are deauthenticated and PTKs and the GTK are revoked. A new GTK is generated but not installed. The AP then waits for 60 seconds before installing the new 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 and fast 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 as well. The only difference is that the STA also deletes the old PTKSA it had with the previous AP. Cached keys - STAs and APs can cache keys from earlier associations. So when roaming 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 cached 802.1X authentication is skipped and the four-way handshake ensues. Pre-authentication - A STA can, once it is authorized, establish PMKSAs with any of the other APs in the ESS. This is accomplished by doing regular 3 802.1X authentication with the other APs and then caching the PMKSA. Re-association can then be handled as in the cached keys method. Whether or not an AP supports pre-authentication is advertised through the RSN-IE. 3 Actually it is not very regular at all: the authentication is run over the DS (Distribution System) instead of over the radio interface. This goes somewhat against the design intent of 802.1X where the supplicant is allowed no access whatsoever until after authentication.

17 Wait for Michael MIC Failure Timer < 60 sec Yes No Timer = 0 Log event Deauthenticate all if not an IBSS Revoke all PTK and GTK Generate new GTK Wait 60 sec Configure new GTK Enable associations if not an IBSS Figure 2.6: Authenticator Michael MIC countermeasures (taken from the WPA standard [3]).

2.4. The 802.11F Standard Ideally, roaming should be as fast as possible, and from that perspective preauthentication looks very promising. The problem with it, however, is that preauthentication is left entirely up to the client. Currently there is no reason to trust that the client will actually do this. Here the need for IAPP (Inter Access Point Protocol) arises. IAPP is defined in the 802.11F standard and specifies how APs communicate to facilitate fast and secure roaming. The 802.11F standard was developed to allow for interoperability between APs from different vendors. It specifies desired operation and suggests implementation models 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 service primitives on the other hand, are messages communicated between the three entities that reside inside each AP. These entities are the APME (Access Point Management Entity), 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 entity that handles the network communication and the IAPP entity contains is the actual IAPP functionality. Security is handled through the use of SAs coupled with ESP (Encapsulated Security Payload, see RFC 2406 [19]). These are protocols taken from the IPsec suite and have been well scrutinized by the security community since their introduction in 1998. The standard also suggests three levels of deployment with increasing functionality: 1. No AS present, each AP maintains a list of addresses for all other APs. This level does not offer any security or administrative support. 2. AS is present, so address lookup is possible. All APs need to register with the 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 to reach every AP in the ESS. The point of this packet is to get the receiving APs to de-associate any STAs matching the one described in the packet, as a STA is not allowed to maintain several associations. This packet needs to be protected 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 an ESS. Unlike the ADD-notify though, this packet is sent only to the AP it was previously associated to with a MOVE-notify packet (from here on referred to as the old AP). This causes the old AP to de-associate the STA and to send relevant context data about the STA to the new AP. This packet needs to be protected for the same reasons as ADD-notify. MOVE-response - This packet is sent in response to a MOVE-notify packet. It contains context information about the re-associated STA such as PMK and must be protected for obvious reasons. Send-Security-Block - This packet is sent by the new AP to the old one in roaming situations in order to provide the old AP with means to set up an SA with the new AP and to encrypt and decrypt ESP packets. The packet is encrypted 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 replay protection and a New-AP-ACK-Authenticator block. This block is copied from the Send-Security-Block packet and is encrypted with the new AP s BSSID secret in order to show that the old AP has installed the encryption keys. CACHE-notify - This packet is sent to all neighboring APs so that handover latency is low in the event of roaming. This packet contains essentially the same information as a MOVE-response packet and is protected in the same manner. CACHE-response - This packet is sent in response to the CACHE-notify packet. It only contains status indication about whether the information was already present in the cache or not. This is the only packet that is not protected, because there is very little to be gained by manipulating this packet.

2.4. The 802.11F Standard 2.4.3 Service Primitives The service primitives are invoked in response to certain events, such as the AP being turned on or a STA wishing to associate with the AP. There are five basic classes of primitives: INITIATE, TERMINATE, ADD, MOVE and CACHE-NOTIFY. INITIATE and TERMINATE These two first classes are straightforward and work as would be expected. They initialize and terminate the APME when the AP is turned on or shut off. If there is an AS present they also register and unregister the AP with the AS. INITIATE.request - APME MLME - Initializes the APME and provides startup parameters. INITIATE.confirm - MLME APME - Result indication of the INITIATE.request. TERMINATE.request - APME MLME - Shuts the IAPP entity down. TERMINATE.confirm - MLME APME - Result indication of the TERMINATE.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 on the DS (Distribution System). The ADD.indication primitive is then generated in the receiving APs. The ADD.indication contains a MAC address and a sequence number. The sequence number is provided to aid each APME in determining where the STA is currently associated. ADD.request - APME IAPP - Invoked when when the MLME detects that a STA wants to perform a full association procedure with this AP. ADD.confirm - IAPP APME - Result indication of the actions following an ADD.request. ADD.indication - MLME APME - Invoked when the MLME detects an ADD-notify packet on the DS.

21 MOVE Whenever a roaming situation occurs the MLME of the AP the STA roamed to sends a RE-ASSOCIATE.indication to the APME in that AP. This invokes the MOVE.request primitive that then tries to contact the old AP. This is done in order to get the old AP to send relevant information about the STA over to the new AP (for instance, the PMK). MOVE.request - APME IAPP - Invoked when the MLME detects that a STA has roamed over to this AP. MOVE.confirm - IAPP APME - Result indication of the actions following a MOVE.request. MOVE.indication - MLME APME - Invoked when the MLME detects a MOVE-notify packet on the DS, indicating that a STA has roamed from this AP 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 that roamed 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 look in the cache to see if there if the STA s context is already stored. If that is the case no MOVE.request is issued until an 802.11 Reassociation Response frame is sent (from the old AP the STA was associated with prior to this one). The MAC address of the old AP is also added to the neighbor graph. CACHE-NOTIFY Whenever a STA associates with an AP the CACHE-NOTIFY.request primitive is invoked. This sends a CACHE-notify packet to each of the neighboring APs telling them to cache the included context. The neighboring APs all answer with a CACHE-response indicating whether the information was already present in the cache or not. The purpose of this class of primitives is explained more thoroughly in the following section. CACHE-NOTIFY.request - APME IAPP - Invoked when the MLME detects that a STA associates or re-associates with this AP. IAPP then tells the MLME to send CACHE-notify packets to all neighboring APs.

2.4. The 802.11F Standard CACHE-NOTIFY.confirm - IAPP APME - Invoked when the MLME has received CACHE-response packets from all the neighboring APs or a timeout has occurred. CACHE-NOTIFY.indication - IAPP APME - Invoked when the MLME receives a CACHE-notify packet. CACHE-NOTIFY.response - APME IAPP - Invoked by the APME when the IAPP entity has finished the actions triggered by the CACHE-NOTIFY.indication. This causes IAPP to tell the MLME to send a CACHE-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 storing the context information for each STA in the neighboring APs. Each AP maintains a neighbor graph that is a set of neighbors relative to a given AP. This graph is best populated through dynamic learning by listening for 802.11 Reassociation Request frames that the STA sends when re-associating with a new AP. The AP can filter out 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 Least Recently Used (LRU) cache. This will over time weed out neighbors that are misidentified 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 own shared secret with the AS, called RADIUS secret 4 and at startup they need to register themselves with the AS. The APs can then later use the AS to establish Security Associations (SAs) with each other. As all SAs are verified through the AS they provide origin authenticity. ESP (Encapsulated Security Payload) is then used to provide confidentiality through encryption, integrity through MICs and replay protection through the use of replay counters. The algorithms used for encryption and MIC generation are unspecified, so any proven algorithm can be used. 4 Actually there is a bit of confusion surrounding this. The 802.11F standard use RADIUS BSSID secret and BSSID secret interchangeably. But there is actually another attribute that is also called BSSID secret that is used to encrypt packets that need to be sent securely between APs. So in this report BSSID secret will signify the encryption secret and RADIUS secret will signify the secret shared with the RADIUS server.

23 As the RADIUS protocol is the de facto standard there are six packets defined to support RADIUS usage: Registration Access-Request, Registration Access-Accept, Registration Access-Reject, Access-Request, Access-Accept and Access-Reject. The first three are only used when IAPP is initiated, the last three each time a SA between two APs needs to be established or renewed. In the interest of conciseness only the last three will be presented in detail. The differences are small and will be pointed out in the text. Details about the other three can be found in the 802.11F standard [14]. The messages here map directly to the messages discussed in section 2.1.2: Access-Request - This message is sent to RADIUS when the IAPP entity receives 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 new AP s ESS. 2. To establish a secure channel to the old AP to allow for context transfer. An important note to make is that this only verifies that the old AP is legitimate, not the STA. The packet contains the following attributes: User-Name - This is the BSSID represented as a text string containing the MAC address of the AP. User-Password - As the AP is already authenticated by the pre-shared secret and RADIUS has already logged the BSSID secret there is no need for this attribute in this packet. It is therefore set to NULL. In the registration request messages this attribute contains the shared RADIUS secret. NAS-IP-Address - The IP address of this AP. Both this and the NAS-Identifier attribute are optional but at least one of them must be present 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 is not replayed. This attribute is Vendor Specific meaning that only IAPP uses it. In the registration request there are three Vendor Specific Attributes (VSAs): SSID and cipher suite selectors for both the encryption and the MIC. Called-Station-Id - A text string containing the new AP s MAC address concatenated with the SSID and separated by a :.

2.4. The 802.11F Standard 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 a registration request. Message-Authenticator - The MIC of the packet. Access-Accept - At reception of this packet the new AP has all the tools it needs to communicate securely with the old AP. IAPP defines different SAs in each direction so the packet also contains all the information the old AP needs to establish an SA to the new one. The full contents of the packet is the 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 an IAPP-Register message. New-BSSID-Security-Block - SA information for the link going from the new 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 the old 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. A registration accept has a few more VSAs detailing the encryption keys and the SPI. Message-Authenticator - The MIC of the packet. The registration accept also 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 valid member 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 handled efficiently with small latencies. STA context information is, for the same reason, also cached through the proactive caching mechanism. Both the SAs and the cached contexts have timeouts associated with them and have to be periodically refreshed. The actual chain of events triggered in a roaming situation is depicted in figure 2.7. 1. The client gets too far away from its currently associated AP and decides to re-associate with another. It then sends a 802.11 Reassociation Request frame to the new AP.

25 Authentication Server 2. Access- Request 3. Access- Accept 4. Send-Security-Block 5. ACK-Security-Block New AP 6. MOVE-notify 7. MOVE-response Old AP 1. Reassociation request 8. CACHE-notify multicast to all neighbors 9. All neighbors answer with CACHE-response Roaming Station Figure 2.7: A roaming example.

2.4. The 802.11F Standard 2. The new AP does not have the context information of this client cached and therefore sends an Access-Request message to the RADIUS server. The message tells RADIUS that the new AP wants to know if the old AP is legitimate and if so communicate with it. 3. RADIUS checks if the old AP has a legitimate registration and sends an Access-Accept back if that is indeed the case. The Access-Accept contains all that the new AP needs to communicate with the old AP. The message also contains all that the old AP needs in order to communicate with the new 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 needs encapsulated 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 connection saying that the client that was previously associated with you has now moved over to me; please hand over relevant information about this client. 7. The old AP then sends a MOVE-response message back containing all relevant information (for instance the PMK). 8. The new AP then sends a CACHE-notify message to all its neighbors telling them that this client just moved over to me, here is the relevant information about it in the event that it would roam over to any of you. This actually requires 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 an ACK 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 of the different links and the protocols responsible for them. At the end there is also a 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 is the generally accepted model for assessing risks in a system. The model has three components: Confidentiality - Information should only be available to those with the proper authorization. Integrity - Information should not be altered in any way except by those authorized to do so. Availability - Information should be accessible to authorized users any time that it is needed. The most common way to ensure confidentiality is to encrypt the data but other methods like physically protecting the link over which the information is sent are equally valid. In a wireless network, however, anyone with an antenna can listen in on the traffic, so the only feasible way of ensuring confidentiality is through encryption. Integrity on the other hand, is very hard to ensure (solutions would need to involve 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 have a good redundancy and robust systems. Load-balancing servers, for instance, can be 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 can be 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 believing that he is the entity that the client wants to connect to, in this case an access point. The attacker then takes the authentication information it receives from the client 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. This attack has been a problem especially in tunneled EAP methods such as EAP-TTLS and EAP-PEAP [4]. For a more detailed attack scenario using MITM see section 3.2.2. In order for this attack to be successful the authentication process needs to be one-sided, i.e. only the client is authenticated and not the AP. In order for eavesdropping to work though, the authentication needs to be simple enough that the attacker can decode and install the session key. Mutual and robust authentication prevents this attack. 3.2.2 Session Hijack This type of attack is used by the attacker to gain control of a legitimate user s session and use it as his own. It is often used in conjunction with MITM and an attack scenario using a challenge-response protocol can look as follows: An attacker connects to an AP and receives a challenge. The attacker then poses as an AP to get a client to connect to it. When a client connects to the attacker it gets the same challenge as the attacker did. The client encrypts it and then sends it back to the attacker. The attacker then forwards the response to the genuine AP and is allowed to log on. As a final act the attacker sends a logoff-message to the client which has no reason to suspect foul play (and even if it did, there is little, save switching to a better 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 some manner. This is especially easy in wireless systems as all traffic is effectively broadcasted. An attack scenario is as follows: Alice writes a check for $50 to Eve and sends 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 authentication exchange, and then replaying them at a later time in order to gain access illegitimately. This attack type is handled through the use of replay counters, which is a monotonically increasing counter inserted into each packet. This counter is then included into the MIC. So in order to replay a packet the attacker would not only have 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 something. It can also assume a different identity by switching to a different MAC address. If an AP only uses MAC association as authentication method this is a very trivial way to gain access to the network. MAC association means that the AP has a list over the MAC addresses that are allowed; packets sent from others are just thrown away. This technique is often used to facilitate other attacks, for instance MITM, where the attacker uses spoofing to impersonate an AP to lure clients to connect to it. The spoofing itself is hard to stop as there exists no network-level method of ascertaining that an entity actually is who he says he is. But spoofing on its own is rarely a major problem: it has to be combined with some other kind of attack in order to be really damaging. 3.2.6 Denial of Service Denial of Service (DoS) is exactly what it sounds like: it is about denying someone access to a service. It can be as easy as setting up a jamming beacon to disrupt the AP s signals to deny them access to the network. There are basically two kinds of