ESCORT: a decentralized and localized access control system for mobile wireless access to secured domains

ESCORT: A Decentralized and Localized Access Control System for Mobile Wireless Access to Secured Domains Jiejun Kong, Shirshanka Das, Edward Tsai, Mario Gerla Computer Science Department University of California, Los Angeles, CA 90095 {jkong,shanky,edwardt,gerla}@cs.ucla.edu ABSTRACT

Keywords

In this work we design and implement ESCORT, a backward compatible, efficient, and secure access control system, to facilitate mobile wireless access to secured wireless LANs. In mobile environments, a mobile guest may frequently roam into foreign domains while demanding critical network services. ESCORT provides instant yet secure access to the mobile guest based on the concept of “escort”, which refers to a special network object with four distinct properties: (1) The escort is already a trusted permanent or semi-permanent component of the secured wireless LAN; (2) The mobile guest and the escort have established transient but mutual trust; (3) Communication between the escort and its guests is localized. The escort forwards data packets between the mobile guest and the LAN; (4) The implementation of escort can be mobile and tamper-resistant, thus it can roam with the mobile guest without being compromised. Existing network concepts (e.g., router, gateway) and security concepts (e.g., existing access control models and authorities) do not possess at least one of the four essential properties. As a permanent component of wireless LAN, the communication channel between the escort and the LAN can be secured by effective countermeasures like 802.11i TKIP and AES-CCMP. Therefore, ESCORT addresses the challenge of providing efficient mobile privacy support between the escort and its mobile guests. Three aspects of mobile privacy, namely content privacy, identity privacy, and location privacy are covered in ESCORT design to maximize the protection offered to ESCORT’s mobile guests. We use actual implementation to demonstrate that ESCORT design is feasible and efficient.

Wireless security, Decentralized access control, Mobile privacy, Location privacy, Identity privacy

Categories and Subject Descriptors C.2.0 [Computer-Commmunication Networks]: General—Security and protection

General Terms Security, Design, Management, Measurement, Experimentation

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WiSE’03, September 19, 2003, San Diego, California, USA. Copyright 2003 ACM 1-58113-769-9/03/0009 ...$5.00.

1.

INTRODUCTION

Nowadays wireless technology has enabled a new networking paradigm that is significantly different from the legacy wired ones: a mobile guest can frequently roam into foreign domains while enjoying critical network services; a wired connection in harsh environment can be replaced by an indestructible wireless one; and so on. However, this also implies that the legacy security countermeasures proposed for the wired networks may not be able to provide qualitative protections due to modified design goals. In particular, mobile wireless communication is susceptible to many new threats. For example, in a wired network, adversarial parties normally should gain physical access to wired links in order to launch attacks. However, in a wireless network, any adversary within transmission range poses serious threats including eavesdropping and message injection. In a fixed wired network, centralized security solutions are effective means to stop authentication, authorization, and access control attacks. However, in a mobile wireless network, centralized solutions are limited by their legacy design— they are not efficient in a distributed scalable network consisting of many autonomous domains where there are potentially many temporary mobile guests roaming in and out. In this work we propose an escort-based access control system for mobile wireless networking scenarios that typically look like these ones: 1. Case I: Professor Smith invites Professor Taylor (of University T) to give a talk to his students at University S. During the two-hour talk, Professor Taylor needs to access the Internet, especially his home email server at University T, from his mobile laptop. Public DHCP access at University S is open to any local computers. Unfortunately, the open but under-protected DHCP system was recently hacked and thus closed, and system administrators have left for lunch because the talk time is around noon. Fortunately, permanent users (including Professor Smith) possess permanent IP addresses and other network resources. Their mobile access is not affected by the DHCP shutdown and the absence of administrators. 2. Case II: Enterprise X has installed wireless LAN in all local offices. Kerberos-based access is granted to all permanent employees. User accounts and access control lists are typically renewed quarterly. However, granting access to temporary interns and visitors causes big trouble to X’s network

team. Everyday the team members are busy at adding new accounts and deleting ghost accounts for short-term interns and visitors to use but not abuse the enterprise’s private network. Due to inconsistency among different administration team members’ management, many loopholes existing in the authentication, authorization, and access control (AAA) subsystem pose non-trivial threats to the enterprise’s data resources. 3. Case III: The New York office of enterprise X has a parking lot, which is separated from the main building by the Fifth Avenue. The office director wants to extend wireless LAN to the janitor room in the parking lot, so that parking tickets can be electronically regulated. Unfortunately, due to the city’s civil codes, the expense of installing a wire across the Fifth Avenue is expected to be as much as one million dollar. The network team is trying to establish a secured local channel between the main building and the parking lot, and a secured wireless channel is the top candidate. Two common traits, namely network inconsistencies and centralized control in the system, are shared by these scenarios. In Case I, if the inconsistency between Professor Taylor’s laptop and the local domain has to be solved by centralized control, then the system will be haunted by the risk of a single point of failure and extra access control management overhead. In Case II, not only the problems described in Case I, but also tighter rules and security demands, raise the bar of security enforcement. Transient but secured mobile access is a non-trivial challenge to centralized access control models. In Case III, people normally assume access points can always be wired into the infrastructure. Real world scenarios do not necessarily endorse the assumption. When physical obstacles (e.g., river, street) invalidate the assumption and cause wired network partition, an obvious solution is to build a centralized control at each partition, then connect the multiple partitions via virtual private network (VPN, e.g., network layer IPsec VPN). Unfortunately, in many cases this is an overkill; in Case III, the centralized solution is impractical due to its unreasonable deployment expense. In addition to centralized control, we observe that close and decentralized trust between a guest (or a partitioned node) and the local domain is feasible in the real world. Such decentralized trust model can be used to facilitate transient mobile access by decreasing access control overheads and avoiding single point of failure in centralized solutions. In many cases, people do know each other by various means. The acquaintance can be built from direct physical contact, or from the check-in validation procedure at office’s frontdesks, or from an electronic token/ticket issued by an online E-commerce transaction paid by credit card. In general, the transient acquaintance can be pre-established before the mobile guest roams into the local domain. We name the acquainted host as “escort”, which is already inside the domain and is responsible to host the guest. Such an escort can be easily allocated to the mobile guests in the above-mentioned scenarios: I. Professor Smith’s network devices can play the role of escort for Professor Taylor’s laptop; II. The network team of enterprise X can incorporate all AAA requirements into a network object, which in turn can be physically granted to or collected back from temporary interns and visitors. Compared to centralized and “invisible” accounts, the objectified local control scheme is easier for managers to regulate and grants no access for remote hackers—they must come within close range of the local domain and thus leave themselves vulnerable to local intrusion detection systems; III. An 802.11 access point in the janitor room can be upgraded to be a wireless escort box, so that other

