Visitor Access Management in Personal Wireless Networks

N. Asokan, Seamus Moloney, Philip Ginzboorg, Kari Kostiainen Nokia Research Center, Helsinki, Finland {n.asokan, seamus.moloney, philip.ginzboorg, kari.ti.kostiainen}@nokia.com

Abstract
The increasing popularity and variety of consumer multimedia devices is driving the need for networked homes. Yet setting up a secure wireless network is a daunting task for most ordinary users. Recently, there have been several proposals for easing this process. However, none of the proposals consider the problem of how to make it easy to manage visitor access. In this paper, we motivate the requirements for visitor management, show the shortcomings of the current easy setup proposals in this regard, and propose a new setup procedure that makes it easy to manage visitor access to wireless networks. Our contributions are twofold: First we present an approach to assigning categories to client devices at admission time so that selective revocation of clients based on those categories becomes possible. Then we present the idea of admission tickets, a flexible and secure way to delegate conditional access rights. We report the results and experience of prototyping of the proposed procedure using the HostAP framework.

1.

Introduction

There is ample evidence that setting up a wireless local area network (WLAN) is a very difficult operation for most ordinary users. Setting up a secure WLAN is even harder. This is a significant obstacle in deploying personal wireless networks [4]. Recently, there have been several attempts to make this process intuitive and painless to the end user [3-9]. While these approaches are effective for setting up wireless networks for personal use, they do not allow easy ways to manage visitor access. Let us motivate our objectives by considering the following usage scenario. Alice purchases a new high speed WLAN access point (AP) and brings that device home. She wishes to easily connect other wireless devices in her home to the new AP so that the resulting wireless network may be used for instance to render

multimedia content to displays or music players located in different parts of her home. After plugging in the AP, Alice takes ownership of it by touching it with a personal device, like a mobile phone. We call this device the Introducer. Then Introducer could also be the home PC or in simpler cases, it could be a physical token, which was delivered with the AP. The AP is then placed high on a shelf where it is out of reach of the children, and Alices new wireless network is ready to use. To admit other wireless home devices, such as a stereo system or a television, to her wireless network, Alice touches those devices with the Introducer. With a single touch, a new device can be admitted to Alices network. Later Alice hosts a LAN party for playing games. Guests bring along their laptops. Alice grants the guest laptops temporary access to her home network. She does this by first choosing the visitor option from a menu of the Introducer device, and touching each guest laptop with the Introducer. When the game is finished and the guests leave, Alice presses a button on the Introducer to end all temporary access granted to visitor devices. Guest laptops no longer have access to Alices wireless network, but Alices own devices continue to work as before. In order to realize scenarios like the above, we need a wireless network setup procedure that 1) is intuitive as well as secure, 2) allows the possibility of easily admitting devices and 3) allows convenient removal of access for visitor devices. To achieve 3), we introduce the notion of a device category (e.g., visitor device, home device). The category information is maintained in a database, and is used to make access control decisions. In this paper, we briefly survey existing solution approaches, and describe their shortcomings with respect to visitor management. We then propose a unified approach that meets our objective and helps realize scenarios like the one described above. The rest of the paper is organized as follows. In Section 2, we describe two existing solution approaches, and analyze

Proceedings of the Seventh IEEE International Symposium on Multimedia (ISM05) 0-7695-2489-3/05 $20.00 2005

IEEE

their drawbacks. In Section 3, we propose our new approach. In Section 4, we describe how the proposal was implemented and present some analysis of the resulting prototype. In Section 5, we summarize the improvements gained by our proposal. In Section 6, we briefly survey other related work. In Section 7 we discuss some future improvements. Finally, in Section 8, we conclude.

because the in-band key agreement protocol is unauthenticated. Second, access rights cannot be delegated from one device to another. To admit a new device to the network, the user must have physical access to the AP.
New Device AP

1. In band key agreement protocol

2.

Solution approaches
PSK PSK

Traditionally WLANs have been protected with a single pre-shared key (PSK). For example, the WiFi Alliances Wireless Protected Access (WPA) has a mode intended for home usage called WPA-Personal. Currently available WPA-Personal APs are such that all WLAN stations and the AP in the same WLAN network share the same PSK. Several recent proposals for solving the easy network setup problem [5-9] are aimed at WPAPersonal using a single PSK. These proposals take one of two approaches: the in-band approach that exploits proximity in time and the out-of-band approach that exploits proximity in space.

