Fast and Secure Roaming in WLAN
Performed for Ericsson ABby
Magnus Falk
LITH-IDA-EX--04/116--SE 2004-12-22
Final thesis
Fast and Secure Roaming in WLAN
by Magnus FalkLiTH-IDA-EX--04/116--SE
Supervisors: Bo Kvarnstr¨om
CPE Products & Solutions at Ericsson AB
David Byers
Division for Database and Information Techniques
at Link¨oping university
Examiner: Nahid Shahmehri
Department of Computer and Information Science
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 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 authenti-cation 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,
Acknowledgments
First I would like to thank my supervisors at Ericsson: Bo Kvarnstr¨om and Rasmus Ax´en. 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¨oberg at Ericsson in G¨oteborg 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.
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 . . . 42.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
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
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. Such zones 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 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.
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 includeHotspot
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
Client Station Supplicant
Access Point
Authenticator 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 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 port1 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 1This is not a port in the TCP sense; it is only used as an abstraction of the 802.1X interface.
Authorize Supplicant Authenticator Authentication Server Distribution System
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 inRFC 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.
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 estab-lished 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. Ad-ditionally, 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 encrypting2 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.1. Authentication
Authentication in WLAN In order to achieve satisfactory security levels for 802.11i andWPA, 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 de-scribed 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.
STA AP GSM AC EAPOL-Start Request/SIM/Start IMSI or pseudonym Request/Identity Nonce Request triplets (x3) GSM Triplet (x3) (RAND, SRES, Kc) Request/SIM/Challenge (3xRAND, MIC, Psdnym)
SRES
AP creates a session key out of the Kc values and constructs a new pseudonym
Client calculates the session key from the RAND-challenge
EAP-Success
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 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 still retaining backwards compatibility to WPA devices. It is sometimes referred to as WPA2 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 and
CCMP 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. 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 theFour-Way Handshake is used to establish another
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 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 net-work that only allows Robust Security Netnet-work Associations (RSNA). Two devices can 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 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
SNonce + MIC
ANonce
STA constructs
the PTK
AP constructs
the PTK
GTK + MIC
Ack
2.2.3
CCMP
CCMP is the encryption protocol in 802.11i. CCMPstands 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 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, seeRFC 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.
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 authen-ticator 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.
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 WEPin a suit of armor that takes care of the current 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 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 look-ing 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 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. Whether or 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 (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.
Wait for Michael MIC Failure Timer = 0 Log event Timer < 60 sec Yes No
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 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 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 theAPME(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, seeRFC 2406[19]). These are protocols taken from theIPsecsuite and have been well scrutinized by the security community since their introduction in 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. 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
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.
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 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 own shared secret with the AS, called RADIUS secret4 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.
4Actually 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.
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.
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
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.
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 be-lieving 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 asEAP-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 eaves-dropping 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).
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 broad-casted. 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 authen-tication 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 some-thing. 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
3.3. The Different Links Involved
DoS attacks: the ones that exploit flaws in the protocols and the ones that use brute force to overwhelm the resource. There is no universal panacea for this category of attacks; tools designed to cope with them most often analyze traffic and act on anomalous events. But it is hard as some attacks are very subtle and problematic to detect. Having a robust system that is deployed correctly using proven security protocols 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. The attacker makes the system believe that it has to use the authentication alternative with the lowest level of security. This leaves the system more vulnerable to other means of attack.
3.3
The Different Links Involved
This section examines the different links in the system. It will look at the protocols that 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 a very tricky link to protect since without exchanging encryption keys there can be no protection.
The protocol used on this link is EAPOL(EAP Over LAN), which has no built in security measures except for the EAPOL-Key frame type. EAPOL-Key frames are used to transport keying information to the client after authentication, and use RC4 for encryption. They are used (with slight modifications, see the 802.11i standard [15] for details) to protect the traffic during the four-way handshake in 802.11i. Earlier, in connection with WEP (section 2.3), it was mentioned that RC4 has 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 that the risk of exposure is negligible.
The attacks possible on this link are mainly DoS attacks. One potential attack is for an attacker to spoof the MAC address of any client trying to log on to the AP and send a EAPOL-Logoff message. The AP will then immediately shut down the connection, shutting the client out. If this is done continually the attacker will have the AP entirely to himself.
3.3.2
ClientÀAuthentication Server
This link is the second one (from the client’s perspective) to be established and it only exists during authentication. The protocol used for this link is EAP but the actual traffic is encapsulated within other protocols during transport. From the client to the AP traffic is encapsulated in EAPOL packets and from the AP to the AS inside RADIUS packets.
There are no native security mechanisms in the EAP protocol; they are left entirely 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 the authentication 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 recommended criteria.
3.3.3
Access PointÀAccess Point
Given a level 3 deployment, this link is taken care of by IPsec using ESPwhich pro-vides authentication of the APs, traffic confidentiality, traffic integrity, traffic origin authenticity, and replay protection. The encryption and integrity check algorithms in ESP are unspecified so any proven algorithms can be used.
A level 2 deployment provides authentication of the APs but nothing more. A level 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 DS and then change the destination for a packet so that the AP routes it to the silent entity on the DS. As the CCMP/TKIP/WEP encryption is only applied to packets sent 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 replay protection and the integrity protection would have to be flawed as they would both individually thwart this attack.
3.3.4
Access PointÀAuthentication Server
As RADIUS is the de facto standard for authentication servers the protocol for this link is RADIUS. The protocol specifies that each Access-Request packet should contain 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. To ensure confidentiality a Keyed Hash (MD5) is used as a stream cipher to encrypt the 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 RFC also 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 (section 7.2.2 in RFC 2869), MITM attacks (section 7.2.3 in RFC 2869) and authentication method 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 the use of a robust EAP method such as EAP-SIM (see section 3.3.1 for EAP method requirements).
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 Mishra and William A. Arbaugh [22]. The first comment is about the asymmetric nature of 802.1X where the client but not the authenticator is authenticated. The authors make the argument that this allows for a MITM attack. The 802.1X protocol is however not designed to be used on its own, but rather in conjunction with the EAP protocol. Most EAP methods today are safe from MITM attacks, including the EAP-SIM method.
They also comment on the lack of security for the low level signaling between the AP and client. This enables an attacker to spoof a disassociate message to the
AP causing the client to lose its connection to the AP. They also claim that this makes the session vulnerable to hijacking, but this is only true if the attacker also recovers the session key for the encryption. Without the session key, hijacking is not possible.
Thirdly a number of DoS attacks are outlined. These will be covered in section
3.4.2.
3.4.2
802.11i
802.11i addresses most security issues in 802.11; most significantly it offers strong confidentiality and robust authentication. There are, however, still a few threats to the availability of the system.
ChangHua He and John C. Mitchell point out a possible DoS attack on the four-way handshake in 802.11i [12]. The attack takes advantage of the fact that the first message in the four-way handshake has no MIC and no confidentiality and is therefore easily forged. The attacker spoofs the MAC address of the AP and starts sending forged first messages to the client. The reason this message lacks a MIC is that since the PMK can be a static pre-shared key the system then would be sensitive to replay attacks.
The impact of this attack depends on how the client implements the four-way handshake, i.e. if several sessions can exist simultaneously or not. Since Ericsson is developing an AP and this attack is entirely client dependent, it will not be examined 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 of 802.11 management frames, especially the disassociate frame. This throws the client out of the network and forces it to re-associate. Yet another attack involves EAP-Failure message spoofing. This causes an already authenticated supplicant to be de-authenticated and put into a HELD state. It will then be kept in this state for 60 seconds before being allowed to re-authenticate [22].
Lastly, there is an attack that starts as many parallel authentications as possible using random MAC addresses to fill up the number of allowed associations or the memory 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 practice of sharing the PMK with all the APs the client roams to. This criticism has been brought 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.11i makes the following security claims: Data origin authenticity, data integrity, replay immunity and data confidentiality. They state that the last requirement is not feasible without the prior three being true. They also state that the first three assume 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 respect to 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 new four-way handshake each time the client roams. An attack would then have to first crack 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 ideal practice it does not pose any long term threat to the system. Aruba Wireless NetworksTM has presented a solution [23] which claims to incorporate a centralized key 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 solution is not suitable for the ABS 2200 as it is not designed to have a local server. The ABS is a rather “fat” AP with a lot of functionality and is designed to be part of a peer-to-peer environment. In order for it to work the AP responsible for the WAN interface would have to be redesigned to also work as a site switch. That would be too expensive to be an option.
3.4.4
RADIUS
The current RADIUS implementation has a number of weaknesses as pointed out by Joshua Hill in his analysis of the RADIUS protocol [13]. His findings are summarized below:
Flawed password protection - RADIUS uses a Keyed Hash (MD5) as a stream cipher primitive, something which it is not designed for. Hill enumerates four different attacks based on this vulnerability.
Flawed MIC generation - RADIUS uses MD5 to generate a MIC for all response messages. As MD5 has documented weaknesses [33] this is not a good idea.
Many clients create insufficiently unpredictable nonces - Much of the security of RADIUS depends on the generation of the nonce called Request Authenticator. The RFC does not emphasize the importance of this enough and the result is a plethora of poor implementations.
Bad shared secret hygiene - The RADIUS standard specifically permits use of the same shared secret by many clients (from this perspective the APs are
the clients). This is a bad idea as a single flawed client will allow for several other to be compromised. This is possible as RADIUS provides no
protection for client or server address. Many implementations also artificially limit the shared secret entropy by only allowing ASCII input (where little more than a third of the 256 possibilities are readily available on a standard keyboard) and limiting the length to 16 characters. This greatly reduces the key 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 Ericsson will only have limited influence over them. There are a few recommendations that can be made to the customers. First of all the RADIUS extensions detailed in RFC 2869 should be implemented (see section 3.3.4 for details). There are also a few guidelines when it comes to deployment of a RADIUS server outlined by Joseph Davies [7] that can be applied without interfering with the normal function of the server.
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 is tempting to use a single password for all APs in order to simplify management. An effort should be made to make it easy for customers to have different passwords for each AP. All these changes can be implemented while remaining fully compliant with the RADIUS protocol.
As mentioned in section 3.3.4, RFC 2869 also points out that the RADIUS protocol is vulnerable to connection hijacking, in this case meaning that an attacker could inject packets into a conversation between the AP and RADIUS. This is possible as not all packets are integrity protected. Since RADIUS does not provide end-to-end security, MITM attacks are possible where an attacker could alter EAP packets in transit. Authentication method downgrading is also a threat if the AS accepts low-security methods such as EAP-MD5. Customers should be made aware of this.
3.4.5
EAP-SIM
Sarvar Patel has in an analysis [24] pointed out two weaknesses in the EAP-SIM protocol:
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 longer entirely correct. The first item refers to the authenticator sending three identical RAND challenges effectively making the key only 64 bits strong. This has been disallowed in the later versions of the EAP-SIM draft. The AS is now obliged to provide distinctly different RAND values and the client is also obliged to check them so 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 be able to decrypt any traffic beyond the ongoing session. This has been achieved by incorporating the client’s nonce value into the session key. Hence, even if the RAND challenges were to be reused at a later authentication the resulting session key would still be different.
Something that could be a problem however, is if the same SIM chip is used for GSM or GPRS traffic. An attacker could then eavesdrop on the traffic and that way obtain RAND and SRES values. He can then use brute force to obtain the corresponding Kc key value for each of those RAND values. This attack is rather serious and steps should be taken to inform customers that they should not use their SIM chips in this manner.
An active attacker could even mount a rogue GSM/GPRS base station attack and start sending previously seen RAND challenges to obtain the SRES values and then brute force the Kc keys for them. This is possible since EAP-SIM does not provide PFS (Perfect Forward Security). PFS is when an old session is secure even if the master key is later discovered.
As this attack requires the attacker to actually build a rogue GSM base station the cost of this attack is rather significant. It can be very efficient though, due to several weaknesses in the GSM encryption algorithms. The effective key strength of the Kc keys is much less than the expected 64 bits (no more than 40 bits if the A5/1 GSM algorithm is used [31]; an active attacker can also use authentication downgrading to get the client to use the weaker A5/2 algorithm which can be broken in less than a second [5]).
EAP-SIM also requires that fresh keying material is used each session, i.e. the probability 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 the freshness of the RAND values though. The functionality for this would have to be implemented into the client.
3.5
Threat Assessment
The threat type that houses the largest quantity attacks is Denial of Service. This does 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 TV station Al-Jazeera launched their new English-language website [20]. From the moment it went online it was beset by a constant flood of traffic in what is called a DDoS attack (Distributed Denial of Service), making it impossible to reach. The attack persisted over a period of several days until the DNS was redirected to a fake, pro-American site. As the redirection also is a form of DoS, the attack is one of 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 well again.
There are however a few non-technical consequences that need to be taken into account, 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. As DoS attacks are very hard to defend against there needs to be a significant threat if countermeasures are to make economical sense. There are tools such as Red-Detect from Red-M [25] that claim to detect and thwart many DoS attacks. These are however large standalone systems that probably would demand many months to develop. This should still be an area of interest for Ericsson to look into as public hotspots are prime targets for these kind of attacks.
DoS attacks aside, the APÀAS link seems to be the weakest. When RADIUS is used without EAP, as it is when the APs register via IAPP and request SAs with 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 and authentication method downgrading. This means that an attacker could, using no more equipment than a computer with Internet access and an AP, make a MITM attack on the APÀAS link. Once established as a man in the middle the attacker can 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 rogue AP 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 security EAP-methods such as EAP-MD5. Customers should be informed that this is not a good policy.