wireless devices in the parking lot can connect to the office’s wireless LAN via the escort. In all scenarios, the escort box is at most one wireless hop away from either the wired LAN or the guests. It provides network functions in close contact with both the infrastructure and the guests. Many existing and work-in-progress security schemes (e.g., TKIP, AES-CCMP at link layer [8], IPsec at network layer [9]) are expected to provide qualitative protection to wireless LAN and its permanent network members. Therefore, ESCORT does not try to address security problems among members of the wireless LAN. This includes communication between the escort box and the wireless LAN, as well as communication between any two permanent members of the local network. Instead, ESCORT focuses on providing qualitative protection, in particular message integrity and mobile privacy support, to mobile guests. Privacy in mobile networks has different semantics from the traditional notion for business banking systems and the Internet. Cooper and Birman [4] identify three kinds of privacy for mobile computing: content, participant identity, and participant location. In this work, content privacy means application payload is protected, typically by encryption, from being revealed to third parties other than the intended receivers; identity privacy means the mobile guest maintains its identity anonymity to observers other than the escort; location privacy means observers (except the escort) cannot correlate mobile guest’s identity with its current location (i.e., the local domain). The contribution of ESCORT is to actualize a general, efficient, and secure access control system that can be easily implemented in any existing IP networks to facilitate real-time mobile wireless access: 1. Back-compatibility and generality: ESCORT can be easily deployed and used in any existing autonomous IP subnets with minimal cost. It can be realized on low-cost mobile wireless devices. It also does not require extra mobility and security supports from extra network components like mobile IP, Kerberos, PKI, etc. Moreover, there is no conflict between the extra add-ons and ESCORT, thus with or without them an escort-based access control system will be functional. 2. Efficiency: ESCORT ensures that the communication between the mobile guest and the infrastructure is efficient. In addition, the implementation cost of ESCORT is low because it leverages many existing network functions, such as network address translation, network tunneling, and standard cryptographic algorithms. 3. Security: ESCORT seeks to provide supports for message integrity and all three aspects of mobile privacy, namely content privacy, identity privacy, and location privacy. The rest of the paper is organized as follows. Section 2 describes the underlying assumptions and models. The design framework and related discussions are illustrated in details in Section 3 and Section 4. Our implementation and performance evaluation are shown in Section 5. In Section 6 we compare our scheme with related work. Finally Section 7 concludes this paper.

2. 2.1

SYSTEM MODELS Network assumptions

Throughout the paper IP networking is assumed, and all wireless LANs have been secured by state-of-art wireless LAN security

solutions. It is well-known that 802.11WEP [7] is vulnerable to a myriad of attacks including the following two major categories: (1) Various message privacy and message integrity attacks described by Borisov et al. [3]. These attacks are based on various mechanisms like short IV, linear CRC-32 checksum, and keystream recovery by known-plaintext attacks. (2) Probabilistic cipher key recovery attack in the form of Fluhrer-Mantin-Shamir attack [20]. This attack is based on the fact that the initial output in the RC4 keystream is disproportionally affected by a small number of key bits, especially the prefix and postfix parts of the key [5]. However, the proposed 802.11i/TKIP [8] has mended all obvious loopholes in WEP. And future countermeasures like AES-CCMP are being developed to improve the strength of wireless LAN security. We believe such countermeasures can realize a secured local domain. Thus we assume the paradigm depicted in Figure 1 before ESCORT is deployed.

2.3

IPsec gateway

IPsec



Guest

? WEP

LAN

TKIP


  

AES−CCMP

Internet Secured Wireless LAN

Figure 1: Network assumption

2.2

System bootstrapping

ESCORT assumes a pre-scheduled registration phase between

the mobile guest and the wireless LAN. Such registration has to be realized by a secure authentication procedure, e.g., physical contact, PGP-like recommendation [22] (aka. web-of-trust), HTTPSbased electronic transaction paid by credit card, etc. The following three steps are essential in any registration method: (1) The mobile guest selects its security parameters including keys and initialization vectors; (2) The mobile guest notifies its escort box about the selections, along with its network parameters including IP address and MAC address, via a secret registration channel (e.g., HTTPS connection, or even direct delivery in case of physical contact); (3) The escort gives the guest its IP address/alias and token-acceptance port, its ESSID, and a confirmation number, which is a unique 128bit random number, then stores the guest’s parameters under the unique number. The unique number is a secret token that is valid within a (transient) period. The token is given to the guest via the secret registration channel and must be kept secret until the guest presents it to its escort box’s token-acceptance port. On the escort box, the following network security state is maintained for each of its mobile guest under the unique token number. MAC addr IP addr Security parameters Current state Start time End time

Guest authentication, authorization, and if necessary, financial accounting, are accomplished during the pre-scheduled registration phase. For example, the local domain may maintain an online registration E-commerce server to accept guests and assign escorts for them. ESCORT separates mobile access service provisioning from these well-studied security modules that have lots of off-the-shelf solutions. After the registration phase, the easy-to-carry 128-bit confirmation token is the only secret required by the escort box to provide service to the mobile guest. The escort box resides in a secured wireless LAN. However, network resources possessed by the wireless LAN, for example extra IP addresses and various centralized servers, may not be available at the time when the mobile guest roams in. ESCORT provides mobile access to the guest as long as (1) the guest holds the secret confirmation token; (2) the guest is the first one who presents the confirmation token to the escort box; and (3) the communication channel between the escort box and the wireless LAN is functional.

Guest’s MAC address for one-hop contact Guest’s IP address for data forwarding Guest’s keys, IVs, and other records for mobile privacy protection TOKEN ISSUED or TOKEN RECEIVED or IN SERVICE or EXPIRED FINISHED the time when this record becomes valid the time when this record is recycled

Adversary model

We consider two categories of wireless adversaries. The first category is external adversary that poses threat to wireless links. Such an adversary knows and actualizes all network protocols and functions. It can eavesdrop, record, inject, re-order, and re-send (altered) wireless packets within its radio transmission range. The adversary may possess enough bandwidth to access its computational resources via a fast network with negligible delay. Nevertheless, its computational resources may be abundant, but not unbounded. The adversary cannot invert one-way functions, or differentiate cryptographically strong pseudorandom sequences from truly random sequences, with non-negligible probability. The second category is internal adversary that has already compromised a permanent member inside the wireless LAN. We use the escort box to prevent mobile guests from being attacked by such internal adversaries. In the case when the escort box is compromised, we argue that all functions provided by the escort box can be provided without human interaction, thus the escort box can be an enclosed tamper resistant blackbox that is hard to compromise. In addition, since the escort box has localized close contact with both its mobile guests and the wireless LAN, there are abundant chances for intrusion detection systems (or even physical contact) to effectively discover and recover from the threat. More related discussions are presented in Section 4.