2. 802.11i: Link-layer key agreement

Figure 1. In-band protocol for device admission

2.2.

Out-of-band approach

2.1.

In-band approach

The basic approach is to exploit proximity in time to ensure secure admission of authorized devices to the network. The Broadcom Secure Easy Setup proposal [5] falls into this category. Essentially, network setup is performed by first putting the AP into a configuration mode and then putting the new device also into the configuration mode. Putting into configuration mode is done by pressing a button on the respective devices. Once in configuration mode, the devices locate each other using some protocol to agree on a PSK. A suitable protocol is an unauthenticated key agreement protocol like Diffie-Hellman key exchange [10]. The security of the approach relies on the fact that the AP and the new device enter the configuration mode at roughly the same time. The chances of another device or another AP being in configuration mode at the same time are small in the home environment. The advantages of this approach are that the user interaction is intuitive, and the cost overhead of adding a button is small. But there are two limitations. First, the chances of unauthorized admission remain. A malicious host could wait in configuration mode for a victim device or AP to enter configuration mode and pretend to be the AP towards the new device, or vice versa by being quicker to initiate or respond to the in-band key agreement. This is possible

The second approach is to use a physically secure out-of-band (OOB) channel. Using secure out-of-band channels to bootstrap security is a well-known concept. Examples of OOB channels include Near Field Communications (NFC)[8], Infrared[4], audio, visual [11], or even wired connections [2][9]. Essentially, the OOB channel is used to transfer the WLAN network identifier, usually known as SSID (service set identifier), and a shared key from one device to another. The transferred key is used directly as the PSK, thereby avoiding the need for any additional key agreement protocol. To admit a new device to the network, the only user interaction needed is to touch the new device with an Introducer. The Introducer can be a simple special-purpose device like a passive NFC token, or it can be part of another device, such as a phone. Figure 2 illustrates this approach where an Introducer is used to admit a new device into the network. Note that the Introducer can be the AP itself. The security of the approach derives from the perceived physical security of the OOB channel. The advantages of this approach are that the user interaction is intuitive: a single touch is enough to admit the new device into the network, and access rights can be delegated from one device to another, even when out of local network coverage. One disadvantage that adding an OOB channel increases the hardware cost of the device.

Proceedings of the Seventh IEEE International Symposium on Multimedia (ISM05) 0-7695-2489-3/05 $20.00 2005

IEEE

New Device

Introducer

AP

1. Out-of-band: PSK and network parameters

has PSK and network parameters

PSK 2. 802.11i: Link-layer key agreement

Figure 2 Out-of-band device admission

2.3.

Ease of visitor management

channels available. The in-band approach does not allow delegation of access, and is less secure, but it is less expensive and is already appearing in commercial APs and client devices. Both approaches do not support easy management of visitor access. What is needed is a unified approach that: supports the in-band approach on all devices, but the ability to use OOB where possible to increase security and usability, and the possibility of delegating access from one device to another, and allows easy management of visitor access, including the delegation of access rights using a single-touch user interaction. Figure 3 illustrates one possible way to achieve this unification.
New Device Introducer AP

Visitor access management remains cumbersome in both approaches. Since all the devices use the same PSK, the only way to remove visitor access is to remove all devices from the network, and add home devices once again, one by one. To avoid this problem, each device must have some key that is unique to that device. The obvious solution is to use a unique PSK for each device. The WPA-2 specification, which is the same as the IEEE 802.11i specification, does support multiple PSKs in the same network. But moving from a single PSK to multiple PSKs is not straightforward. Both the new device and the AP must learn the new pair-wise PSK assigned to them. This implies either the user interaction requires an additional step (e.g., Introducer touches the AP and then touches the new device), or additional signaling is needed to communicate the new PSK between the Introducer and the AP. The first option does not preserve the single-touch user interaction during delegation. The second option requires the use of an additional interactive protocol. Even when each visitor device has a unique key, there must be an easy way for a human to distinguish one key from another so that selective revocation becomes easy.

1. Out-of-band: AK, AK_ID, n/w parameters

has AK and network parameters

AK, AK_ID 2. In band key agreement protocol: AK_ID

PSK 3. 802.11i: Link-layer key agreement

