"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896

---

Contributed by Intel Corporation

Executive Summary

Wireless LAN (WLAN or also known as Wi-Fi*) is a high speed data networking technology that is being widely deployed in residential, enterprise and public areas all around the world. Wi-Fi* brings the Internet to users with mobile computers and/or PDAs and soon even cell phones regardless of where they are - home, corporate campus, or a public hotspot.  However there are many people today who cannot take full advantage of WLAN connectivity because of differences in connection interfaces, security provisioning and authentication methods in private and public network deployments.

This paper describes the market environment and the challenges for deployments in enterprises and public hotspots. It is intended for enterprise IT managers, public WLAN operators and WLAN equipment and software vendors who are involved in planning, deploying or supporting WLAN networks.

This paper addresses key interoperability issues including best practices for Authentication, Authorization and Accounting (AAA), one bill roaming and mobility management. It goes on to provide architectural tenets and guidelines for WLAN network planning and deployments in the focus areas listed above; however deployments in the home are addressed by other industry groups such as the Digital Home Working Group ( http://www.dhwg.org/home_eng/ ). This document is organized as follows:

Section 1 describes Intel’s vision for WLAN seamless roaming and some of the steps involved in reaching that vision in enterprise environments and public hotspots. An overview of the Intel WLAN end to end guidelines is provided along with a summary of the key issues to be addressed: best practices for AAA and data privacy, one-bill roaming, and IP mobility management.

Section 2 focuses on enterprise Wi-Fi* networks. Architectural tenets for enterprise deployment are provided as well as guidelines for enterprise WLAN deployment. These guidelines address authentication and authorization, options for wireless link security, visitor or guest access, VPN compatibility and IP mobility management.

Section 3 outlines a harmonized public WLAN hotspot blueprint, including a model that facilitates the establishment of roaming business relationships among service providers, and a flexible AAA and security framework. It extends the architectural tenets for enterprises to address considerations in planning and deploying public hotspots. A significant new requirement for growth in availability and utility of public WLANs is the ability to offer one-bill roaming. This requires the application of consistent authentication methods and sharing of billing information with business agreements to host visiting users on foreign networks while authenticating and receiving a bill from a familiar and trusted home service provider. In this section we also take a look at the road ahead on issues such as "fast hand-off" between access points within subnets to better support applications like voice over WLAN, mobility management in hotspots and across wireless wide area networks such as cellular. A brief discussion of advanced network and service discovery is also provided in this section

Section 4 summarizes how the framework for enterprise and public hotspot relies on a common set of standards, and through a consistent implementation of these standards, the Intel guidelines enables progress towards seamless roaming.

Finally an annex provides a summary of requirements and recommendations with references to the related standards specifications, a glossary, and other references.

This WLAN end to end deployment guidelines document provides a unique look at what is required from the client to the backend infrastructure to support consistent access of WLANs by clients from and to any network. The tenets and requirements outline an architecture that can support today’s roaming user while paving the way for advancements in wireless access and services. Our goal is to provide an incentive to establish a common approach in the industry and promote three courses of action:

1. WLAN architects and managers adopt the end to end guidelines for planning new network deployments and upgrading existing ones, offering protected access and advanced functionality to WLAN users.

2. Equipment and software vendors support the identified standards in the guidelines as requirements or recommendations to ensure interoperability and market acceptance.

3. The industry joins forces with Intel to promote the adoption of open, IP-based standards for AAA, security, and mobility.

1 Intel vision for WLAN seamless roaming

Wireless LAN (WLAN, also widely referred to as Wi-Fi* and IEEE 802.11) is a high-speed data networking technology that is being widely deployed in residential networks, enterprises, and public areas around the world. WLAN brings to users equipped with a laptop or a PDA wireless connectivity to the Internet and intranet, regardless of location - in the corporate campus or office, in hotspots such as airports, hotels and coffee shops and at home - unleashing new ways to keep in touch with colleagues and family, while promoting freedom and productivity at work [1].

In the public hotspot market, a wide range of operators (cellular carriers, DSL and cable modem providers, dial-up ISPs, wireless ISPs, and corporate data service providers) are fueling rapid deployments, enabling untethered connectivity for business road warriors and consumer users alike. In the enterprise, WLANs are increasingly deployed to meet the connectivity requirements of employees, regardless of location.

Most users, however, are yet unable to take full advantage of WLANs connectivity, as interfaces, security provisions and authentication methods are often substantially different, if not incompatible. In public hotspots, the prevalence of proprietary solutions and interfaces, the inconsistent implementation of standards, the fragmentation in the market, and the limited availability of roaming have created a service that users often find difficult or inconvenient to use. Those who do subscribe to a WLAN service are typically required to use multiple client software applications, to manage multiple subscriptions, and to deal with multiple pricing models. One-bill roaming, the ability for a mobile user to access WLAN hotspots owned and operated by different service providers having roaming agreements with the user’s home service provider, and to get a single bill for the services used, has not yet become a reality. In the enterprise, concerns about over-the-air security, interoperability limitations and lack of a widely adopted common framework have held back the adoption of WLAN.

Most WLANs, both in the enterprise and in the public access market, have been developed as stand alone entities, often relying on ad-hoc or proprietary solutions for security and reliability. As a result, negotiation of access across WLANs managed by different entities, such as enterprises or public hotspot operators, typically requires substantial effort and intervention from the end-user, as well as the use of proxies and other protocol translation capabilities across the network operators’ back-ends.

Intel believes that these are the growing pains of a rapidly adopted technology with a great potential that can and should be addressed today. WLAN holds the promise to realize Intel vision of seamless roaming across private and public WLANs, as well as across WLANs and other wireline and wireless networks. Seamless roaming will enable the user to select the best wireless network available (with minimal or no user intervention) and will offer migration and persistence of IP services across these networks.

The path to seamless roaming will be gradual. Initially, basic roaming across service providers will be a strong driver for market growth as it will make WLAN access available to subscribers at a larger number of locations. Consumers are already familiar with cellular roaming, which has wide coverage, ease of use, and an established billing and settlement system. Intel hopes that this user experience paradigm will extend to Wi-Fi*, to achieve easy access to private and public WLANs and to offer one-bill roaming capabilities across WLANs. This will set the stage for seamless roaming.

To achieve seamless roaming, Wi-Fi* networks need to rely on a common framework and open standards that have been developed by the industry and are supported by industry associations like the Wi-Fi* Alliance. Adoption of open standards will also enable greater ease of use, by laying the foundation for a common but extensible software connectivity framework for mobile clients.

1.1 Intel WLAN end to end guidelines

With the launch of the Intel® CentrinoTM mobile technology platform and Intel® Personal Internet Client Architecture (Intel® PCA), which provide the building blocks for mobile computing devices and smart IP phones, Intel is committed to ensuring broad adoption and use of WLAN technology and mobile applications by consumers, enterprise IT departments, hotspot operators, and service providers.

This document presents Intel’s recommended WLAN end to end guidelines, which will lead towards a harmonized blueprint for enterprise WLANs and public hotspots. The guidelines also specify current and future requirements,

We recommend a prompt implementation of Intel guidelines in enterprise and public Wi-Fi* networks to allow network operators to take advantage of enhanced security and Authentication, Authorization and Accounting (AAA) functionality. These guidelines are also a first step toward advancing the capabilities of WLANs - with features such as Quality of Service (QoS) and multimedia services such as Voice over WLAN (VoWLAN), messaging and gaming. The WLAN end to end guidelines are compatible with the requirements for VoWLAN and other advanced services, but a detailed discussion of how to implement them is beyond the scope of this paper.

The Wi-Fi* Alliance is a key industry forum that certifies interoperable 802.11 products (which are identified by the Wi-Fi CERTIFIED* logo on the products), promotes consistent deployment and use of Wi-Fi* and that educates users on the challenges and the features of Wi-Fi*. The alliance has been instrumental in bringing together different players in the industry, to push for the adoption of new core, standards like Wi-Fi Protected Access* (Wi-Fi Protected Access*) which is crucial to establish a robust security framework for Wi-Fi* and enabling support for advanced services based on open standards. This paper is a tool that provides guidance to Wi-Fi* network managers, vendors and Wi-Fi* service providers that is intended to be complementary to the educational efforts of the Wi-Fi* Alliance.

We expect our guidelines to develop through time, as new technologies become available and new standards are approved. Intel will publish supporting documents as needed that will provide further guidance to the industry and updated requirements for enterprise and public networks.

1.2 Scope

This document provides guidelines for WLAN deployment, addressing the main challenges facing enterprise and service provider networking managers in selecting and deploying an architecture for their WLANs that ensures both confidentiality and ease of use. In particular, it provides guidance on the following issues:

1.  Best practices for AAA & data privacy, including recommendations for migration from solutions broadly deployed today

2.  One-bill roaming across tariffed public WLANs

3.  IP mobility management.

The paper will not discuss specific requirements for WLAN deployments in residential networks as these are discussed elsewhere by the Digital Home Initiative1.

1.3 Document organization

This document presents Intel’s requirements and recommendations for both enterprise and public hotspot WLAN networks deployments.

Section 2 focuses on enterprise Wi-Fi* networks. It includes a discussion of AAA best practices, security, visitor access functionality and IP mobility management.

Section 3 outlines the public WLAN hotspot blueprint. The section describes a model that facilitates the establishment of roaming relationships among service providers, a harmonized AAA and security framework and developments anticipated in the future.

Finally, section 4 shows how the framework for enterprise and hotspot WLANs relies on a common set of standards. It also indicates how, through a consistent implementation of these standards, Intel guidelines will enable progress towards seamless roaming.

The annex includes a list of requirements and recommendations, with reference to standards specifications, a glossary, and references. Current requirements are referenced through the paper by a number preceded by R, future requirements by a number preceded by FR.

For additional information see http://www.intel.com/technology/digitalhome/ and http://www.dhwg.org/home_eng/

1.4 Target audience and focus

This document is targeted at enterprise IT managers, public WLAN operators, and WLAN equipment and software vendors that are involved in the planning, deployment or support of WLAN networks and would like to understand better the end to end challenges the industry faces and the options we have.

Our goal for these guidelines is to provide a reference tool to guide the planning and upgrading of WLANs and a unified blueprint based on a set of open standards which will allow network architects to maximize the benefits of WLAN technology.

This document is neither an introductory tutorial, nor a detailed specification. It assumes familiarity with basic WLAN concepts and introductory documents are referenced where available. It does not list specifications, but identifies the key building blocks for WLAN deployments and points the reader towards the relevant standards specifications.

2 Enterprise Wi-Fi* deployment

Wi-Fi* enables ubiquitous access and mobility across a broad range of locations, including large enterprise campus networks, smaller office suites and multi-tenant buildings. It allows employees to be connected even when they are away from their desk, encouraging flexibility and improving productivity. To take full advantage of the benefits of WLAN, it is crucial that IT administrators carefully consider the architecture of their WLANs during the planning and deployment phases and the implications of their choices on the future expansion and enhancements of their wireless networks.

This section presents key tenets to keep in mind when designing an enterprise’s WLAN network architecture, discusses Intel’s recommendations for robust support for authentication and security, and shows how these guidelines promote advanced capabilities, such as guest access and mobility management.

Our WLAN guidelines focus on the architectural requirements to enable protected and seamless connectivity in Wi-Fi* networks of any size, topology, or traffic requirements. As such, they are compatible with different hardware deployments. For instance, different access point (AP) deployment topologies, such as fat APs, thin APs and hybrid APs are compatible with our recommendations2. While important to the planning of individual networks, a detailed discussion of these issues goes beyond the scope of this paper.

2.1 Architectural tenets

The key architectural principles for enterprise WLAN deployments with respect to AAA and IP mobility that are embodied in these guidelines are:

1. Usability. A consistent framework for network discovery and selection must be supported across different mobile client form factors, leading to a more uniform user experience.

2. Client provisioning. Mobile clients should be able to discover a WLAN and establish a connection using a provisioning framework that can accommodate both pre-authenticated and post-authenticated connections. Furthermore, such provisioning should be possible both offline and in real-time.

2 Fat (or full function) APs support a wide range of WLAN functions, ranging from 802.11 radio management, terminating 802.1X/Wi-Fi Protected Access* authentication, over-the-air encryption, DHCP/DNS proxies and VLAN management. Fat APs may also support more advanced features such as VPN termination, IP routing and tunneling, and NAT and mobility management for inter-AP handoffs. Thin APs are typically Layer 2 bridges that can be remotely configured and managed by an array of interconnected switches or gateways, which manage most of the functions performed by fat APs. Hybrid APs are an intermediate class. The Hybrid APs typically perform RF functions while a centralized controller manages security, traffic isolation, filtering and AP configurations. Some functions may be cooperatively executed such as QoS, where the centralized controller determines QoS policies and APs enforce the policy over the air. The choice of topology will depend on the specific network size and traffic requirements. Fat APs are often the best solution for networks of limited size. Thin and hybrid APs may be better suited to larger deployments.

WLAN End to End Guidelines

Seamless mobility. Mobility across WLAN IP subnets and between wired and wireless networks should require little or no user intervention and the network identity of the client should remain unchanged.

A robust security framework should be in place to protect intellectual property and personal data from malicious attacks.

Mutual authentication to protect user and network. The network and the mobile client should exchange and validate credentials presented to each other. Ultimately, this should be an interlocked, simultaneous exchange. However, in the transition from legacy techniques based on symmetric keys, the network should present its credentials to the mobile client before authenticating the client.

Over-the-air encryption and data origin authenticity. Due to easily accessible Wi-Fi* hardware and the higher incentive to steal valuable corporate information carried on rich mobile clients connecting across these networks, enterprise WLANs are especially susceptible to security vulnerabilities. Robust and scalable solutions should be adopted for over-the-air encryption, to ensure data origin authenticity and to protect against replay attacks.

User traffic segregation. Private enterprise networks operating as hotspots need to shield their own users from all malicious attacks perpetrated by unauthorized guests, authorized guests or insiders.

Mobile clients and AP security capabilities. Devices authorized to use WLANs should be properly equipped with mechanisms to detect and resist active attacks.

Scalability. Incremental deployment should be supported by ensuring maximum reuse of and integration with existing IP infrastructure (e.g. Remote Access Dial-In User Service (RADIUS), firewalls, Virtual Private Networks (VPNs), routing infrastructure, Domain Name Service (DNS) and IP address management).

Safe AP infrastructure sharing. The WLAN infrastructure should be architected to be securely shared across multiple IT domains to support multi-tenant office buildings and other similar situations.

Compatibility with various wireless topologies. From a mobile client perspective, mixed AP configurations (e.g., some combination of fat APs, thin APs or hybrid APs) and technologies (802.11a/b/g) should appear topologically the same.

Incremental feature support. Whenever feasible and permitted by policies, IT managers should be able to incrementally add support for features such as VoWLAN, AP load balancing, fast inter-AP roaming, IP mobility management and QoS, in order to maximize productivity gains and user satisfaction with WLAN use.

2.2 Guidelines for enterprise WLAN

The core of Intel requirements for enterprise Wi-Fi* networks is centered on the use of Wi-Fi CERTIFIED* products and the use of Wi-Fi Protected Access* [2, R04] to provide secure authentication and protected access to the WLAN itself and to enable infrastructure sharing and support for advanced services (r 1). Wi-Fi Protected Access*

Enterprise roaming scenario

Anne is at her desk with her notebook plugged into the corporate LAN and has an Instant Messaging (IM) application open and connected. She decides to send an IM to a colleague with a request to share documents with each other. Anne has a meeting to go to in a conference room, so she continues with the IM session and document sharing, since they relate to the meeting she is going to. She then unplugs her notebook and walks to the conference room and, referencing the shared documents, she sends IM requests to her colleague for clarification when needed. At noon, Anne sits down for lunch at the cafe with her notebook. Because she stays logged into IM, she receives an IM request from a colleague for some quick information required for a critical meeting. Later, Anne returns to her desk, plugs back into her LAN and continues with the same shared document to update with her colleague after the meeting.

With client provisioning and seamless mobility enabled, users are able to move between subnets (i.e. conference room, cafeteria, desk) without having to close down applications or re-authorize their network connection.

A de facto standard branded by the Wi-Fi* Alliance to address the vulnerabilities of Wired Equivalent Privacy (WEP) and offers protected access in enterprise, public and residential networks. It adopts most core security features of the IEEE 802.11i [FR01] draft standard and is now being implemented by vendors across the industry. All products certified by the Wi-Fi* Alliance after September 1, 2003 are required to support Wi-Fi Protected Access*. Although Wi-Fi Protected Access* does not require the use of VPN technologies such as IPSEC, the technology is fully compatible with VPNs.

Wi-Fi Protected Access* is an interim technology that will be superseded by an IEEE 802.11 Task Group i (TGi) specification when it is ratified late 2004. This successor to Wi-Fi Protected Access* will include support for a more powerful encryption scheme, the Advanced Encryption Standard (AES). In the meantime since Wi-Fi Protected Access* addresses all the known WEP vulnerabilities, and already implements the 802.11i security infrastructure., adoption of Wi-Fi Protected Access* is strongly recommended for enterprise WLANs and is a guidelines requirement for new and upgraded deployments. When it does become available, we recommend migrating to 802.11i. 

Intel’s key recommendations for enterprise networks can be summarized as follows:

Authentication and security. Adopt the IEEE 802.1X/Wi-Fi Protected Access* security framework (including Temporal Key Integrity Protocol (TKIP), Protected EAP (PEAP) or Tunneled-TLS (TTLS) and RADIUS [R09]) as basis for user authentication, access control and confidentiality to provide protected access to employees and other authorized users and guests over a shared infrastructure.

VPN compatibility. Wi-Fi Protected Access* provides a high level of over-the-air security within the enterprise. To protect data communications across the Internet, use IPsec or SSL-based VPN tunnels over wired and Wi-Fi* links.

Authentication credentials. Promote adoption of robust authentication tokens, such as X.509 public-key

Outside in scenario

Nicolas has meetings today with clients at a local coffee shop and at a customer’s main office, respectively. In the morning, Nicolas prepares at home by remotely accessing the corporate intranet via his cable modem and WLAN Access Point. Nicolas then closes his notebook and drives to the coffee shop. At the coffee shop, Nicolas opens his notebook, connects to the corporate intranet via the WLAN offered by a Wireless Internet Service Provider (WISP), and proceeds with the client meeting. At the end of the meeting, Nicolas quickly replies to a couple of urgent emails, closes his notebook, drives to his customer’s office and repeats the scenario, except this time he connects to the corporate intranet using the WLAN guest access account provided for visitors at the customer site. When the meeting is completed, Nicolas drives to his campus, where he opens his notebook and connects automatically into the corporate intranet.

The ability to move between private and public WLANs without user intervention will be enabled by standards-based AAA and secure credentials.

1. certificates, while also supporting legacy, symmetric key based methods such as username/password authentication.

2. Usage provisioning. Enable network discovery and automatic or semi-automatic network selection, along with a consistent, easy-to-use user interface.

3. Infrastructure sharing. Introduce IP filtering [R13] and/or virtual LANs (VLANs) [R12] to provide employees and guests with connectivity, to grant and enforce access privileges as appropriate, and to support requirements for applications such as VoWLAN. We also recommend hardening any resources that might be shared by both guest and internal VLANs, such as Dynamic Host Configuration Protocol (DHCP) servers, DNS servers, routers and bridges, printers, etc.

4. Mobility management. Accommodate the need of employees to establish connections with different networks or maintain the same IP connection as they move through the enterprise campus. Virtual LANs can provide IP connection persistence transparent to mobile clients in small and medium business environments where one virtual subnet can be created. Mobile IP (MIP) enables inter-IP subnet mobility for ubiquitous connectivity and reachability across large enterprise WLANs.

2.3 Authentication, authorization and data confidentiality

Since the initial availability of WLAN, authentication, authorization and data confidentiality are the issues attracting the most attention from both industry and academia3 in planning enterprise Wi-Fi* networks. Security vulnerabilities in WEP [3], the initial IEEE security protocol for WLAN, are widely acknowledged and documented. WEP uses static 40-bit or 128-bit keys both for encryption and for access authorization to clients which can be easily compromised. In addition, updating WEP keys requires a substantial effort, as the static keys have to be manually entered and stored in all the APs and all the mobile clients. It is worth noting that compromise of a single device could compromise the security of every device in a shared WLAN.

Aware of these significant WEP limitations, the industry has responded via proprietary solutions that attempt to address the security concerns of its customers. Cisco’s Lightweight Extensible Authentication Protocol (LEAP*) has been the forerunner of robust WLAN authentication and security solutions, by supporting mutual authentication and session re-keying. LEAP* is widely used in enterprise deployments

Today Wi-Fi Protected Access* is the only solution included in Wi-Fi* certification that allows an enterprise to deploy an AAA infrastructure to authenticate users and ensure data confidentiality and integrity over the WLAN. While it is an interim solution, it provides a more comprehensive and robust security solution that addresses the specific requirements of wireless networks. Intel recommends adoption of Wi-Fi Protected Access* in all new WLAN deployments and migration of existing WLANs to Wi-Fi Protected Access* and its core protocols and algorithms wherever possible.

2.3.1 Securing Wi-Fi* with VPN

Because of WEP’s inadequacies with regard to security one approach a number IT groups chose to secure wireless access for their corporate users is the use of VPNs. While VPN solutions provide a high level of security, it comes at a price of expensive VPN gateways, network routing inefficiencies because all the VPN traffic must be routed through the VPN gateways. Also, there is additional overhead for maintenance and support of the VPN gateways. While this may seem less significant since most corporations already have VPNs gateways deployed for remote access, using VPNs for campus WLAN access significantly increases the number of simultaneous VPN users and required ports with a similar increase in cost. Unlike Wi-Fi Protected Access*, VPNs do not enable port-based access control for APs, so VPN-protected WLANs in enterprises are typically deployed outside the firewall, introducing additional wiring and infrastructure management challenges. In short, VPNs do not scale well for internal wireless deployment and use.

VPNs, will continue to be widely used to secure remote access, as they are well suited to protect traffic security outside the corporate firewall in remote access situations such as logging into a corporate intranet from homes or public networks.

For additional information, see The Unofficial 802.11 Security Web Page, http://www.drizzle.com/~aboba/IEEE/

For these reasons, Intel requires the use of Wi-Fi Protected Access* (and eventually 802.11i) for enterprise WLANs and sees declining use of VPNs for this purpose, while noting the complementary use of VPNs for secure remote access.

2.3.2 Securing Wi-Fi* with Wi-Fi Protected Access

The core elements of an enterprise Wi-Fi* network protected with Wi-Fi Protected Access* include:

1. Wi-Fi Protected Access*-Capable Access Points [R01, R02, R03]. Use of Wi-Fi Protected Access*-enabled APs does not preclude or mandate any specific AP configurations.

2. 802.1X/Wi-Fi Protected Access*-Capable Wi-Fi* Clients. 802.1X is a port-based network access control standard designed to provide an authentication framework that can be used for both wired and wireless networks. 802.1X enables mutual authentication, which requires the network to authenticate to the user before the user authenticates to the network.

3. Extensible Authentication Protocol (EAP) Methods. EAP methods, specific to a credential type, are used to authenticate the mobile device or user to the network, and the network to the user. Local IT policies will determine which specific EAP methods are enabled, but some general principles apply to all:

1. a. the authentication mechanism must protect itself from direct cryptanalytic attack

2. b. the solution must afford protection against man-in-the-middle attacks

3. c. the method should derive fresh, i.e., never-before-used, session keys.

4. PEAP [R08] and TTLS [R07]. Almost all legacy symmetric key based authentication protocols fail to satisfy any of (a), (b), or (c) adequately, so we, in general, recommend that they never be used directly. With sufficient care, legacy authentication can be protected by encapsulating such methods using PEAP or TTLS. PEAP and TTLS satisfy (a), (b), and (c), and have been designed explicitly to shield authentication methods from vulnerabilities such as dictionary and man-in-the-middle attacks [4]. PEAP and TTLS do this by first authenticating the network to the mobile client via a digital certificate using the Transport Layer Security (TLS, the standard security mechanism for web pages) protocol. As part of its normal operation, TLS constructs a fresh, randomly generated session key known only to the mobile client and the network. Once this is done, the network and the mobile client use the TLS session key to secure the channel between them, and the mobile client then authenticates to the network using some legacy authentication method inside the secure channel.

There are two caveats to using PEAP or TTLS correctly:

1. a. The enterprise must provision the AAA server’s public key certificate directly on all clients. This is because the threat model applicable to WLAN authentication is different from that for e-commerce. In e-commerce, the TLS server is typically not the network attachment point, so it cannot control all of the traffic exposed to the mobile client. Second, in e-commerce the user typically actively selects the TLS server by clicking on a URL, while a mobile client selects an access point in a more automated fashion, leaving less control to the user. Third, in the e-commerce case it is feasible to cross check the certificate, through a reverse lookup of the TLS server name found in its certificate or by verifying that its IP address matches that of the server, but this is generally not feasible during WLAN access. As a result, a general purpose root certificate cannot provide sufficient security for WLAN access.

2. b. The risk of reusing legacy symmetric key based authentication schemes in different contexts must be considered. For example, many enterprises employ password- or SecurID-based methods for remote access authentication, and would like to use the same mechanisms for in-campus WLAN access. If this is done, the enterprise should evaluate the risk of an attacker masquerading as a remote access AAA server to a user who is trying to connect via WLAN. If the attacker can convince the user that this is genuinely a remote access authentication, then the attacker can launch a successful man-in-the-middle attack, and redirect the user’s authentication to the network to authenticate itself. User education is required to blunt this attack.
    

5. PEAP is likely to be the most widely deployed protocol in the future, given native support in Windows* operating systems, but we note that its use is not required with EAP-TLS (for client certificate-based authentication) as the inner EAP method. A new version of PEAP (version 2) is being developed that includes a fix for man-in-the-middle attacks that are possible when the same credentials are used both inside and outside of PEAP. When this

WLAN End to End Guidelines

1. version of PEAP becomes available, we recommend using it with inner EAP methods that can derive keys (e.g. EAP-MSCHAPv2 [R06], see below). While PEAP may seem redundant when used with EAP methods that inherently offer bilateral authentication and 128+ bit key derivation, PEAP use is still recommended as it enables TLS session reuse that can further minimize handoff latencies across APs [5].

2. RADIUS. RADIUS is the dominant AAA protocol in use across all public and private networks globally. RADIUS servers provide the authentication infrastructure and can be integrated with other critical components of protected intranet access such as domain controllers. RADIUS allows the enterprise to centralize access control decisions. Centralizing the public key operations used by PEAP and TTLS also offloads them from access points, lowering deployment and management costs. The RADIUS servers terminate EAP and generate keys that can be used to secure data over the Wi-Fi* air links between clients and APs. In the future, we expect RADIUS to be natively substituted by DIAMETER [FR02], a successor AAA protocol currently under development by the IETF.

3. TKIP. TKIP provides 802.1X, a per-packet encryption key that enables Wi-Fi Protected Access* to effectively defend against attacks similar to the Fluhrer-Mantin-Shamir attack on WEP [3] and offers per-message integrity protection through Message Integrity Check (MIC). TKIP provides session security after the user has been successfully authenticated and access has been authorized.

During the authentication process, EAP messages are carried over EAPOL (EAP over LAN) frames between the mobile client and the AP and re-encapsulated in RADIUS messages from the AP to the Access Controller (AC) and on to the RADIUS AAA server. IPsec-ESP may be used to secure RADIUS traffic between the Wi-Fi Protected Access* authentication (RADIUS) server and access controllers. Vendors should also use encrypted channels to protect transfer of keys between APs and access controllers.

There are several EAP-based authentication methods. We recommend EAP-TLS [R05] for X.509 certificates and EAP-MSCHAPv2 [6] for passwords. PEAP (especially version 2 when it becomes available) should be used with EAP-MSCHAPv2 and other inner EAP methods to establish a protected channel for authentication, but it is not required with EAP-TLS (Table 1)

Table 1. Enterprise authentication types

2.4 Usage provisioning

Discovery and selection of available WLAN networks (i.e., Service Set Identifiers, SSIDs) by mobile clients is generally straightforward in enterprise WLANs where the network is exclusively owned and operated by a single corporate IT department. Authorized guest access and shared infrastructure (see sections below) may complicate the usage provisioning as mobile clients may need to select a network among several available. To address issues that may arise in the discovery and selection of available networks, Intel recommends that IT administrators audit and deploy solutions which enable integration of domain authentication, remote access and enterprise WLAN access back-ends, leading to a more uniform access experience to the end user. As an initial step, IT administrators should promote the use of WLAN profile management software on mobile clients, to provide users with information about available networks and to shorten the time needed to select and negotiate connections and switching between WLANs and other wireless networks. Intel supports the development of open standards for client provisioning, fostered by the Wi-Fi* Alliance, with strong industry-wide support to ensure wide adoption of these advanced services.

2.5 Validated visitor access

Visitors, such as consultants, contractors or clients, can be granted guest Internet access over the shared Wi-Fi* access network, either with or without validation. Guest access is a service that is quickly expanding in popularity, as guests have grown accustomed to wireless connectivity in their office or public hotspots and need Internet and intranet access when working on their client or business partner’s premises.

2.5.1 Guest access without validation

Restricted usage without credentials is possible only by segregating unauthenticated guests from authenticated users. To support these different classes, we recommend the use of separate physical LANs or VLANs, each with its own assigned SSID. We recommend that all authenticated users rely on Wi-Fi Protected Access*, and to use an open network for unauthenticated users who may then employ services such as a VPN to remotely and securely access their

Symmetric key based authentication

Symmetric key based authentication methods can expose security vulnerabilities which arise from the need for third-party key establishment. With symmetric keys, each session key established between the mobile client and the authentication server must be shared directly and uniquely by the authentication server with the AP the mobile client associates with. Transfer of session keys hop-by-hop from the authentication server to an AP exposes the key to man-in-the-middle attacks. Intel therefore believes that the long term solution is one based on asymmetric (private-public) keys and in the interim appropriate measures should be taken (such as managed secure tunnels between key management entities and auditable infrastructure) to minimize or mitigate attacks on symmetric key based deployments.

2.5.2 Validated guest access

Validated guest access provides a way to limit and control who gains access to the network, and to offer different access rights to different guests. Each visitor with access rights is granted a limited use certificate (e.g. X.509) or password which is validated by the RADIUS server. The IT department will have to create guest user accounts if using password-based authentication. It is possible to avoid this step if the IT department already possesses and has validated the signing certificate of the organization sponsoring the guest.

If user databases are maintained across distributed RADIUS servers, then a RADIUS proxy may be used to route authentication requests and responses between APs and the appropriate bank of RADIUS servers.

Segregation of user traffic for different classes of services may be accomplished in one of two ways:

1. Use parallel WLANs or VLANs with different SSIDs.

2. Use stringent filtering rules over a shared-SSID based WLAN, using EAP to authenticate clients.

2.6 Mobility management

WLAN enables mobility across the enterprise intranet. When policy permits, employees should be able to move from one campus location to another without the need to manually select the network or to re-authenticate. Subnet mobility and quick handoffs enable the network to offer advanced enterprise solutions (e.g. continuous instant messaging availability, online inventory) and VoWLAN. AP sharing enables further functionality by making multiple networks available to users at the same location. To provision such services it is necessary to adopt a mobility management framework, which we outline in the sections below.

2.6.1 Sharing APs across IT domains

In some situations, such as in large office complexes, tenants may be allowed or required to share a single WLAN infrastructure deployed by the property owner. Enterprises need to carefully evaluate the specific requirements for AP configuration, management of user access privileges, and secure partitioning of user traffic belonging to different administrative domains that shared infrastructure entails.

In many cases, infrastructure sharing will involve public access as well as enterprise access. For example, enterprises may offer access to their guests through independent service providers (SPs) which will manage the public network and charge users. Similarly, hotspot locations, such as airports, may also offer WLAN access to their tenants (e.g. airlines, police, and concessions) over the same network as they offer public access services. The enterprise IT administrator must carefully manage guest credentials and the RADIUS back-end when Wi-Fi Protected Access* is used to grant partitioned access.

There are two core aspects that need to be addressed when deploying a solution for shared infrastructure use:

1. Network Discovery. Effective management of SSIDs and Basic Service Set Identification (BSSID) to support multiple, secure connectivity domains [R10] is essential to allow mobile clients to discover available networks. One SSID is needed to support each domain, but that can be achieved using different solutions. Table 2 below summarizes different ways in which APs can support multiple SSIDs, and Intel’s recommendations for AP vendors. Appropriately partitioned AAA proxies and local AAA servers are required as well.

2. Traffic Segmentation. An often-used client-agnostic approach to AP sharing across different IT domains is via the use of multiple VLANs with per-client VLAN tags. VLAN tags are assigned by the RADIUS AAA server as part of the authentication process, using the RADIUS ACCEPT message. Another possibility is to associate pre-

4 Since Wi-Fi Protected Access* protects all data packets, all broadcast packets are encrypted. And no broadcast packets are encrypted in an open network, because no party has an encryption key. This requires two separate and separate functional entities: one for the Wi-Fi Protected Access* protected WLAN and another for the open WLAN. These wireless networks may be implemented by physically distinct APs or by virtual access points implemented on the same physical access points.

1. Configured one-to-one VLAN tags with 802.11 SSIDs. VLAN technology can provide additional flexibility to the deployment of WLANs, because it can be used to provide logical isolation of traffic sent through common WLAN APs. The partitioning can be employed to support flexible charging or service provisioning when needed, enable infrastructure sharing among carriers, and to separate private WLAN connections from public access traffic. Intel recommends support for VLANs for those who choose to provide shared use of APs.

AP Configuration Description	Comments	Intel’s Recommendation
AP setup for 1 BSSID and 1 beacon type. However each beacon and probe response contains 2 or more SSID Information Elements (IE).	Most client Media Access Control (MAC) implementations are incapable of parsing such advertisements. Configuration does not allow easy support for different or multiple capability sets for each SSID.	Do not support.
AP setup for 1 BSSID but multiple beacons (1 SSID as IE per beacon). AP generates 1 probe response for each supported SSID.	Current MAC client implementations might purge all but the last advertisement. Configuration can support different capability sets per SSIDs but not multiple capability sets for any particular SSID.	Do not support.
AP setup for 1 BSSID and 1 beacon type, with 1 SSID IE. Default probe responses are for primary SSID. Clients may probe for hidden, secondary SSIDs.	Can be supported by current client MAC implementations. Configuration can support different capability sets per SSIDs but not multiple capability sets for any particular SSID. This approach requires client pre-configuration with secondary SSIDs which may limit discovery capabilities.	Recommended as the most practical solution to today’s needs, as it is supported by many AP vendors. Lack of scalability limits impact that this solution will have in the long term.
Virtual AP, with each AP hosting 2 or more independently functioning APs. Each AP in turn supports 1 BSSID with 1 SSID IE.	This configuration allows discovery of multiple SSIDs with different capability sets for each SSID and multiple capability sets for any particular SSID.	Recommended as a long term solution. While not yet widely supported, it provides the most flexible longer term solution.

Table 2. Configuration options for secure AP infrastructure sharing

2.6.2 Inter-AP, intra-IP subnet mobility

The initial step towards fast and seamless mobility management across APs is to establish subnet mobility within a single administrative domain. Intel’s requirements and recommendations for mobility management are:

1. Application adaptation. Employees will expect that, as they move through their IP domain, applications will remain active, even through the occasional loss of connectivity. New Transmission Control Protocol (TCP) applications are designed to be mobility aware. When connectivity dead spots are detected, such applications gracefully terminate any on-going TCP connections to avoid the user perception of a system hang. Applications are also being designed to take advantage of finer grained network connectivity information and adapt to varying

2. network characteristics such as bandwidth and QoS. We encourage ASPs to take advantage of such primitives when available in operating systems, for both new and existing applications.

3. Fast inter-AP 802.11 handoff. Roaming across APs contributes significantly to the end-to-end latency for authentication. One of the biggest factors is AP authentication and access control based on the Wi-Fi Protected Access* framework. Intel expects one or both of the recently formed IEEE study groups, 802 Handoff and 802.11 Fast Roaming, to be approved and that the combination of these IEEE groups with the efforts of SEAMOBY and PANA working groups in the IETF will lead to a harmonized framework for faster inter-AP handoffs.

4. VPN auto launch and hands-free authentication. In situations where the Wi-Fi* network is protected from the rest of the corporate intranet using VPNs, it is highly desirable to be able to automatically launch a VPN tunnel without user intervention, either after recovering from a brief period of no connectivity or due to a previous tunnel tear-down caused by an IP subnet change.

2.6.3 Inter-AP, inter-IP subnet mobility

Inter-IP subnet mobility is the second step to provide full mobility management. In addition to addressing requirements listed above we recommend adoption of Mobile IP (MIP) [FR05, FR06] coupled with Wi-Fi Protected Access* to enable seamless IP handoffs and continuous connectivity across multiple networks. MIP provides key features such as seamless mobility support for any IP-based communications applications and consistent reach ability for the client as people move from network to network.

MIP can now seamlessly support Network Address Translation (NAT) Traversal and effort is also underway in the IETF to develop a mobile VPN solution for VPN-enabled enterprise WLANs. The framework for mobile VPN minimizes deployment barriers by enabling reuse of existing router and VPN infrastructure. The solution, referred to as Dual-Home Agent (HA) mobile VPN involves the use of two mobile IP Home Agents (HA). One of the HAs is deployed inside the firewall to extend access to clients roaming outside the wired intranet. The second HA provides mobile IP services inside the intranet. The dual HA solution is based on dynamic VPN tunnels that allow mobile IP services to be seamlessly maintained across firewall transitions even as client VPN tunnels are torn down and re-established [7].

3 Public hotspot Wi-Fi* deployments

Deployment of public WLAN hotspots [8], initiated by a diverse set of incumbent operators, cellular carriers (GSM and CDMA), Wireless Internet Service Providers (WISPs), dial-up aggregators, and fixed broadband operators, is rapidly taking place across the globe [9]. The expected rate of deployment of WLAN technologies is impressive. The analyst firm Gartner predicts that by the year 2008 there will be more than 167 thousand public WLAN hotspots around the globe and over 75 million users worldwide [10].

WLAN offers a great opportunity for the subscribers to gain wireless high-speed access while on the go and for service providers to stimulate growth in the wireless data market. To gain acceptance among the subscribers, a public WLAN service needs to meet two key requirements:

1. Consistent coverage. Hotspots have to be in easily identifiable locations and in sufficient number to enable users to quickly locate a hotspot in urban areas and in some key locations, like airports, major hotels and conference centers.

2. Easy access. The service has to be easy to use and not require users to enter lengthy information, such as credit card numbers, every time they want to establish a connection.

The current WLAN market for public access is characterized by fragmentation among operators and the coexistence of different business models. Such deployment of WLAN infrastructure does not encourage users to subscribe for a service that is often available at a very limited number of locations. Business users who need connectivity while traveling often end up with a high number of subscriptions to manage. At the same time, it is unlikely that a single provider will emerge as the dominant one, controlling a large portion of the hotspots within a country.

A common, widely accepted roaming framework, that will allow users to get access in hotspots managed by different operators while having all the charges combined on the same bill is the necessary to address this issues. Currently available AAA standard-based solutions make it possible to implement a common roaming framework that can be integrated with the billing systems used by a wide range of service providers.

Intel guidelines provide a blueprint for public hotspot deployments, based on a robust security framework, that facilitates adoption of service among potential customers, and that supports a one-bill roaming model which will simplify the establishment of roaming agreements among service providers.

In the remainder of this section, we describe the AAA framework most commonly adopted today, discuss architectural tenets that should guide hotspot deployment, present our blueprint for hotspots, which includes a roaming model and a security framework, and discuss further developments that will enable hotspots to offer more advanced services.

3.1 The state of WLAN deployment today

A long day scenario.

A few years from now, Rebecca works for a large technology firm. While at work, she enjoys free access to the company’s wireless LAN. After work, she leaves the office and begins travelling home. Her PDA remains on, however, and as it sits in her briefcase, it connects with the cellular network and begins downloading relevant information from the web to update her system - as well as downloading a new presentation that came her way just after she left the office. As she pulls into her garage, the PDA finds and connects with her home wireless network, updating her personal devices with the calendaring information that was modified throughout the day. Later, she decides she’d like to do some work, but in a more social environment. Rebecca takes her laptop, turns it on and begins to drive to a local coffee shop. As she drives, her machine connects with the cellular network and downloads several new documents that have been mailed to her. When she arrives at the coffee shop, her machine invisibly shifts from its cellular connection, to the higher bandwidth wireless LAN connection at the shop. She sits down, orders a latte, opens her laptop, sees the new documents, and immediately begins mailing her feedback and input to the document authors.

All of these interactions, though utilizing a number of devices on different networks, will be represented as one "identity" online and Rebecca will receive a single consolidated bill for all of these services.

According to the Wi-Fi* Alliance [11], the most prevalent form of access today is based on the e-commerce model and is referred to as the Universal Access Method (UAM) [R11]. In the UAM sign-on usage model, the hotspot intercepts and redirects the user’s web browser to a local web server secured by TLS. The user’s identity is authenticated to the UAM login page typically by entering a username and password on a form sent to the web server. Ease of deployment and the minimal requirements on mobile clients (only web browser support is needed to gain access) have been the major strengths of UAM.

Despite these advantages, UAM has serious drawbacks. User experience is one problem. To obtain network access, the user needs to launch the browser to enter authentication credentials. This step is not intuitive if the user wants to simply use a mail client. Enterprise users frequently have VPN policy settings that do not allow them to access a local web server. More seriously, most of the UAM implementations expose the user’s credentials (username and password, and often credit card information) to the visited network’s web server. This is an unacceptable feature for carriers that do not wish to expose subscriber databases, even to legitimate roaming partners. Furthermore, unless the user manually inspects the certificate used by the server to secure the web pages (which is rarely done), these credentials may be unwittingly disclosed to an attacker operating a rogue wireless AP. Vulnerability to session redirection has proven to be a real problem in UAM deployments today.

UAM security limitations can be overcome by using Wi-Fi Protected Access*. Wi-Fi CERTIFIED* products with Wi-Fi Protected Access* protect the client and the network by using IEEE 802.1X authentication to mutually authenticate the AP and mobile client and provides security through encryption with TKIP. Section 3.5.1. provides a comprehensive overview of Wi-Fi Protected Access* advantages in public hotspot environments.

3.2 Architectural tenets

The hotspot guidelines proposed in this paper are based on the following principles:

1. Usability. The client should be able to gain access to hotspot services based on user and operator policies, independently of the specific details of the hotspot implementation.

2. Simplified client provisioning. Users should be presented with a consistent AAA interface, regardless of location or network operator, which is intuitive to use, while providing service information to more experienced users. The sign-on experience should be independent of, or agnostic to, variations in network back-ends.

3. Common login. Different authentication credentials from different service providers should be accepted and the user should be authenticated directly with the home service provider with common AAA mechanisms.

4. One-bill roaming. A roaming infrastructure should allow users to get connected at hotspots managed by different operators, while being authenticated by their home service provider and charged for aggregate use on a single bill.

5. Security. Both users and network operators should receive a high level of assurance throughout each session.

6. Mutual authentication to protect user and network. The client should be allowed to verify the AP and/or network credentials before divulging its own.

7. Secure tunnels for back-end authentication. The visited network operator should not require disclosure of authentication credentials, to preserve confidentiality of account information. Only the home service provider should have access to clients’ credentials.

8. Support VPN for remote enterprise access. Hotspots should provide compatibility with VPN tunneling for corporate users during connections from public hotspots.

9. Scalability. The recommended framework should provide a blueprint for independent hotspots and hotspot networks of different sizes.

10. Accommodate various wireless topologies. The network topology should be planned on the basis of the local network requirements for access and backhaul that can accommodate the best wireless technology.

11. Ability to share infrastructure safely. Different network operators and service providers should be able to use the same WLAN infrastructure and to segregate internal business traffic from commercial traffic.

12. Support advanced services efficiently. Hotspot networks should be planned to support advanced services when they will become available.

13. Unified accounting framework. Hotspot operators and service providers need to support flexible billing models, which include prepaid and postpaid roaming, pay-for-use and contract plans (either flat-fee or with limited usage). Data and financial clearinghouses and AAA aggregators and intermediaries may facilitate the establishment and management of roaming partnerships.

3.3 Intel guidelines for public hotspots

As in enterprise WLANs, the key element in Intel’s blueprint is the adoption of Wi-Fi Protected Access*. WLAN hotspots are essentially 802.11-based IP networks and, as such, we strongly subscribe to the use of core protocols developed in the IEEE (such as 802.1X) and IETF. This eliminates the need for proprietary or domain-specific protocols to be used over the WLAN interface and facilitates the establishment of a consistent user experience across service providers and the development of a roaming infrastructure.

Intel’s proposed hotspot blueprint relies on Wi-Fi Protected Access*, RADIUS and PEAP with standardized EAP-based authentication methods such as MS-CHAP and EAP-SIM to support roaming across a wide variety of home operators (WISP, cellular, fixed operator). As a prerequisite of roaming, AAA signaling between the hotspot and the different back-end authentication systems of different operators must be fully compatible.

Intel key recommendations for operators of public hotspot and service providers include:

1. Wi-Fi Protected Access* should be adopted as soon as feasible to provide mutual authentication with the home SP and session security.

2. The framework must accommodate older UAM authentication models while providing coexistence and longer-term migration to more robust schemes based on Wi-Fi Protected Access*/802.1X.

3. Preserve support for VPN users to support the large number of remote corporate users who use VPN to access their intranet from public networks. In particular, care must be taken to ensure that NAT functionality does not adversely affect VPN, by implementing features defined in RFC 3022 [R14].

4. If integration of services requires interworking with another network (such as a cellular operator’s core data network), we strongly advocate a loose coupling between the WLAN hotspot and core network. In other words, WLANs should be seen as standalone networks based on IEEE and IETF core protocols as opposed to radio access networks, and should not require the use of domain-specific mobility management protocols over the client’s WLAN interface (for example, GPRS Mobility Management or GMM). This helps harmonize the interfaces of different WLAN networks (both public hotspots and enterprise networks) and promotes roaming interoperability for clients. Convergence on IP protocols will result in more uniform support of advanced services among different wireless technologies.

5. Key distribution between home providers and visited networks for wireless link layer encryption should be secured and cryptographically bound to authentication and session information. Use of IPsec tunnels between RADIUS servers managed by roaming peers is recommended.

6. • Backhaul requirements should be determined on the basis of actual or expected traffic. However, we recommend at minimum a broadband connection (e.g. DSL, cable modem, or T1/E1) be present at all hotspots.

7. • An industry-standard approach to AAA should be adopted to facilitate the establishment of roaming agreements [12, 13]. This allows service providers to extend the availability of WLAN services beyond their own infrastructure and enhance their own footprint with that of their roaming partners.

3.4 Architectural considerations for one-bill roaming

Availability of roaming among different service providers at public hotspots is key to attracting more customers for WLAN services. Setting up roaming agreements, however, is time consuming and expensive because a large number of players with different business models and different protocol and system legacies need to seamlessly work together to offer smooth AAA and consistent service.

At a minimum a roaming relationship involves a home service provider (e.g., fixed or cellular operator, or a WISP) and a hotspot operator (which may be also a service provider). The hotspot operator needs to provide the subscriber with a quick and easy way to obtain connectivity, transfer the authentication credentials to the service provider, collect all the billing information for authorized users and transmit the billing information to the home provider or a data clearing house for settlement. The home provider authenticates the users against its subscribers’ database, authorizes access and later bills the subscriber.

This basic framework is complicated by the fragmentation of the public hotspot market and the need to provide wide coverage to the user. To be able to offer a wide domestic and international footprint to the user, a service provider would need to enter bilateral roaming agreements with a large number of hotspot operators. This is a time-consuming process that requires considerable effort.

To simplify the establishment of roaming relationships, the adoption of open standards discussed above is the first crucial step. Intermediaries may streamline the process by providing aggregation of service, data clearing and financial settlement. These services effectively allow the hotspot operator to have a wholesale roaming relationship with a wide number of SPs and enable SPs to increase their footprint without having to negotiate individual deals with hotspot operators. 

Global traveler scenario

Erika is visiting Portland on business from Sweden. Erika’s notebook configuration has a GPRS PC card, using a SIM from her own Swedish GPRS operator. During her visit, Erika connects to her corporate intranet back in Sweden at different times and places using her GPRS connection with a VPN. She also connects to public WLANs that have roaming arrangements with her home GPRS operator that allows automated sign-on using her GSM SIM card. All of Erika’s data usage shows up on her next month’s bill from her home GPRS operator.

Standards-based AAA implementations allow users the flexibility to use wireless networks anytime, anywhere.

1. The Mobile Client represents the user’s equipment (typically a laptop computer, cell phone, or PDA) that is used to access the 802.11 network.

2. The 802.11 Access Point terminates the air (radio) interface to and from the mobile client.

3. The Access Controller is the entity that verifies authorization and enforces access control for authenticated users and segregates traffic of non-authenticated (guest) users.

4. The Visited Network AAA Server (AAA-V) serves as an AAA proxy for inbound roaming customers.

5. The Home Provider AAA Server (AAA-H) serves as the RADIUS server authenticating the mobile client user. User credentials are disclosed only to the AAA-H. The home SP and visited network operator AAA servers also participate in transactions involving the reconciliation of billing and settlement records—both online and offline— and done either mutually, or via an intermediate settlement entity.

6. The Web Server is an optional component that could serve one or more of the following functions: browser-based login portal, local value-added services portal for guests and authenticated users, portal for new subscriptions, and redirector for other services.

7. The Roaming Intermediary (INT) represents a wide variety of AAA and billing intermediaries which provide translations of RADIUS billing records into other formats and can be a key element in resolving legacy issues. The INT function can be served by a Data Clearing House (DCH). DCHs connect via a chain of RADIUS/AAA proxy intermediaries to one or more hotspots and is responsible for charging, billing, and settlement with diverse back-ends, using protocols such as RADIUS, TAP, CIBER, and IPDR  INT functions performed by DCHs might include AAA aggregation, wholesale hotspot service aggregation, and AAA data and financial settlement. They are typically implemented across multiple physical components. In addition, to the conversion among different record formats, DCHs can provide other value-added services such as rating and fraud detection.

Roaming by definition requires the home SP to offer service using the infrastructure of another operator, but the home SP does not have good visibility into the operational status of another provider’s network. As advanced services like QoS are implemented and offered, there is a requirement for common agreement between SPs on policies for network service levels and network performance information.

3.4.1 Billing records and usage metrics

The framework presented here is compatible with several billing models available to users including prepaid, pay-for-use, and postpaid (subscription-based) models likely to be the most common. Charging metrics could be based on fixed or flat rates, on usage (time, volume and/or number of connections) or specific services used. Regardless of the billing model, roaming users should be able to connect to a visited network as they do when they connect to their home network. Ideally, charges associated with WLAN roaming usage would appear in an integrated single bill as is the case for cellular voice roaming today.

Billing metrics and formats across operators vary today, and there are no agreed upon standards in the industry. The SP billing metrics (e.g., number of connections, flat fee, time metered, volume metered) often depend on how the SP bundles WLAN access with other services it offers. For example, a cellular operator may be more inclined to charge by the minute while an ISP might prefer per-connection charges. The establishment of an industry wide standard for billing formats should support legacy systems which are needed for billing other services offered and to minimize the incremental investment to deploy.

Until a prevailing metric or a billing format emerges, the best path to maximize flexibility for service providers and to facilitate integration with different backend systems is to rely on RADIUS records as the common protocol for WLAN services, with clearinghouses or other intermediaries translating RADIUS records into formats that are compatible with the service providers billing systems, when necessary. To support different pricing models, all the available data should be collected into detailed usage records , This will allow service providers (and by extension intermediaries and network operators) to charge on their preferred basis, including length of connection, traffic volume, in addition to flat-fee and per-connection charges. In the cases where the SPs charge on a different basis, the proper billing information can be derived from the detailed usage records because they have the complete accounting data for a billed session.

3.5 Authentication and security

3.5.1 Wi-Fi Protected Access*: A better framework for authentication

The documented security vulnerabilities of the initial 802.11 security standard, WEP, and the need to communicate the keys to the client before establishing a connection, have resulted in wide use of UAM. UAM typically provides the initial authentication, while leaving the user responsible for session security. This approach typically translates into use of VPN among remote corporate users, and no security for those users that do not have VPN at their disposal.

Leaving security as a responsibility for the user drastically limits the options available, as the most effective solutions involve the adoption of the same standards on both the client side and the hotspot infrastructure. A robust security framework relies on a joint effort of service providers, network operators and hardware manufactures to comply with a unified set of standards.

The convergence on the same AAA and security standards in the public hotspot networks is even more important than in enterprise networks as many more players are involved, and users are expected to use multiple networks managed by different operators, in addition to their enterprise and residential networks.

Wi-Fi Protected Access* provides much needed improvement over UAM in addressing security concerns while offering compatibility with more advanced services. As an added advantage, WPA* provides a common solution that can be implemented in enterprise and residential networks as well public access networks. Wi-Fi Protected Access* provides a mobile client framework for consistency in network discovery, selection and authentication, which paves the way for seamless roaming across different types of WLAN networks.

In a public hotspot network, Wi-Fi Protected Access* core elements are the same as for enterprise networks (see section 2.3.2):

1. TKIP to generate dynamic per-user encryption keys.

2. 802.1X to provide the authentication framework

3. EAP methods to perform mutual authentication

4. RADIUS to offer AAA functionality

5. PEAP or TTLS to secure EAP-based authentication methods

Wi-Fi Protected Access* and VPNs can work together to provide robust authentication and session protection for public wireless access. Wi-Fi Protected Access* offers a more comprehensive wireless security solution, which includes mutual authentication and dynamic encryption keys.VPNs are still needed for session protection when accessing enterprise intranets from public networks and as such compatibility with Wi-Fi Protected Access* is required to ensure wide adoption of WLAN services among business users.

Wi-Fi Protected Access* implementation in public hotspots has to satisfy specific requirements, which arise from the need to share AAA messages among different partners and to preserve confidentiality along the authentication path. 802.1X provides this functionality as it supports extensible end-to-end authentication between the mobile client and the home provider’s AAA-H. When the EAP channel is established between the mobile client and the AAA-H, there is no need for the visited network’s AP, AC, or AAA-V to support the specific EAP method or credential types used by the home provider. This feature provides great flexibility to the client and service providers. With the use of PEAP or TTLS tunneling, the information transmitted to the AAA-H remains confidential to the home provider, thus allowing the establishment of roaming relationships that do not require the home provider to disclose subscriber information to the visited network operator.

With PEAP, common session key derivation, distribution, and configuration solutions can be defined for a variety of credential types, including certificates, usernames/passwords, and SIM cards. Industry agreement over acceptable credential types and most suitable authentication methods will make it easier for cellular carriers and network operators to support a variety of roaming scenarios across different network types. PEAP and TKIP provide valuable support for interoperability and roaming, as it addresses the 3GPP user security requirements defined in TR 22.934, Release 6 [15,

16]. Alternatives such as TTLS, which has similar functionality, can also be used without significantly sacrificing interoperability, because of the end-to-end properties of EAP. However, PEAP is likely to be more widely deployed on client platforms due to native operating system integration.

EAP-SIM [FR04] is an authentication method which has a special relevance for public hotspots, as it allows a SIM-card based user authentication across WLAN and GPRS/EGPRS wireless networks (a method known as EAP Authentication and Key Agreement (EAP-AKA) [FR03] offers a similar solution for USIM cards used in 3G-WCDMA networks). In EAP-SIM, the GPRS/EGPRS SIM authentication parameters are exchanged in the EAP messages with added mutual authentication that improves upon GSM security. This mechanism allows re-use of GSM and GPRS/EGPRS SIM cards and preserves cellular service providers’ infrastructure elements like the Home Location Register (HLR). The use of PEAP with EAP-SIM and other EAP methods allow for a consistent level of security, independent of the EAP method and providing strong keying material and mutual authentication, data origin authentication, session encryption, dynamic key distribution (through RADIUS) between the EAP Client, NAS (network access server) and the EAP server. The visited network only needs an 802.1X-compliant authentication framework to offer EAP-SIM to roaming partners, which will then authenticate the user against their HLR. The EAP-SIM method can be developed using the Microsoft* EAP framework.

3.5.2 Wi-Fi Protected Access* as a defense against security threats

Security is a major concern in deploying WLANs, particularly for enterprise applications. It is important to understand that the threats associated with network impersonation on a WLAN are substantially worse than with most other networks. With wired networks the user’s direct connection to the network has at least some level of implied authenticity by virtue of physical wires, virtual circuits (e.g., ATM virtual circuits) or physical circuits (e.g., dial-up). In a WLAN, there is no such first line of defense. Unless robust mechanisms to authenticate the network are employed, the user is highly vulnerable to man-in-the-middle or rogue access point attacks on the wireless link. The sensitivity and the value of data stored on many WLAN client devices such as laptops, and the high bandwidth of WLANs offer a significant incentive to attackers.

Because of these concerns, it is crucial to adopt a security framework that effectively addresses these concerns. Wi-Fi Protected Access* offers a compelling solution to these challenges. Wi-Fi Protected Access*’s defense against rogue APs provides a good example. A rogue AP has complete control over the channel of information flow and can perform a wide variety of attacks including eavesdropping, message insertion, message modification, DNS-based attacks, etc. Link-level encryption does not protect against this class of attacks if the attacker is one of the endpoints of the encrypted channel.

There are two basic strategies to defend against rogue AP attacks. One is to tunnel all traffic using a VPN client and a client-hosted firewall. If executed properly, this defense limits the rogue AP to denial-of-service attacks. However, the VPN approach requires a VPN infrastructure in the network and on the client, plus robust configuration of the client firewall. These are non-trivial requirements. Wi-Fi Protected Access* provides an alternative strategy which is both more powerful and more easily deployable. With mutual authentication, the client is required to authenticate the network so the client has confidence in the network it is connecting to. This also enables the client to refuse a connection to a rogue AP when it does not recognize the network identity. Note that the latter approach is only effective if subsequent use of the connection is cryptographically bound to the initial network authentication.

3.5.3 Migration to Wi-Fi Protected Access*

Although we require adoption of Wi-Fi Protected Access* in conjunction with 802.1X, we also recognize that until 802.1X-capable clients are widely deployed, there will be a market requirement to support the legacy UAM. Furthermore, even when 802.1X is used, browser redirection can be useful to help resolve authentication failures and to permit the establishment of new accounts. Therefore, the recommended hotspot AAA framework supports the coexistence of UAM and 802.1 X-based authentication in one hotspot.

To support both 802.1X and UAM, each AP supports two different SSIDs, one corresponding to 802.1X and one to UAM. With current AP hardware, only one of these SSIDs associated with the Wi-Fi Protected Access* VLAN can be advertised by the AP, but the other SSID for the UAM VLAN could be discovered via the 802.11 probe request/response mechanism. When APs with full VLAN support become available, both SSIDs can be broadcast on different beacons. The open SSID, associated with UAM-based access, would not require any link-layer security, but the authentication controller (AC) would limit user access to the local web server until the user obtains authorization to use the network. Subsequent enforcement of access control for the UAM method is likely to be based on the client’s MAC address, which is not very robust. Attackers can easily configure their own equipment with the same MAC address and masquerade as legitimate users, stealing their bandwidth. This is one business incentive for network providers to migrate users away from the UAM as soon as possible.

In the Wi-Fi Protected Access* configuration with UAM support, the AP assigns separate VLAN tags to packets according to the SSID the mobile client associates with. The VLAN switch in turn routes the packets during authentication so that the 802.1X traffic gets sent to the local AAA server/proxy for local authentication or proxied to the home AAA server for home network authentication, and the browser redirection mechanism is used for the non-802.1X clients. 

Other coexistence models are possible, but not recommended. For example, traffic from the 802.1X clients and browser redirection clients can be mixed and the need for the VLAN switch eliminated, with the Access Controller managing both types of clients. 

3.6 The road ahead

Public WLAN services were only recently introduced by major operators and are still in their developing phase. We expect rapid evolution of public hotspot network requirements to support advanced usage models and services. In the remainder of the section we explore areas in which we believe there is greater scope for innovation.

3.6.1 Fast and seamless inter-access point handoffs

Current WLAN access at hotspots is often limited to a single AP present on the premises. If multiple APs are deployed, inter-AP handoff may be slow or the mobile client may have to be re-authenticated when associating with a different AP. For today’s prevailing usage models (laptop access to check email or connect to Internet/intranet) this is not a severe limitation as users are typically stationary.

Fast and lossless handovers across APs will become a requirement with the availability of a wider range of devices such as Wi-Fi* enabled PDAs and mobile phones, and the introduction of advanced services such as messaging, real-time multimedia streaming, and data application portals.

Improvements in hand-off support are being addressed in IEEE study groups to make possible seamless and fast inter-AP handoffs within the Wi-Fi Protected Access* framework.

3.6.2 Mobility management in hotspots

Requirements for mobility management in public WLANs are still not fully defined. Most hotspots currently are deployed as one large IP subnet. In these topologies support for mobility management is provided by Layer 2 (MAC level) mechanisms such as fast re-authentication, pre-authentication and transfer of MAC layer states such as QoS across APs.

For larger hotspots that employ multiple IP subnets, Intel recommends the use of mobile IP in conjunction with Layer 2 mechanisms for generic (non application specific) mobility. In the future mobile IP will be required. Protocols such as Session Initiated Protocol (SIP) may be appropriate for targeted applications such as Voice over IP (VoIP).

3.6.3 Wireless wide area network (WWAN) interworking

Even though some mobile operators now offer cellular and WLAN services through a single bill, progress on WWAN data interworking is slow due to architectural limitations in the access infrastructure and to incompatibility with cellular IP core networks. Issues such as data access authorization, data reachability and data session persistence need a standards-based resolution. In addition, the diversity of service providers and operators in the WWAN and WLAN space creates significant challenges in service provisioning and authorization. Introduction of EAP-SIM will start to address these issues, especially authentication. As cellular networks integrate IP-based services, we expect WWAN interworking with WLAN to become established and to provide seamless roaming among different wireless technologies. In this area, Intel will continue to provide support to the development and adoption of IETF and 3GPP interworking standards.

3.6.4 Public key-based authentication and authorization

Password-based authentication currently dominates in public WLAN access, as it is easy to implement and familiar to users, but it can open security holes for wireless connectivity. Password-based authentication also suffers from poor usability with inconsistent interfaces, typically requiring users to remember multiple passwords for access to multiple networks. Symmetric key based authentication methods, such as password-based authentication, can be exposed to security vulnerabilities which arise from the need for third-party key establishment. With symmetric keys, each session key established between the mobile client and the authentication server must be shared directly and uniquely by the authentication server with the AP the mobile client associates with. Transfer of session keys hop-by-hop from the authentication server to an AP exposes the key to man-in-the-middle attacks. Intel therefore believes that the long term solution is one based on asymmetric (private-public) keys and that appropriate measures should be taken (such as a night in.

In a late afternoon after work in a few years’ time, Nick waits in the coffee shop for a train, as he listens to Internet radio while looking online for a good deal on plane tickets for a weekend holiday. After a few minutes, he receives an Instant Message (IM) from his wife asking him to rent a movie and bring dinner home. His train arrives and he gets on as he answers with a "sure!"

While on the train, Nick listens to the end of Internet radio show. Then he sees a friend who tells him about a hot new interactive game called Wowsa. He downloads Wowsa then starts playing head to head with his friend on the train as well as others connected on line.

After several minutes, the reminder from his wife to pick up a movie and dinner pops up, and he decides to leave the game. Nick pulls up his video membership to browse a list of movies. He picks a movie from the top of his wish list and rents it. He sends the rental key home to his wife, so she can start downloading the movie on the media service connected to their new wide screen HDTV.

Nick then browses menus for restaurants on his way home and pulls up his favorite restaurant’s web page. He selects Italian, ordering their favorite fettuccine dish (pays and schedules pick up). After that, he connects to his office remotely using a VPN and checks his office email once more to see if an order for a key customer was delivered. Seeing that it was, he signs off for the evening. Once he gets off of the train, he picks up their dinner and heads home.

The ability to securely access different types of applications is increasingly important to users. VPNs add an extra layer of security when accessing valuable information across public networks.

The use of public key-based certificates with attributes for dynamic service provisioning and authorization will promote a more homogeneous framework for network access whether in the home, enterprise, or public hotspots. Intel supports the creation and adoption of standards that will lead to more robust authentication tokens.

3.6.5 Mobile client provisioning considerations

Users often arrive at a hotspot location without any previous knowledge of the required information to access and utilize the network and services. This process is complicated and cumbersome today, as each service provider and network operator presents different interfaces and requires different information from subscribers. To improve the overall user experience, we recommend the adoption of a client provisioning system that supports the AAA requirements for common login described earlier in section 2.4.

This client provisioning system should enable the client to automatically associate to a network that is unknown and discover the required information to access the network and associated services. This information must be kept current by the provisioning system and updates should be sent to the client during associations or during sign-up at the hotspot. A consistent client provisioning framework for signup, renewal and authentication that users can use across devices, hotspot locations, service providers and network types (e.g. public, enterprise or residential) needs to be adopted by the industry. In addition, the client provisioning system must provide transparent support for 802.1X authentication and be capable of addressing problems that may arise during the authentication process.

3.6.6 Network and services discovery

As infrastructure sharing among different networks becomes more widely used, mobile clients will need to have more advanced hotspot discovery capabilities to enable identification of available networks, obtain information about available services, and select the appropriate network automatically (if desired). The establishment of a common yet extensible standard-based framework for hotspot discovery, selection of service providers, and provisioning of service is necessary to provide this functionality across different visited networks.

If there is a single hotspot operator which has a bilateral roaming arrangement with the user’s home operator (Home SP), network selection is trivial. If two or more hotspot operators (i.e., two or more advertised SSIDs) offer service, the mobile client must first select the SSID associated with the desired hotspot operator, and then proceed with the SP selection as usual. The user may also need to select the broker or roaming aggregator, as the hotspot operator(s) may have roaming arrangements with the home SP via multiple intermediaries, whose services (including QoS) and charges may be different.

An industry-wide accepted solution for network and service discovery has not yet emerged, however ongoing work indicates several solutions can be implemented successfully, including:

1. Advertisement using the EAP framework. While suitable for light weight dissemination of SP information, this solution cannot be used for direct advertisement by the home SP.

2. Advertisement within beacon frames. Beacon frames are overloaded with SP information. The approach has several drawbacks: the information is not authenticated, only limited information can be transmitted, its radio use is inefficient, and it might require changes to client firmware.

3. Advertisement through the virtual AP framework. A variant of the previous approach, it can advertise information relevant to each SSID.

4. Advertisement through PEAP. This solution offers a more robust post association framework, which includes a secure provisioning service and can provide detailed information and supports configuration by the home SP.

Network selection can then occur either by explicit SSID preference or by overloading the Network Access Identifier (NAI) of the service providers (SP) in the SSIDs. This selection process can be automated if supported by the client provisioning system described in 3.6.5.

4 Summary and conclusions

WLAN is one of the most exciting new wireless technologies today, allowing secure and robust high-speed wireless access at work, at home and while traveling. It works with laptops, PDAs and soon be included with cellular phones, and it is employed in a rapidly increasing number of locations, including enterprises, airports, hospitals, homes, restaurants, warehouses, marinas and even Recreational Vehicle parks.

To support the growing enthusiasm for the technology among users a common framework to make WLAN convenient, easy to use and secure must be defined and adopted. Intel has developed these guidelines for implementation by enterprise WLAN and public hotspot operators. The guidelines rely on open standards, can be implemented on different hardware configurations and are fully compatible with residential networks. In addition, they lay the foundation for the adoption of advanced services in the future.

Intel’s goal is for users to roam seamlessly from their enterprise network, to public networks and back to their home networks, without being burdened by multiple authentication procedures, subscriptions and user interfaces. Adoption of our WLAN guidelines is a stepping stone towards realizing Intel’s vision of seamless roaming, which allows the user to remain connected and keep remote applications active when moving from one wireless network to another, without having to worry about security, passwords or payment methods. In the meantime, implementation of our recommendations will make possible two important goals in this direction: 1. enable common login across multiple networks; and 2. provide a common infrastructure to support one-bill roaming.

Intel key recommendations for enterprise and public hotspot networks are centered on the adoption of Wi-Fi Protected Access* (Wi-Fi Protected Access*) with 802.1X, EAP and RADIUS to ensure robust mutual authentication and TKIP and PEAP to preserve confidentiality during authentication. Wi-Fi Protected Access* will also promote the development of AAA interfaces that will increase ease of use and be compatible across different Wi-Fi* networks (office, hotspots and home). Intel advocates the use of robust authentication credentials, such as X.509 certificates, for increased security and ease of use.

We expect that provide guest access and mobility management on enterprise networks will be commonplace, taking full advantage of the productivity gains WLANs can provide. These capabilities require support for virtual LAN, multiple SSIDs in a single AP, intra-IP and inter-IP subnet mobility, and the availability of mobility aware applications, fast handoffs, VPN auto launch and secure ad hoc connections.

In public hotspot networks Intel sees the adoption of Wi-Fi Protected Access* as crucial to provide security with login consistency to subscribers. In public hotspots it will be necessary to complement Wi-Fi Protected Access* with Universal Access Method compatibility through the early adoption stage and continued support for VPN use. The adoption of IP-based standards for AAA and mobility will enable one-bill roaming and, eventually, seamless roaming both within WLAN networks and interworking with WWAN and other networks.

WLAN is a relatively new technology that is still developing at an impressive rate. Several standards have been proposed to increase WLAN functionality and different services and applications are expected to appear soon. While it is difficult to predict in detail the development path for 802.11, there are some clear trends that need to be kept in mind while planning a Wi-Fi* network to ensure future compatibility. The Intel guidelines have been drawn with a vision of full mobility management, extensive roaming capabilities, advanced services, such as VoWLAN, a harmonized AAA interface, QoS provisioning, and coexistence with other wireless technologies. Intel requirements are based on technology and standards currently available, and they also support future services and functionality.

This paper presented a strong case for the adoption of open, IP-based standards in the effort to create a common WLAN framework. Our goal is to provide an incentive to establish a common approach in the industry and promote three courses of action:

1. WLAN architects and managers adopt the end to end guidelines for planning new network deployments and upgrading existing ones, offering protected access and advanced functionality to the WLAN users.

2. Equipment and software vendors support the identified standards in the guidelines as requirements or recommendations to ensure interoperability and market acceptance.

3. The industry joins forces with Intel to promote the adoption of open, IP-based standards for AAA, security, and mobility.

Annex A. Intel requirements and recommendations

This annex lists the current and future requirements and recommendations set forth by the WLAN end to end guidelines here presented. They provide a roadmap for the industry that will enable a managed transition toward harmonized WLAN deployments for enterprises and public hotspots.

We distinguish between requirements and recommendations. Requirements constitute the core of elements of all enterprise and public hotspot WLAN deployments, regardless of network topology, size, and functionality offered. Recommended items (marked as Optional items in the tables below) address specific issues, which arise in most, but not all, enterprise WLAN or public hotspot deployments, and should be supported by WLAN managers on an as-needed basis. Future requirements and recommendations are complementary or represent upgrades to the current ones and we expect that their adoption will begin during the second half of 2004.

Intel recommends vendors to provide support for both all the required and recommended standards listed below to ensure wide adoption of WLAN products in the enterprise and hotspot market. (Note: Current requirements are referenced throughout the paper by a number preceded by R, and future requirements by a number preceded by FR.)

Current requirements

Required Name Description Reference Required/Optional

Future requirements

5 PEAP is recommended if EAP-SIM and EAP-AKA are deployed.

6 Multi-SSID is required in public hotspots to ensure co-existence of UAM with WPA.

7 UAM support is required in public hotspots to support co-existence with 802.1X capable clients as part of migration to WPA and 802.11i.

8 If NAT is deployed in your environment, RFC 3022 should be implemented to support VPN.

Annex B. Glossary

Annex C. References:

[1] Intel (2003) "Wireless LANs. Linking productivity gains to return on investment". www.intel.com/eBusiness/pdf/it/pp024801.pdf

[2] Wi-Fi Alliance (2003) "Wi-Fi protected access: Strong, standard-based, interoperable security for today’s Wi-Fi networks". http://www.wi-fi.org/OpenSection/pdf/Whitepaper_Wi-Fi_Security4-29-03.pdf

[3] Luhrer, S., Mantin, I., and Shamir (2001) "Weaknesses in the key scheduling algorithm of RC4". Eighth Annual Workshop on Selected Areas in Cryptography. http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html

[4] Asokan, N, Niemi V. and Nyberg, K. (2003) "Man-in-the-middle in tunneled authentication protocols". http://www.saunalahti.fi/~asokan/research/tunnel_extab.pdf

[5] Matthew Gast (2002) "A Technical Comparison of TTLS and PEAP". http://www.oreillynet.com/pub/a/wireless/2002/10/17/peap.html

[6] Microsoft Internet Authentication Service. http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/intwork/inbc_ias_RQSF.asp

[7] S. Vaarala (2003) "Mobile IPv4 Traversal Across IPsec-based VPN Gateways". http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vpn-problem-solution-02.txt

[8] D. Ziakas (2003) "Hotspot in a box. Creating publicly available WLANs". Intel white paper. ftp://download.intel.com/labs/wireless/download/CreatingPubliclyAvailableWLANs.pdf

[9] Intel® CentrinoTM Mobile Technology Hotspot Finder. http://intel.com/products/mobiletechnology/hotspots/finder.htm?iid=ipp_hotspots+finder&

[10] Gartner (2003) "Public Wireless LAN Hot Spots: Worldwide, 2002-2008".

[11] Wi-Fi Alliance (2003) "Wi-Fi Alliance Wireless ISP Roaming Best Practices Document".
http://www.Wi-Fialliance.org/opensection/wispr.asp

[12] GSMA (2003) "IR-61. GSMA Inter-operator Handbook" (also known as "Inter Operator Handbook"). http://www.gsmworld.com/documents/index.shtml

[13] GSMA (2003) "IR-62. End-to-End WLAN Roaming Test Cases". http://www.gsmworld.com/documents/wlan/ir62.pdf

[14] P. Iyer et al. (2003) "Public WLAN hotspot deployment and interworking". Intel Technology Journal. http://www.intel.com/technology/itj/2003/volume07issue03/art02_hotspot/vol7iss3_art02.pdf

[15] 3GPP (2002) "Feasibility study on 3GPP system to Wireless Local Area Network (WLAN) interworking, 3GPP TR 22.934". Version 6. http://www.3gpp.org/ftp/Specs/html-info/22934.htm

[16] 3GPP (2003) "3GPP system to Wireless Local Area Network (WLAN) interworking; Functional and architectural definition". 3GPP TS 23.234. http://www.3gpp.org/ftp/Specs/html-info/23234.htm

* Other names and brands may be claimed as the property of others.

For more information, visit the Intel Web site at: www.intel.com/ebusiness/strategies/wireless/wlan

Intel Access:

WLAN Solutions Web Site http://www.intel.com/ebusiness/strategies/wireless/wlan/index.htm

Intel® Centrino Mobile Technologies http://intel.com/products/mobiletechnology/

Other Intel Support:

800 548-4725 7am - 7pm CST (USA and Canada)

General Information Hotline 800 628-8686 or 916 356-3104 5am - 5pm PST

The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Intel Corporation. Intel Corporation assumes no responsibility or liability for any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document.

Except as permitted above, no part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means without the express written consent of Intel Corporation.

THIS DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY RECOMMENDATION, PROPOSAL, SPECIFICATION OR SAMPLE. Intel disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this document

Intel Corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property rights that relate to the described subject matter. The furnishing of this document does not provide any license, express or implied, by estoppel or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights.

Intel is seeking feedback on this 1.1 release. If you would like, you can email feedback to [email protected]
All feedback submitted will become the property of Intel.

Intel, Pentium, and Centrino are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

Visit the Authors Web Site