3.

DESIGN

The ESCORT design consists of three parts described in Section 3.1, 3.2, 3.3, respectively. In all three parts, ESCORT pays a reasonable implementation cost to change the escort box’s protocol stack. More importantly, ESCORT seeks to minimize changes made to the mobile guest and the wireless LAN, so that the entire scheme is friendly to mobile guests and local system administrators. • In all three parts, ESCORT makes absolutely no change in current IP-based wireless LANs (except the changes on the escort box). The ESCORT model functions in basic IP networks with wireless LAN support. There is no need to realize mobile IP and home domains for mobile guests, as well as centralized authentication and access control services like Kerberos, RADIUS, or certification servers. • In the first two parts (Section 3.1 and 3.2), ESCORT seeks to provide legacy content privacy support to mobile guests. As basic encryption functions are available in current network

standards, there is no change made in the mobile guest’s protocol stack. Mobile guests need to communicate with the escort box privately. Using 802.11 MAC protocol, the mobile guest and the escort can employ 802.11 ad-hoc mode in their communication. If degradation of mobility is allowed, the mobile guest and its escort box can also be wired together. • In the third part (Section 3.3), upgrades need to be applied to the mobile guest’s protocol stack as not-yet-supported mobile privacy services are added. However, the change made is minimized and its implementation is highly efficient.

3.1

Escort serving single mobile guest

Figure 2 shows the design paradigm of an escort serving single mobile guest. The mobile guest is roaming from another IP network, thus possessing a non-local IP address and subnet mask. Example guest configuration (Linux): iwconfig essid $ESSID mode ad-hoc key $WEP10 ip route replace default via 7.7.7.8 dev wifi0 Example escort configuration (Linux): echo 1 > /proc/sys/net/ipv4/ip forward iwconfig wifi0 essid $ESSID mode ad-hoc key $WEP10 route add -host 7.7.7.7 dev wifi0 iptables -t nat -A POSTROUTING -o wifi1 -j SNAT - -to 8.8.8.8

It is obvious either wireless segment, namely guest-escort segment or escort-infrastructure segment, can be replaced by a wired connection. However, this obviously impedes the guest’s mobility in the wireless LAN. Either segment can also be replaced by another wireless communication scheme, such as Bluetooth, as long as both ends of the segment support IP networking over the underlying scheme.

3.2

Escort shared by multiple mobile guests

Like 802.11i but unlike stateless 802.11WEP, ESCORT is a stateful design that differentiates one guest from another. The escort box maintains a network security state for each of its guest, and no security parameters are shared by any two guests. Figure 3 shows the design paradigm of an escort shared by multiple mobile guests. The mobile guests may originally belong to different IP networks, thus have different IP addresses and subnet masks.

Wireless LAN IP Addr: 6.6.6.6 MAC Addr: MAC2 Ad-Hoc Mode

Device MAC MAC1 MAC2 MAC3

Wireless LAN IP Addr: 7.7.7.7 MAC Addr: MAC1 Ad-Hoc Mode

Security Parameters key WEP110 key WEP211

IP Addr: 7.7.7.8 MAC Addr: MAC10

IP Addr: 8.8.8.8 MAC Addr: MAC11

Source MAC1

WEP10 Encrypted Payload

Checksum CRC 32

Destination MAC2

Source MAC11

Laptop, iPAQ, Desktop Escort

MAC Addr: MAC2 in LAN 8.8.8.*

Destination MAC3

Guest 1 Destination MAC10

Access Point

Destination MAC10

IP Addr: 8.8.8.8 MAC Addr: MAC11

IP Addr: 7.7.7.7 MAC Addr: MAC1 Ad-Hoc Mode

Laptop, iPAQ, Desktop Escort

Guest

WEP11 Encrypted Payload

Destination MAC10

Checksum CRC 32

Figure 2: Escort serving single mobile guest (Traffic from guest to LAN depicted) After roaming into the escort’s wireless LAN, the mobile guest presents the secret confirmation token to the escort. Here we suggest to use a small application layer program we have designed. The small token-provision program is customizable for each specific escort box, and is downloadable by the guest at the pre-registration phase via the protected registration channel. FEC coding and TCP connection are used in the program to implement an extremely reliable token transmission procedure. The escort box runs a daemon process on the designated tokenacceptance port. Upon receiving the confirmation token, the escort retrieves related records according to the confirmation token, then both sides switch to 802.11 ad-hoc node and follow the prescheduled configuration. The confirmation token is annulled upon its first usage as it is published during the contact. The probability that an adversary can correctly guess a valid confirmation token is only pguess = 21281 −k where k is the number of confirmation tokens issued by the escort within the past years. The communication between the guest and its escort is protected by available link layer security protocols, currently likely to be WEP and TKIP, and in the future would be replaced by stronger protections like AES-CCMP. For routing, the guest merely sets his wireless card to ad-hoc mode and makes the escort its default gateway. The escort box acts as a network address translation (NAT) box, thus for third parties the communication appears to be originated from the escort box. This prevents the internal adversaries inside the wireless LAN from attacking the mobile guest.

MAC Addr: MAC3 in LAN 8.8.8.*

IP Addr: 6.6.6.8 MAC Addr: MAC10

Guest 2

Device MAC MAC1 MAC2

Security Parameters key WEP110 key WEP210 key WEP311

Source MAC1

WEP110 Encrypted Payload

Source MAC2

WEP210 Encrypted Payload

Access Point

Source WEP311 Encrypted MAC11 Payload

Checksum CRC 32

Checksum CRC 32

Checksum CRC 32

Figure 3: Escort shared by multiple heterogeneous mobile guests (Traffic from guest to LAN depicted) The escort box communicates with its mobile guests in ad hoc mode. For routing, the escort box has an alias in each of the mobile guest’s subnet. A mobile guest treats the escort’s alias as its default gateway. The escort box’s link layer driver is rewritten—the corresponding IP aliases in each wireless packet are translated into the configured IP address of the ad hoc side of the escort box (6.6.6.8 in Figure 3). This operation is feasible because guest-escort communication is identified by MAC addresses instead of IP addresses. The escort box then does network address translation and forwards the packet to the infrastructure via its network interface in managed infrastructure mode. Like Section 3.1, the communication between the guest and its escort is protected by available link layer security protocols, currently likely to be WEP and TKIP. In ESCORT, different mobile guests do not share the same encryption key. To implement this feature, the encryption/decryption module in the firmware of the escort’s ad hoc mode interface is disabled. Instead, the escort box uses software-based encryption. Because security parameters for different mobile guests are stored under their unique confirmation numbers, the escort box can use efficient table lookup to retrieve relevant security parameters for each mobile guest at real time. The processing scalability of ESCORT design is proportional to the processing power of each escort box and the total number of escort boxes implemented in the wireless LAN. Our “proof-of-concept” implementation uses the linux-wlan-ng driver http://www.linux-wlan.com/linux-wlan for our Prism II chipset based PCI card. These drivers do support software based encryption, however they only support a single WEP key for