PSK

Figure 3. New unified approach If an OOB channel is available, it can be used to transfer an authentication key (AK), a key identifier (AK_ID) and the address of the AP to the new device. Together, the received information constitutes an admission ticket. A client device triggers the in-band key agreement procedure immediately after receiving an admission ticket, or whenever a new AP is detected for which a matching admission ticket is found in local storage. The admission ticket is used to authenticate the key agreement. A device-specific key is derived from the in-band key agreement protocol. This key can be used directly as the PSK, or can be used to deliver the PSK. Once used the admission ticket can be removed from the device. The AP will have two types of receiving modes. In the authenticated receiving mode, it will only accept requests for authenticated key agreements. AK will be used to authenticate the key agreement. The AP will always be in the authenticated receiving mode. By pressing a button on the AP, it can be put in to unauthenticated receiving mode for a short time. The behavior in this mode is the same as in the pure inband approach described in Section 2.1. Authentication of key agreement helps avoid accidental admission, and man-in-the-middle attacks

3.
3.1.

A unified approach for Easy Setup

Basic description

Both approaches seen in Section 2 have advantages and disadvantages: the OOB approach is more secure and possibly more intuitive, but because of the extra hardware requirements, it may not be reasonable to expect that all devices will have suitable OOB

Proceedings of the Seventh IEEE International Symposium on Multimedia (ISM05) 0-7695-2489-3/05 $20.00 2005

IEEE

are removed. But it also enables better management of visitor access as we shall see in the next section.

3.2.

Deriving authentication keys

The owner of a WLAN shares a long-term owner authentication key (OAK) with the AP. OAK is stored safely in the Introducer device. When the Introducer wants to admit a new device, it uses a suitable key derivation function (KDF) to compute a new AK by diversifying with the AK_ID parameter. In other words, AK = KDF(OAK, AK_ID) AK_ID contains two mandatory parts: 1. current value of a monotonically increasing counter maintained by the Introducer. 2. the type of AK, which is an integer identifying the device category to which the user wants the new device to belong to (e.g., 1=home, 2=visitor etc.) AK_ID may also contain other fields such as a friendly name for the new device (e.g., the string Bobs phone), and the lifetime of the resulting PSK. AKs are limited to a single use only and can be limited to a short lifetime (e.g., 1 day) as well. During the OOB exchange, the Introducer will pick AK_ID, compute AK and communicate both to the new device. The new device will send AK_ID to AP in the in-band key agreement protocol. AP can then (a) check to see if the sequence number in AK_ID was not used previously, and (b) if so, calculate AK. The new device and AP will then use AK to authenticate the inband key agreement protocol. The AP maintains a sliding window of acceptable sequence numbers. It updates the window whenever it receives a new sequence number. If AKs, and hence sequence numbers, have a short lifetime, old unused sequence numbers will automatically expire. The result is that an AK can only be used for a short period of time. After a successful authenticated key agreement, AP will store the PSK along with the relevant portions of the AK_ID. The PSK will be used by the new device on subsequent associations with the AP. Note that if an attacker were to modify the AK_ID in order to get a longer key lifetime or to change the ticket type to home from guest, the attack would fail because the AP would generate a different AK to that possessed by the attacker and the authentication from the key agreement would not succeed.

The admission ticket contains the following information: Address of the Access Controller function o SSID of the AP: string (mandatory) o DNS name: string (optional) o IP address: IP address (optional) AK_ID o Sequence number: integer (mandatory) o Category: positive integer (mandatory) o Lifetime: integer (optional) o Friendly name: string (optional) AK: bitstring (mandatory) The secret agreed during the key agreement protocol may also be used for remote access, over the Internet, to the same network. Balfanz et al. call this the phone home feature [3]. The optional forms of the Access Controller address are meant to locate the Access Controller during remote access. The AP will maintain a database of the following form: Table 1. Database on AP
MAC address 000A221 3B7CD 000CF14 EC26D 000CF14 EC26E Category HOME VISITOR UNAUTH Expiry Never 101020 05 Never Friendly name Stereo Bobs phone unknown PSK 0x32FD.. 0x81FA.. 0x23BC..

The example shows three client devices. One of them, the Stereo is a home device. Another, Bobs phone, is a visitor device. The PSK of the third device was unauthenticated. Some devices have an infinite lifetime. Bobs phone has a definite expiry date.