encryption or decryption. We extended the driver code at the escort to allow it to do MAC address to WEP key mapping in real time and thus encrypt or decrypt the 802.11 payload with the correct key. So now, multiple guests using the same escort use the same ESSID for the one-hop ad hoc network but they do not share security parameters.

3.3

Providing extra mobile privacy services

guest B uses an escort device. Figure 4 illustrates that the protection area for guest A is the entire circle. In other words, the entire forwarding path between guest A and its servers needs to be protected, especially at the bootstrapping time when ID is authenticated and access is granted. This means any eavesdropper and traffic analyst en route can potentially trace network IDs belonging to guest A, for example, via control packets (ICMP and IGMP messages) and data packet headers. Hence a corresponding countermeasure is expected to be much more complex and expensive.

ESCORT provides extra mobile privacy support to mobile guests.

ity ym pro tec tion

“The Ring Argument” in mobile anonymity design Unlike content privacy, end-to-end security cannot ensure identity privacy and location privacy. This is because the guest’s identities are revealed in protocol control messages like data packet headers and ICMP packets. Compared to a centralized solution, we observe that a decentralized and localized solution is in general more suitable to provide anonymity support to mobile guests. The latter solution needs to protect much less network resources vulnerable to adversary’s attack. Without loss of generality, let’s compare a pair of mobile guests: Guest A uses centralized services like DHCP and RADIUS, while

non

nymous wireless transmission at data link layer between mobile guests and the escort box. Throughout this paper, we use the term “anonymity” as a synonym of “anonymity in terms of unlinkability” [15]. That is, wireless transmission and node ID is not linkable from both directions: an anonymous transmission is not linkable to any node ID, and a node ID is not linkable to any anonymous transmission. More specifically, sender anonymity means that a particular transmission is not linkable to any sender’s ID, and any transmission is not linkable to a particular sender’s ID. Recipient anonymity is similarly defined. The design goal of ESCORT is to ensure that any mobile guest’s network identity is not revealed to any local network entity except the escort. This implements sender anonymity, recipient anonymity, and location privacy for all mobile guests. Anonymous communication between mobile escort boxes and the wireless LAN can be addressed within a similar framework, though the subject is beyond the scope of this paper.

da

Anonymity terminology and design goal The design goal of ESCORT’s anonymity and untraceability support is to implement ano-

guest A

ne e

We have to point out a major difference between this extra-service part and the previous two parts: Unlike the design of the previous two parts where no change is made in the mobile guest’s protocol stack, some changes have to be made in the guest’s protocol stack because the corresponding supports are not yet implemented anywhere. Nevertheless, ESCORT adopts a minimalist methodology when changing the guest’s protocol stack. In particular, identity privacy and location privacy are ensured in ESCORT. This means that ESCORT provides anonymity and untraceability support to mobile guests. Such support may not be critical to (non-private) mobile access scenarios (e.g., Case I). However, for private enterprise networks (e.g., Case II), it is dangerous to let external eavesdroppers trace communication characteristics of visiting guests. In a wireless LAN without anonymity and untraceability support, an external eavesdropper is capable of seeing all visitors’ MAC IDs, and sometimes other IDs including IP addresses. By seeking help from recorded chronicles and databases, the external adversary can reveal private identity information in the wireless LAN. Proposed network security protocols, such as WEP, TKIP, AES-CCMP, IPsec, SSL, do not address this problem and cannot stop the threat.

escorted guest B

centralized service escort

need anonymity protection

Figure 4: The Ring Argument in mobile anonymity design In contrast, the cost of anonymity protection is significantly decreased in the decentralized and localized ESCORT paradigm. As the escort has provided on-device anonymity protection for the guest, the protection area is only the ring depicted in Figure 4. A third party not in the ring area cannot easily break guest B’s anonymity. Review of the impact of previous design choices on guest’s anonymity We have considered the anonymity demand in previously described ESCORT’s design choices. At the beginning of guestescort interaction, an anonymous 128-bit pseudonyms/IDs, rather than mobile guests’ real IDs, are used to identify legitimate guests. Then ESCORT employs sophisticated techniques to translate guests’ traffic into escort’s own traffic. As a result, adversaries cannot reveal guests’ identities unless they are capable of compromising the escort-guest mapping procedure or even intruding the escort box. The capability requirement eliminates external adversary’s threat, and limits internal adversary’s threat to the escort-guest mapping procedure and the escort boxes. The local domain should accordingly protect these two critical components. Securing the “ring” As a mobile guest shares a secret with its escort, a naive solution is to use the secret as cipher key to encrypt the source and destination MAC addresses in 802.11 packet header. However, this naive solution has a non-trivial problem. The encrypted result is a random bit-string looks like a valid MAC address. It is possible the encrypted result collides with a valid local address, then 802.11 frames will continuously be duplicated at both colliding sites. In a locality, given m plain MAC addresses and n encrypted MAC addresses, the probability for an encrypted MAC address colliding with a plain MAC address is  m n pcollision = 1 − 1 − 48 . 2

This quantity cannot be treated as negligible when n is large. Unfortunately, since re-keying is enforced in 802.11i, n increases as the keys are updated periodically. In TKIP a key should be updated

in less than every 216 packets. On an 11Mbps 802.11b access point, this means re-keying may happen every minute1 , and n constantly increases over time. ESCORT adopts an alternative approach where collision probability is tractable and can be tuned to be negligible. In ESCORT, 802.11 network interfaces can use a special MAC address FF:FF: FF:FF:FF:FE to accomplish anonymous wireless transmission (FF:FF:FF:FF:FF:FF is a special 802.11 MAC address for local broadcast). A sender can use the special address to hide its own MAC address and its receiver’s MAC address. Using 802.11WEP as the example, the link layer frame format is slightly changed from2 dest MAC 48 bits

src MAC 48 bits

encrypted payload up to 1500 bytes

CRC-32 checksum 32 bits

to FF:FF:FF:

FF:FF:FF:

FF:FF:FE

FF:FF:FE

encrypted payload up to 1500 bytes

CRC-32 32 bits

SEQ# 8 bits

PRN# 128 bits

The trailing new field consists of two sub-fields: a pseudorandom number P RN # and a sequence number SEQ#. Currently we select P RN # to be at least 128-bit long and SEQ# to be 8-bit long. The design motivation is justified right below. Wireless LAN

IP Addr: 7.7.7.7 MAC Addr: MAC1 Ad-Hoc Mode

Device MAC MAC1 MAC2

Security Parameters key WEP110 key WEP211

MAC Addr: MAC2 in LAN 8.8.8.* IP Addr: 7.7.7.8 MAC Addr: MAC10

IP Addr: 8.8.8.8 MAC Addr: MAC11

Access Point Guest XORed with PRN# stream Destination FF:FF:FF:FF:FF:FE

Source FF:FF:FF:FF:FF:FE

WEP110 Encrypted Payload

Laptop, iPAQ, Desktop Escort

Checksum CRC 32

SEQ# 8 Bits Destination MAC2

PRN# 128 Bits Source WEP211 Encrypted MAC11 Payload

Checksum CRC 32

Figure 5: Efficient provisioning of mobile privacy services (Traffic from guest to LAN depicted) Cryptographically strong pseudorandom function (PRF) is an essential design component of common security protocols, such as TKIP,SSL/TLS/WTLS. Two parties sharing a secret seed can use the PRF to produce self-synchronized pseudorandom numbers. That is, the i-th pseudorandom number is P RNi = P RF (P RF (· · ·P RF (seed)· · ·)) = P RF i (seed). {z } | i

Shamir [19] has proven that such one-way hash chain is cryptographically strong. The cryptographic concept behind the design is unpredictability in polynomial time, which means that no Turingcomplete algorithm can effectively differentiate a cryptographically strong pseudorandom sequence from a truly random sequence in polynomial time. By sharing a common cryptographically strong PRF, anonymous wireless transmission with negligible collision probability can be realized on top of such cryptographically strong pseudorandom sequences P RN #. Although an anonymous 802.11 frame is received by all local nodes, only the one with self-synchronized pseudorandom number sequence can match the number and conclude 1 Given maximum frame length as 1500 bytes, the lapse is 72 seconds on a busy 802.11b access point. The lapse is even smaller on a 54Mbps 802.11a/802.11g access point. 2 There is a type field in 802.3 and 802.11 Ethernet frame format. It is treated as payload in this paper for the ease of presentation.

that it is the intended receiver. The other local nodes have negligible chance to collide with the cryptographically strong pseudorandom sequences. In a locality with n local connections, at each moment there are only n PRNs to be the candidates of collision. Even due to “classic occupancy problem”, the collision probability is negligible when the bit-length of P RN # is sufficiently large. For n 128-bit long PRNs, Qn−1 128 (2 − i) pcollision = 1 − i=0 128 n , (2 ) which is a negligible quantity compared to other probabilistic quantities. For example, any checksum, including the one used in TCP or UDP, is only computationally sound rather than perfect. In other words, there is negligible but greater than zero probability that a checksum-protected packet is indeed corrupted but undetectable. For example, by using 128-bit MD5 as the message integrity checksum function, the probability of such detection failure is about 1 per 2128/2 = 264 packets due to “birthday paradox” [11]. This probability is much higher than pcollision of 128-bit PRNs. The sequence number SEQ# field is added due to wireless packet loss. If the channel is reliable, consecutive frames can be trivially associated with a sequence of consecutive pseudorandom numbers. However, the wireless channel is unreliable and packet loss is possible. In 802.11, link layer ARQ (Automatic Retransmission reQuest) can significantly increase transmission reliability. Under such application scenario, packet loss may cause a gap between received frames, but the size of the gap is limited. ESCORT assumes there is negligible chance for the channel to drop more than 256 packets consecutively under 802.11, thus the size of SEQ# field is defined as 8 bits. At the sender side, SEQ# is increased by 1 for each distinct 802.11 frame and wrapped around per 256 frames. If the most recent SEQ# received by the receiver is a and SEQ# of the current frame is b, then the receiver can synchronize the pseudorandom sequence by computing P RF b (seed) = P RF b−a (P RF a (seed)), i.e., applying PRF (b−a) times on the current number P RN a (seed). This operation is efficient when the gap (b − a) is limited. In a nutshell, with negligible collision probability and insignificant link layer implementation change, ESCORT implements an anonymous and loss tolerant transmission protocol in unreliable wireless channels. The communication cost of the anonymous protocol is about 136-bit overhead per 802.11 frame, and the computation cost is about 128-bit encryption per frame.

4. DISCUSSION 4.1 Controlling misbehaving guests and escorts It is possible a guest may try to be an illegitimate escort. This attack can be countered by two means: (1) The wireless LAN is configured to accept only authenticated and authorized escorts, which are manageable permanent members; (2) The pre-configured escort boxes provide Internet connection only, i.e., they can be configured to filter any traffic between the guests and the local domain. In addition, all the network functions described in Section 3 can be written into flash ROM residing in a tamper resistant blackbox. Unauthorized update of the escort box is not allowed. As a result, it is hard for a mobile guest to compromise the escort box and use it as an attack agent against the wireless LAN. Therefore, although the escort box is the single point of failure/compromise of the guest (while a centralized server is a single point of failure of the entire domain), a tamper resistance argument is a valid one to justify its robustness against attacks. In addition, we

also consider the scenarios where an escort box is compromised by an extremely capable adversary. In this case we have to address two issues: (1) protecting a mobile guest from being attacked by its escort; and (2) protecting the wireless LAN from being attacked by the escort box, or equivalently, by collaboration of the escort box and its mobile guests. From a mobile guest’s standpoint, its identity privacy and location privacy are compromised when its escort box is hacked. Fortunately, it can ensure content privacy by employing end-to-end security protocols like SSH, HTTPS(using SSL/TLS), host-to-host IPsec, or point-to-point protocols like host-to-subnet IPsec. The protected traffic is tunneled by its escort box to the intended destination. The escort is an eavesdropper who cannot compromise mobile guests’ content privacy. In addition, if the escort box decides to disrupt the guest’s traffic, the guest can detect the misbehavior by monitoring and comparing packet loss ratio and channel condition. From the wireless LAN’s standpoint, we consider two scenarios: (1) Monitoring misbehaviors of a fixed host (including a fixed escort box used in Case III) is an existing problem on the Internet. Corresponding countermeasures can be found in existing designs of intrusion detection systems proposed for wired Internet [17]. (2) If the escort box is a mobile wireless box, we would show below that the problem is also tractable.