3.4.

Revocation of visitor access

3.3.

Formats of the Admission Ticket and AP database

Revocation of visitor access can happen in three ways. First, each visitor admission ticket contains a default lifetime, which the AP translates to an expiry time. AP periodically removes expired entries from its database. In addition, the AP can provide a single Remove Visitors operation. This can be a single physical button on the AP, or a single operation in the AP management interface. For example, the Remove Visitors operation can remove all entries in the database belonging to categories 2 (authenticated visitors), and 0 (unauthenticated devices). Finally, the owner can use the APs management interface to remove selected entries. This is possible because each device is identified by a friendly name that can be chosen at the time of delegating access to that device.

Proceedings of the Seventh IEEE International Symposium on Multimedia (ISM05) 0-7695-2489-3/05 $20.00 2005

IEEE

4.1. 3.5. Taking ownership of the AP

Note that it is really not necessary for the AP to have an OOB interface. The initial OAK and SSID can be delivered in the form of passive tokens, e.g. NFC cards or even barcodes. Each passive token will be for a fixed category, for example there can be a visitor token and a home token. However, if the AP has an OOB interface the AP can use that interface to emit the OAK and network parameters such as SSID, IP address in some limited fashion; for example, exactly once after purchase or full reset of the AP. It can also use the OOB interface to receive OAK and network parameters from the Introducer, again, exactly once after purchase or full reset. Note that if the phone is used as an Introducer and then gets lost or stolen, a full reset of the AP would result in the OAK changing, meaning that phone could no longer manage the network and a new device could take ownership after that reset. All devices in the network would need to be re-added after such an event. The following table summarizes the different possibilities: Table 2. Generation and Delivery of Owner Authentication Key
PARAMETER GENERATION AP generates OAK and network parameters DELIVERY MECHANISM Delivered separately (e.g., passive NFC tokens, Barcodes printed on package) Emitted via OOB channel for a limited time after full reset or purchase. AP receives OAK and network parameters from an external device (e.g., phone) Received via OOB channel for a limited time after full reset or purchase. AP OOB CHANNEL Not needed

Requirements

The two main issues which needed to be addressed in the design of the prototype were how AKs should be transferred over the OOB channel and how can the AK be used as part of the existing WLAN association mechanism. For the OOB mechanism, it should be possible to transfer at least 128 bits so that AKs of a reasonable size can be used. Since AK is used as a key, the bearer used should provide secrecy. For the in-band mechanism, the APs need to be able to indicate that they support Easy Setup and the receiving mode they are in. Client stations must be able to initiate the easy setup key agreement protocol. There are practical requirements: link-layer changes needed to accommodate the key agreement must be kept to a minimum. When one device gets removed from the WLAN, existing WLAN clients must be allowed to use the APs as previously.

4.2.

Design decisions

Needed

Needed

4.2.1. Out-of-band bearer As discussed, there are a number of bearers that could be used for the OOB transfer of data. While NFC represents the best longterm solution in terms of usability and security, infrared is currently the most widespread OOB channel. Most laptops and mobile devices have infrared ports. We used the middleware described in [6] which provides the secure transfer of data over infrared. Other middleware such as [11] could also be used for this purpose. Currently this means our prototype is restricted to devices with infrared interfaces. An important improvement to make would be to add the possibility of OOB capability negotiation, meaning that the devices could figure out which OOB interface they had in common and decide to use that. 4.2.2. Advertisement of Easy Setup capability One way for APs to indicate their ability to support Easy Setup is by using an SSID with a fixed pattern. This would require minimal changes but is not elegant, and cannot be easily extended to convey additional information. The 802.11i specification [13] allows the addition of extra information elements (IEs) to the WLAN management frames. Beacons are sent by APs to clients in range in order to advertise their capabilities. IEEE has allocated a special IE number (221) for these kinds of vendor-specific extensions [12]. The HostAP framework for Linux [14] allows these changes to be made in a user space daemon, meaning kernel side driver modifications are not needed. We defined a new

The OOB channel is not limited to proximity channels. An interesting example is the use of short message service (SMS) messages. The user interaction would be along the lines of: pick a contact from the address book, select what type of access to grant, and an SMS will be sent to the contact with the admission ticket. Then the contact device would be able to do stages (2) and (3) in Figure 3.