it is not a cryptographically strong one against artificial message injections. Borisov et al. [3] showed that adversaries can launch a variant of replay attack: given two valid frames of same length, an adversary can simply XOR them together, then the result can be successfully injected into ongoing wireless traffic because XOR-ed checksum is valid in linear systems. On the other hand, CRC-32 is a prevalent checksum algorithm with very efficient and very low-cost hardware and software implementations. The success of 802.11 is largely due to its empirical treatment on tradeoffs between design soundness and implementation usability. For the large amount of users who have already bought 15,000,000+ legacy units, it is not a trivial work to completely replace CRC-32 with a newly proposed HMAC countermeasure, such as TKIP’s Michael algorithm and AES-CCMP’s CBC-MAC. It takes time to burn the new algorithms into efficient hardware at a reasonably low cost. The ESCORT anonymous protocol described in Section 3.3 can be used with CRC-32 to resist both natural interferences and artificial attacks. Consider an anonymous frame FF:FF:FF: FF:FF:FE

FF:FF:FF: FF:FF:FE

XORed with ← P RN # stream → encrypted payload n bits

CRC-32 32 bits

SEQ# 8 bits

P RN # ≥128 bits

The compromised escort box is useless if not within one wireless hop of the local domain. On the other hand, if it does show up within one-hop, a “watchdog” mechanism [10] or its equivalent can effectively detect its existence and monitor all traffic in-and-out of the escort. The “watchdog” design assumes that communication is symmetric in wireless broadcast. That is, if a sender’s radio transmission can be received by a receiver, then this receiver’s radio transmission can also be received by the sender. The wireless LAN can deploy a watchdog device on each access point, hence all traffic in-and-out of any escort box can be effectively recorded and analyzed by a powerful escrow server inside the infrastructure. A watchdog device can be implemented by a simple wireless interface running in RFMON mode (similar to Ethernet’s promiscuous mode) and connecting to the escrow server. An authorized escrow server may realize key escrow service (e.g., authorized to have backup keys for the guest-escort hop) to decrypt and monitor any guest-escort hop as well as escort-infrastructure hop. The watchdog-based scheme has extra implementation and deployment cost, but the cost is limited since it leverages many existing components inside the resource-abundant infrastructure.

As the P RN # embedded in a valid frame is unpredictable and collision-resistant, messages injected by wireless adversaries are effectively stopped by the ESCORT anonymous protocol, while CRC-32 is used to detect bit corruption. In 802.11-like schemes, a single frame is transmitted without interruption. The adversary has no chance to inject bits during a packet transmission, or the frame received by the receiver is corrupted due to radio signal interference. Thus for 802.11, the embedded P RN # is already the proof of message authentication, and the XOR operations can be spared. However, for time divisioned MAC schemes, the sender must repeat the P RN # to construct an n-bit keystream, then XOR the keystream with the encrypted payload before transmission. For a cryptographically strong P RN #, the adversary is expected to correctly guess half (plus a negligible quantity) of the bits by coin-flips, and the other half is incorrectly guessed. In other words, by the XOR protection scheme an injected rogue frame is expected to have approximately n2 “corrupted” bits, and CRC-32 can be used to detect the “corruption”. Note that the corresponding P RN # is revealed at the end of the frame, which prevents the adversary from having the chance to forge a valid frame. However, since the current P RN # is revealed, each link layer ARQ re-transmission must use a new P RN # in order to guarantee the protocol’s robustness against message injection. In a nutshell, ESCORT demonstrates a new way to ensure message integrity using common linear checksum algorithms and common pseudorandom number generators. Based on the cryptographic concept of “unpredictable in polynomial time”, ESCORT can reuse legacy hardware supports (e.g., in 802.11WEP, CRC-32 for checksum, RC4 for pseudorandom number generation) to effectively realize both message integrity support and anonymity support. Such benefits come with reasonable communication and computation costs.

4.2

5.

Wireless LAN

Escort

Guest



AP + Watchdog









         

LAN

Escort of no use (out of range)

Escrow server

Figure 6: Watchdog device beside access point

Interaction with linear CRC-32 algorithm to stop message injection

Message integrity checking has been a big problem for 802.11 security. A message may be corrupted by either natural causes or artificial attacks. The linear CRC-32 checksum is a proven algorithm in detecting data corruption incurred by natural causes, but

5.1

PERFORMANCE EVALUATION Towards ideal implementation: a sample setup

In the ideal case, an escort box is comprised of five components materialized in an as compact as possible blackbox: (1) a low-

800 A-nowep-client1 A-hwep-client1 A-swep-client1 A-nowep-client2 A-hwep-client2 A-swep-client2

700

600 Bandwidth (Kbps)

cost processor for protocol enforcement; (2) a large-enough but bounded memory used by the processor; (3) a wireless interface to connect to the LAN; (4) a wireless/wired interface to connect to the guest; and (5) a tamper-resistant shell to protect any physical tampering of the above four components. In particular, we recommend to select read-only memory that can only be modified/written after opening the tamper-resistant shell, so that mobile guests or other unauthorized parties cannot easily mishandle the escort box, for example, they should not be able to make the escort box run mobile agents or codes not conforming to pre-installed network protocols.

500

400

300

200

100 1

10

100

1000

10000

File Size (KB)

Figure 9: Download Speeds for the two guests with WEP:disabled (nowep), firmware (hwep) and software (swep) Figure 8: The compact escort Figure 7: A single mobile box (iPAQ) with two wireless interfaces guest and its escort Limited by our hardware acquisition capability, Figure 7 illustrates our smallest mobile escort box (HP iPAQ3870 with double expansion pack running Familiar Linux 2.4.18-rmk3) and a single laptop guest (IBM Thinkpad T30 running Microsoft WinXP). The two wireless interfaces on the escort box are clearly shown in Figure 8. As less expensive and more powerful wireless hardware will be available in the foreseeable future, the current setup can be improved and customized to achieve better communication and battery efficiency with diminishing cost.

5.2

5.4

NAT Overhead

For NAT overhead evaluation, we used four scenarios and three kinds of tests to determine the overhead of ESCORT.

Preliminary testbed evaluation

For experimental purposes, we have developed a simple ESCORT testbed consisting of a Pentium III notebook running a Linux 2.4.xx kernel functioning as the escort and a couple of similar notebooks acting as guests. We use the secure wireless network in the department as the secure domain. Some relevant configuration, hardware and software features regarding setting up the network and enabling WEP on the various links have been discussed at various places in Section 3. The notebook which we configured as an escort has a Prism 2 chipset based PCI card for wireless connectivity. There are a few drivers for Prism 2 based 802.11 cards, and we decided to go with the linux-wlan-ng drivers. Our evaluation of the scheme was geared towards finding out how much performance penalty the user would have to pay to use such a system. In particular, we wanted to evaluate the overhead of doing software based WEP at the escort, and the overhead of doing NAT at the escort.

5.3

than firmware-based WEP for the Prism 2 chipset based wireless card. The two guests we used had different firmware versions on their Orinoco cards, and this was probably why they received different bandwidths even when accessing the escort exclusively. Having observed that using host-based WEP is comparable to firmware based implementations on typical machines functioning as escorts, we conducted the rest of the tests with host-based WEP enabled.

WEP Overhead

We considered three kinds of scenarios, no WEP, firmware-based WEP (WEP done by the card) and host-based WEP (WEP done by the CPU of the escort). Although “no WEP” is completely insecure, we still test it as a reference point. We setup the FTP server on the private interface of the escort, so that we eliminate NAT overhead. We use an FTP client at the single guest to download files of varying sizes and plot the latency for each scenario in Figure 9. The graph shows that the effect of using host-based WEP on performance is insignificant. In fact in some cases, it does better

FTP Server

Escort as FTP Server

Guest 1

Escort as FTP Server

Guest 1

A - Single Guest downloading from Escort.

FTP Server

Escort

Guest 2

B - Multiple Guests downloading from Escort.

Guest 1

C - Single Guest downloading from department FTP server.

Escort

Guest 1

Guest 2

D - Multiple Guests downloading from department FTP server.

Figure 10: Test Scenarios : A, B, C and D The first scenario depicted in Figure 10A corresponds to a single guest with the FTP server at the escort’s private interface without NAT. The second scenario depicted in Figure 10B corresponds to two guests (with different WEP keys) and the FTP server at the escort’s private interface without NAT. These scenarios provide for us the baseline against which to compare the overhead of doing NAT. The next two scenarios are the same except that we put the FTP server on a machine in the wired LAN. Comparing scenarios C and D with scenarios A and B respectively show us the overhead of doing NAT. Comparing scenarios A and B highlights the orthogonal issue of fair sharing and bandwidth utilization in the presence of multiple guests in 802.11 ad hoc mode. We performed the following tests on each of the scenarios :

5.5

Packet Latency and Available Bandwidth Tests

The first test was a standard ping test, where we ping the FTP server 30 times from the guests. We observe that the additional

900

hop as well as decryption of a ping packets does not amount to any measurable overhead to the system. Guest 1 RTT (ms) 1.163 0.848 1.437 1.167

Guest 2 RTT (ms) 5.207 3.867 5.174 5.356

700

The second test involved calculating the available end-to-end tcp bandwidth using a publicly available tool Iperf http://dast. nlanr.net/Projects/Iperf. We perform the Iperf tests for 60 seconds each in scenarios A, B, C and D. Scenarios Scenario A Scenario B Scenario C Scenario D

Guest 1 BW (MBps) 4.32 2.16 4.33 2.08

800

Bandwidth (Kbps)

Scenarios Scenario A Scenario B Scenario C Scenario D

B-client1 D-client1 B-client2 D-client2

600

500

400

300

Guest 2 BW (MBps) 2.36 2.29 2.36 2.03

200

100 1

10

100

1000

10000

File Size (KB)

Figure 12: NAT Overhead: Multiple Guests Our tests show that there is an insignificant overhead cost added to the communication channel because of NAT and WEP encryption— we see no additional cost to single guest scenarios and a 8.64% cost in the double guest case. This value basically falls within the oscillations experienced due to random contention and interference.

5.6

Bandwidth Intensive Tests

The second type of tests included a series of downloading different sized packets. The packets we used were of size 2nˆ , with n=10 to 22 (1 KB up to 4 MB), downloaded using WGET (passive-ftp) from a P-III 1GHz FTP server in the wired LAN (100 Mbps Ethernet). These tests allowed us to get a good estimate of the maximum consistent download speed—downloads of very small files sometimes result in wildly varying observed download speeds because of 802.11 channel capture, random network jitter, and handshake costs more than packet decryption/encryption costs or bandwidth limitations. 550 A-client1 C-client1 A-client2 C-client2

500

Bandwidth (Kbps)

450

400

350

300

250

200

transmitters. In the multiple guests scenarios (B and D) we see a noticeable drop in the bandwidth compared to the single guest cases. This problem is also inherited from 802.11’s contention based sharing of the available bandwidth by the two colliding guests.

5.6.1

Results Summary

We found that the download speed stabilizes when we download files 1MB and larger. Larger file downloads have negligible difference in observed download speed. We also observe that turning on WEP in software or hardware or turning off WEP show little difference in download speeds. The packet decryption and encryption in software at the escort as well as NAT portion of the ESCORT model introduce little difference. Overally our tests bring out the inherent random jitter, channel capture, and interference effects that plague existing 802.11 solutions. For example, in our results, the multiple guests together get less aggregate bandwidth than a single guest gets on the average when operating alone. Our solution towards handling multiple guests at a single escort also inherits the 802.11 problems with regard to multiple access. Currently, we find the 802.11 bandwidth sharing to be the bottleneck rather than processing at the escort. Therefore the scalability concerns of 802.11 with respect to number of guests in ad-hoc mode remains an important issue that needs to be addressed in the future. Apart from the above numerical results, the authors also spent considerable time browsing the net and carrying out other regular network activities on the guest like remote TELNET/SSH and checking E-mail, but did not experience obvious slowdown. We believe that an improved 802.11 with fairness and latency guarantees will further improve user experience for the ESCORT paradigm.

150 1

10

100

1000

10000

File Size (KB)

Figure 11: NAT Overhead: Single Guest Figures 11 and 12 shows the NAT overhead for guests in single and multiple guest scenarios. Its clear that NAT does not have significant impact on the tested scenarios’ performance. The graphs also show that in the single guest scenarios (A and C), guest 2 performs much worse than guest 1. We re-experimented with various cards and even exchanged cards but the speeds remained the same on the two guests. Both the guests were running Linux 2.4.20-8 so the problem is probably due to guest 1’s better processing power (i.e., shorter processing delay) and 802.11’s unfairness against late

6.

COMPARISON WITH RELATED WORK