4.

Implementation architecture

Proceedings of the Seventh IEEE International Symposium on Multimedia (ISM05) 0-7695-2489-3/05 $20.00 2005

IEEE

EasySetup IE and used it to advertise the easy setup capability and AP receiving mode (i.e. is it willing to accept unauthenticated clients to join the network) by adding it to Beacon and Probe response frames. 4.2.3. Exchanging key agreement messages We use the Diffie-Hellman key agreement protocol [10] and in particular the OpenSSL implementation. The Diffie-Hellman public parameters, along with linklayer addresses, and random nonces used to protect against replay attacks, are authenticated by calculating a message authentication code using the authentication key. The key design decision is at what point of WLAN link establishment this authenticated key agreement should be executed. In 802.11i, after a client has made an initial message exchange with the AP, the AP opens a port to allow Extensible Authentication Protocol (EAP) messages to be sent from that station to an Authentication server. A new EAP method can thus be added for the execution of the authenticated key agreement. The EAP endpoint could also be collocated with the AP itself as is the case in WPA Personal. There the open EAP port is used to execute the so-called 4-way handshake, where the device being added to the network needs to prove knowledge of the PSK in order to be granted access to the network. The approach we chose was to allow a new EasySetup EAP method prior to the 4-way handshake. This exchange involves the connecting client device presenting the ticket (AK_ID) it received over the OOB channel to the AP and then the AP provisioning the client with the PSK for the network. This PSK is encrypted using a key derived from the Diffie-Hellman shared secret. We kept the number of messages to a minimum, so that no status message is sent from the client to say that it was able to successfully decrypt the PSK. Because this exchange is followed immediately by the 4-way handshake, where the AP challenges the client to prove knowledge of the PSK, there was no need for such a confirmation message. As mentioned before another option here would be for the shared secret to be used to derive a PSK at each end. Table 3 shows the most relevant fields of these EAP messages. ES_AUTHINPUT contains the DiffieHellman public parameter. ES_AUTHNONCE is a random value picked by each party to avoid replay attacks. ES_AUTHCHECK is a message authentication code calculated using AK on the DiffieHellman parameters, nonces, and link-layer addresses. ES_KID is AK_ID as previously described. Table 3: Easy setup EAP message contents
Field Name ES_AUTHMODE Meaning + Allocated size 0/1 unauthenticated/authenticated

ES_AUTHINPUT ES_AUTHNONCE ES_AUTHCHECK

ES_KID ES_KEY

D-H public parameter Random value for use in key derivation MAC(AK, D-H public params. | AUTH NONCEs | BEACON NONCE | linklayer addrs) AK_ID as described Optional: PSK encrypted

The key agreement protocol in Figure 3 can be implemented by exchanging the needed parameters as two EAP EasySetup messages which precede the WPA 4-way handshake as shown in Figure 4.
C lient AP

1. Scan for beacons with ES_ AUTH_MODE=1

2. Beacon ESIE (221): ES_ AUTH_ MODE=1 (auth) ES_ AUTH_NONC NBCN E=

3. G enerates NSTA Assigns ES_KEYID=AK_ ID x Sets ES_AUTH_ INPUT=G mod P C alculates ES_ AUTH_ HEC C K

4. EAP EASY SETUP REQ contains: ES_ AUTH_ NONC NSTA E= x ES_ AUTH_INPUT= G mod P ES_ AUTH_C K=20 bytes HEC ES_ KEYID=20bytes

6. EAP EASY SETUP RESP == ES__ AUTH_ NONC AP E=N y ES_AUTH_ INPUT= G mod P [ES_ AUTH_PROTEC TEDKEY= KES(PSK)] ES_AUTHC K=20bytes HEC 7. C alculates KES [Decrypts PSK]

5. Verifies ES_ KEYID is acceptable Verifies ES_ AUTH_ HEC C K G enerates AK G enerates NAP y Sets EA_AUTH_ INPUT=G mod P C alculates KES from params [Encrypts new/old PSK with KES] C omputes ES_ AUTHC K HEC