Providing convenient and secure network access to mobile users has attracted critical attention since wireless LANs are deployed in academies and enterprises. Many related projects rely on centralized resource management in their mobile access design. As a result, at least one DHCP server, Kerberos authentication and ticket granting servers, RADIUS server, and SNMP server must present at the time of mobile access, to name a few, authenticated aperiodic connection [21], InSite [6], NetBar [14], and SPINACH [16, 1]. A significant difference between decentralized ESCORT and these centralized schemes is service availability. For instance, even with a considerably large IP address pool (which may not be feasible

in small enterprises and colleges), the DHCP server may ironically run out of IP addresses at an important conference day when many mobile users do need the resource but cannot get it. Or with certain probability, services are completely stopped because the systems sustaining the centralized servers are under denial-of-service attack or simply crash. Or the Kerberos system administrators have to add transient accounts and delete ghost accounts hour by hour, day by day. In contrast, a decentralized solution like ESCORT is resilient to the problems that haunt the centralized schemes. A wireless LAN can realize many fixed and mobile escort boxes, and each escort box can help multiple mobile guests to connect to the infrastructure. In addition, ESCORT also provides extra security services, in particular mobile privacy supports that have not been considered in the related projects. Studies on untraceability in one-hop wireless cellular networks have attracted attention since mid 1990s. Samfat et al. [18] uses KryptoKnight [13, 12] to build a light-weight untraceability service for mobile users. Ateniese et al. [2] provide a comprehensive survey on similar subjects. However, the adversary model and design goals of these literatures are very different from ESCORT. In particular, these literatures focus on implementing one-time aliases that can be used by authenticated mobile hosts to hide their real identities to foreign domains that are treated as potential adversary. The creation process of such one-time aliases normally involves a mobile host’s home domain. In contrast, ESCORT’s design goals are orthogonal to such design: (1) We assume the mobile guest and the escort are already acquainted with each other, thus there is no anonymous requirements between these two parties, while Samfat and Ateniese’s schemes seek to hide mobile guest’s identity from the local domain including the escort. The adversaries addressed by ESCORT are eavesdroppers and third parties other than the escort. (2) ESCORT focuses on protecting packet-level transmission between the mobile guest and the escort. The technical challenges facing ESCORT are communication efficiency and minimal change to mobile guest’s protocol stack, while home domains and associated non-trivial protocol stack updates are prerequisites in Samfat and Ateniese’s schemes.

7.

CONCLUSIONS AND FUTURE WORK

In this work we have designed and implemented ESCORT, a decentralized and localized mobile access control system. ESCORT is an easy-to-deploy-and-use, efficient, and secure system that connects mobile guests to secured wireless LANs. The core of the ESCORT design is a newly proposed concept “escort”, which locally functions as a mixture of security authority and security gateway. The escort box ensures all three aspects of mobile privacy, namely content privacy, identity privacy, and location privacy. The implementation cost of ESCORT is very low and the result system is efficient and potentially mobile. So far we have evaluated ESCORT’s content privacy services in a real testbed. In the near future we will evaluate ESCORT’s anonymity services in the same testbed. In addition, the current ESCORT design only addresses mobile access to a single wireless LAN. For mobile access to multiple local wireless LANs, the mobile guest can trivially reserve an escort in each of the LAN and seek help from an apposite escort inside each LAN. However, if the mobile guest wants to enjoy free local roaming at real time, then an efficient escort registration phase must be embedded in ESCORT design to assign the guest a nearest/best escort box at real time. Currently we are working on an efficient solution to meet the demand.

8.

REFERENCES

[1] G. Appenzeller, M. Roussopoulos, and M. Baker. User-friendly Access Control for Public Network Ports. In IEEE INFOCOM, 1999. [2] G. Ateniese, A. Herzberg, H. Krawczyk, and G. Tsudik. Untraceable Mobility or How to Travel Incognito. Computer Networks, 31(8):871–884, 1999. [3] N. Borisov, I. Goldberg, and D. Wagner. Intercepting Mobile Communications: The Insecurity of 802.11. In MOBICOM, 2001. [4] D. A. Cooper and K. P. Birman. Preserving Privacy in a Network of Mobile Computers. In IEEE Symposium on Research in Security and Privacy, pages 26–38, 1995. [5] S. Fluhrer, I. Mantin, and A. Shamir. Weakness in the Key Scheduling Algorithm of RC4. In 8th Annual Workshop on Selected Areas in Cryptography, pages 1–24, 2001. [6] P. Honeyman. Workstation Authorization. http://www. citi.umich.edu/u/honey/talks/insite/, 1997. [7] IEEE Computer Society. Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. IEEE standard 802.11, 1997. [8] IEEE Computer Society. Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security. IEEE standard 802.11i/D30, November 2002. [9] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. http://www.ietf.org/rfc/rfc2401.txt, 1998. [10] S. Marti, T. Giuli, K. Lai, and M. Baker. Mitigating Routing Misbehavior in Mobile Ad Hoc Networks. In MOBICOM, 2000. [11] A. J. Menezes, P. van Oorschot, and S. Vanstone. Handbook of Applied Cryptography. CRC Press, 1996. [12] R. Molva, D. Samfat, and G. Tsudik. Authentication of Mobile Users. IEEE Network, 8(2):26–34, 1994. [13] R. Molva, G. Tsudik, E. V. Herreweghen, and S. Zatti. KryptoKnight Authentication and Key Distribution System. In Y. Deswarte, G. Eizenberg, and J.-J. Quisquater, editors, ESORICS’92, Lecture Notes in Computer Science 648, pages 155–174, 1992. [14] E. A. Napjus. NetBar - Carnegie Mellon’s Solution to Authenticated Access for Mobile Machines. http: //www.net.cmu.edu/docs/arch/netbar.html. [15] A. Pfitzmann and M. K¨ohntopp. Anonymity, Unobservability, and Pseudonymity - A Proposal for Terminology. In H. Federrath, editor, DIAU’00, Lecture Notes in Computer Science 2009, pages 1–9, 2000. [16] E. Poger and M. Baker. Secure Public Internet Access Handler (SPINACH). In USENIX Symposium on Internet Technologies and Systems, 1997. [17] M. Roesch and C. Green. SNORT: The Open Source Network Intrusion Detection System 1.9.1. http://www.snort.org/, November 2002. [18] D. Samfat, R. Molva, and N. Asokan. Untraceability in Mobile Networks. In MOBICOM, pages 26–36, 1995. [19] A. Shamir. On the Generation of Cryptographically Strong Pseudo-Random Sequences. In S. Even and O. Kariv, editors, International Colloquium on Automata, Languages and Programming (ICALP’81), Lecture Notes in Computer Science 115, pages 544–550, 1981. [20] A. Stubblefield, J. Ioannidis, and A. D. Rubin. Using the Fluhrer, Mantin, and Shamir Attack to Break WEP. In Network and Distributed System Security Symposium (NDSS’02), 2002. [21] D. L. Wasley. Authenticating Aperiodic Connections to the Campus Network. http://www.ucop.edu/irc/wp/ wp_Reports/wpr005/wpr005_Wasley.html, 1996. [22] P. Zimmermann. The Official PGP User’s Guide. The MIT Press, 1995.