Figure 4 Key agreement using 802.11 beacon frames and EasySetup EAP method 4.2.4. Prototype Implementation The Linux access point platform HostAP consists of the kernel WPA driver and user space daemons wpa_supplicant for client devices and hostapd for access points. The modifications needed for the Easy Setup key agreement protocol were limited to these daemons. Both read information about network keys and identities from configuration files and we used these files as the interface between the OOB middleware and HostAP. Changes in the daemons were needed in order to add and react to the EasySetup IE in beacons, load tickets from the configuration file, verify the tickets and to support the packaging and parsing of the EAP EasySetup messages. Our implementation allows the set of fields in the AK_ID to be extended beyond that described in section III C by using a type-length-value approach, meaning more fine-grained categorization of client devices would be possible. Figure 5 shows the resulting implementation architecture.

Proceedings of the Seventh IEEE International Symposium on Multimedia (ISM05) 0-7695-2489-3/05 $20.00 2005

IEEE

WLAN C lient (Linux)

OpenSSl D-H SSID + PSK/AK DB EasySetup OOB MW

w pa_supplicant+easysetup
hostap driver

IR
1. Issue tickets

3. return PSK
hostap driver

2. Use tickets

IR
hostapd+EasySetup MAC+ Psk DB

EasySetup OOB MW

0. Setup AP

OpenSSL D-H Owner keys EasySetup OOB MW

IR

Owner key

Symbian crypto

WLAN AP (Linux)

Introducer (Nokia 6600 phone)

Figure 5 Easy Setup Implementation Architecture

5.

Improvements gained

Our proposed approach preserves the ease of use of the pure OOB approach. In particular, it retains the single-touch user interaction for delegating access from one device to another. The need to type in WEP keys or passphrases is removed and replaced by a simple touch. In our prototype, once a WLAN device has been granted a ticket over the infrared channel, it can enroll to the WLAN network; the typical delay between when a device gets a ticket and when it has successfully enrolled and can use the WLAN is between 5 and 10 seconds. No user interaction is required during this phase. Our approach also provides good security, and can be made compatible with a pure in-band approach by using the same key agreement protocol. In addition to preserving all these advantages, the combined approach also makes it possible to both manage visitor access easily and to add devices to the wireless network.

access management remains the same as in the pure inband case. In the "Network-in-a-Box" proposal [3] by Balfanz et al. a new device is admitted to the network by moving it close to the AP. The two devices exchange hashes of their public keys using their infrared ports as the OOB channel. After that, the new device uses a modified version of EAP-TLS called EAP-PTLS for gaining admission to the network. EAP-PTLS differs from EAP-TLS in that the certificates used are selfsigned certificates. The public keys received in these certificates are checked against the hashes received via the OOB channel. The basic approach requires the new device to interact with the AP via the out-of-band channel. It does not allow device-to-device delegation. A variation, intended for enterprise-scale networks, uses the notion of an enrollment station, which can be compared to our Introducer in that the out-of-band interaction is between the new device and the enrollment station. However, the enrollment station is required to be involved in the subsequent key agreement protocol as well. In contrast, in our unified approach, delegation from the Introducer can happen even when the Introducer is not within network access. Kulkarni and Walker [4] describe a setup procedure involving an out-of-band exchange followed by inband enrollment. They do not discuss visitor access management.

7.
7.1.

Future Extensions
Supporting multiple APs

6.

Related work

There have been some other proposals, which also take the approach of a unified in-band and OOB approach. We briefly outline them here. Atheros JumpStart [7] was motivated by the security problems in the pure in-band approach presented in the Broadcom solution [5]. JumpStart uses Diffie-Hellman key agreement. When the user takes ownership of an AP, the key agreement is done as in the pure in-band approach, but the owner is allowed to choose a password. Thereafter, when new devices are admitted to the network, the password will be used to authenticate the key agreement. A single password is used for all devices, and hence the difficulty of visitor

In a typical home, one AP would probably suffice. But the same Easy Setup discussed here is useful also in public access scenarios, like hotels and restaurants, where there will be multiple APs along with an Authentication Server used with IEEE 802.1X access control (also known as WPA-Enterprise). Instead of agreeing on a PSK with the AP, the Easy Setup procedure should agree on setup information (e.g., a shared secret) with the Authentication Server. Our prototype allows for this possibility in that the tickets can be easily extended to contain a field such as KeyPurpose. Such a field could for instance provide an AP with information that it should take an easy setup request and pass it on to a specified Authentication server.

7.2.

Authentication tokens

Authentication may be based on authentication tokens, instead of authentication keys. In the OOB exchange, the Introducer could receive a hash HND of

Proceedings of the Seventh IEEE International Symposium on Multimedia (ISM05) 0-7695-2489-3/05 $20.00 2005

IEEE

the new devices Diffie-Hellman public parameter, and issue an authentication token (AT) for it as a message authentication code: AT = MAC(AK, AK_ID| HND) In addition, the Introducer will also provide a hash of the APs public parameter. The OOB channel must be bi-directional, since the Introducer needs not only to send AT, but also receive HND in a secure way. The advantage is that since AT is not a key, the OOB channel need not be secret. It is enough for the channel to be merely tamper-evident. In order to securely bind the link-layer addresses to the key agreement, an additional message from the client to the AP is needed. The primary disadvantage of this variation is the need for a bidirectional OOB channel.

[5]

[6]

[7]

[8]

8.

Conclusion

[9]

In this paper, we described the requirements for easy management of visitor access in personal wireless networks, and showed that the current easy setup proposals targeted towards personal wireless networks do not address this aspect. We proposed a new setup procedure that builds on the best features of the current proposals and makes it easy to manage visitor access to wireless networks. In our proposal, selective revocation of some devices can be facilitated by assigning a category to each device at the time of admission. Category information, as well as other information useful for selective revocation is maintained in a central database. We also present the notion of admission tickets, which is a flexible and secure way to delegate access rights. We have prototyped the proposed procedure in the HostAP framework and verified that the goal of single touch delegation of access to wireless networks can be realized with this approach. Our work can be extended to allow easy visitor management in public access scenarios like restaurants and hotels as well.

[10]

[11]

[12]

[13]

[14]

Magazine, November 2004, available at http://www.intel.com/technology/magazine/communicat ions/wi11042.pdf Broadcom, Secure Easy Setup, available at http://www.broadcom.com/press/release.php?id=659800 , January 2005. K. Kostiainen et al, Secure Home Network Made Easy, Unpublished manuscript available from the authors, December 2004. Atheros Communications, JumpStart for Wireless Providing Easy WLAN Setup While Delivering Industry-Leading Security, available at http://www.atheros.com/pt/whitepapers, December 2004 Adam Zawel, Philips NFC Enables Two-Way Wireless Identification and Communication, ZDNet TechUpdate column, available at http://techupdate.zdnet.com/techupdate/stories/main/Phi lips_NFC_Enables.html, July 7, 2004. Microsoft Developer Network, USB Flash Config Tool, available at http://msdn.microsoft.com/library/enus/wcecomm5/html/wce50oriUSBFlashConfigTool.asp, July 2004. W. Diffie and M. E. Hellman, New Directions in Cryptography IEEE Transactions on Information Theory, vol. IT-22, Nov. 1976, pp: 644-654. J. McCune et al, Seeing-Is-Believing: Using Camera Phones for Human-Verifiable Authentication, Proc. IEEE Symposium of Security and Privacy, 2005. IEEE 802.11 Approved minutes of the IEEE P802.11 Full working group, available at http://grouper.ieee.org/groups/802/11/Minutes/Cons_Mi nutes_Jan-2003.pdf, January 2003 IEEE P802.11i/D10.0. Medium Access Control (MAC) Security Enhancements, Amendment 6 to IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 11: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications. April, 2004. J.Malinen, HostAP Driver documentation, available at http://hostap.epitest.fi

9.

References

[1] D. Balfanz et al, Talking to strangers: authentication in ad-hoc wireless networks, Proc. Network and Distributed System Security Symposium; 2002. [2] F. Stajano and R. Anderson, The Resurrecting Duckling: Security Issues for Ad-Hoc Wireless Networks, Proc. 7th International Workshop on Security Protocols, Lecture Notes in Computer Science, Cambridge, UK, 1999. [3] D. Balfanz et al, Network-in-a-Box: How to Set Up a Secure Wireless Network in Under a Minute, Proc. 13th Usenix Security Symposium, 2004, pp 207222. [4] A. Kulkarni and J. Walker, Easy and Secure Setup of Personal Wireless Networks, Technology@Intel

Proceedings of the Seventh IEEE International Symposium on Multimedia (ISM05) 0-7695-2489-3/05 $20.00 2005

IEEE