Enterprise wireless LAN security: 802.11 and seamless wireless roaming

802.11n's impact on WLAN security
Securing embedded 802.11n devices
Persistent, secure connections for roaming WiMAX, 3G and 802.11x

802.11n's impact on WLAN security

As businesses move full steam ahead toward bigger, faster wireless local area networks (WLANs), many factors must be considered -- including security. 802.11n promises to expand network coverage and capacity, but care must still be taken to deliver the same or better security.

A brief history of older wireless IEEE 802.11a/b/g standards
Like yesterday's 802.11a/b/g standards, the 802.11n High Throughput standard employs 802.11i "robust security." In fact, all Draft N products are required to support Wi-Fi Protected Access version 2 (WPA2) -- the Wi-Fi Alliance's test program for 802.11i.

The good news: All 802.11n WLANs built from scratch can forget about WEP crackers and WPA (TKIP MIC) attacks, because every 802.11n device can encrypt data with AES. The catch: WLANs that must support both old 802.11a/b/g clients and new 802.11n clients may be forced to permit TKIP. Doing so makes it possible for older non-AES clients to connect securely. Unfortunately, 802.11n prohibits high-throughput data rates when using TKIP.

It is therefore best to split old 802.11a/b/g clients and new 802.11n clients into separate SSIDs: a high-throughput WLAN requiring AES (WPA2) and a legacy WLAN that allows TKIP or AES (WPA+WPA2). This can be done by defining two SSIDs on a virtual AP or by dedicating different radios on dual-radio APs. This is only a stop-gap measure, however. As soon as you can retire or replace those legacy devices, do away with TKIP to improve both speed and security.

Strengths of WPA2 used to improve 802.11n security
802.11n inherits WPA2's strengths -- and weaknesses. 802.11a/b/g and 802.11n devices can use AES to prevent wireless data frame eavesdropping, forgery and replay. 802.11a/b/g and 802.11n APs can use 802.1X to connect authenticated users while denying access to strangers. However, 802.11n still cannot stop intruders from sending forged management frames -- an attack method used to disconnect legitimate users or masquerade as "evil twin" APs.

As a result, new 802.11n networks must remain vigilant to wireless-borne attacks. Very small WLANs can still use periodic scans to detect rogue APs, while business WLANs should use full-time wireless intrusion prevention systems (WIPS) to stop rogues, accidental associations, unauthorized ad hocs, and other Wi-Fi attacks.

Existing WLANs that employ one or both of these security practices cannot rest on their laurels, however. 802.11n devices reach twice as far as their 11a/b/g counterparts. Rogue, neighbor, or metro-area APs that were too distant before could now become a threat. Not only will intruders be able to connect to your WLAN more easily, but legitimate users will be more likely to connect accidentally to outsiders. Given a choice between your old 11ag AP and a faster 802.11n rogue, promiscuous "connect to any available network" clients will go for the rogue every time.

In short, 802.11n's expanded reach exacerbates the frequency of conventional wireless security incidents and exposes weak configurations that rely on poor performance. Worse, existing 11a/b/g-based WIPS sensors could miss many incidents entirely. Every 802.11n rollout should include a WIPS upgrade to monitor the new WLAN's bigger footprint, analyzing 11a/b/g and n traffic on 20 MHz and 40 MHz channels in both bands.

802.11n protocol brings new security threats, complexity
Every new technology introduces a few undiscovered threats; an innovation as significant as 802.11n is likely to be no exception.

802.11n devices are new products that may contain a few undiscovered bugs. For example, early versions of the Netgear WN802T AP did not correctly parse zero-length (null) SSIDs (WVE-2008-0010). Atheros drivers used in new 802.11n APs (like the Linksys WRT350N) did not correctly handle certain management frame information elements (WVE-2008-0008). Such vulnerabilities are not unusual; WLAN administrators simply need to keep up with security advisories and firmware/driver upgrades.

802.11n options are also considerably more complex, increasing the likelihood of misconfiguration. For example, there are dozens of possible high-throughput data rates, each associated with a combination of capabilities and parameters that must match on both ends. In most cases, misconfiguration causes suboptimal performance -- this might not seem like a security issue, but it can affect availability. In extreme cases, a misconfigured 802.11n AP could result in denial of service to neighboring WLANs. Education and in-situ analysis are needed to find and fix these problems.

Finally, 802.11n introduces a few new MAC frames, one of which has been found to be exploitable. Specifically, 802.11n provides more efficient support for streaming applications by confirming receipt of several data frames using one block acknowledgment. A denial-of-service (DoS) attack can be launched against 802.11n WLANs by sending forged block acknowledgments to the receiver (WVE-2008-0006). An 802.11n-capable WIPS may detect this attack, but the only way to avoid it is to stop using the Add Block-ACK (ADDBA) feature.

How to make 802.11n more secure
Fortunately, all of today's wireless network security best practices still apply to 802.11n. It's important to realize, however, that 802.11n may also raise business risk simply by supporting more users and applications across larger areas. In short, the same old attacks may now be far more disruptive to your business.

Ultimately, 802.11n networks can be made just as secure as -- if not more secure than -- yesterday's 11a/b/g networks. All it takes is awareness and follow-through. In this tip, we've explored the ways in which 802.11n can affect WLAN security. Now it's your turn to provide that follow-through.

Securing embedded 802.11n devices

As WLANs are updated to 802.11n, most will be populated by increasingly diverse devices. According to In-Stat, 2008 Wi-Fi sales were dominated by dual-mode Wi-Fi cell phones (56 million), stationary consumer electronic devices like printers (48 million), and portable consumer electronic devices like cameras (71 million). Traditional Wi-Fi clients like notebooks represented less than half of chipsets shipped last year.

Most administrators already understand how to secure wireless notebooks, but Wi-Fi phones, printers, cameras and specialized devices like barcode scanners pose unique challenges. They cannot be configured by desktop management systems, nor can they participate in human-interactive login processes. So what techniques can be used to secure this new wave of embedded 802.11n devices?

MAC filters fall short
Let's start with the most common method of controlling embedded device access: media access control (MAC) filters. MAC filters, or access control lists (ACLs), are widely used to discourage wireless connections from unknown client devices.

Many Point-of-Sale (PoS) and Voice over IP (VoIP) deployments use old, limited devices – barcode scanners, Wi-Fi handsets – that lack Wi-Fi protected access (WPA). It is common to configure APs with lists of known devices, identified by the MAC address sent in all Wi-Fi frames. APs use this list to reject unrecognized devices and map the rest onto a designated network segment (such as a VLAN). Upstream filters may be added to control service access – for example, permitting only SIP and RTP to reach a VoIP gateway that checks SIP uniform resource identifiers inside those packets.

This approach makes the best of a bad situation where devices lack the embedded capabilities needed to join an 802.11i robust security network. MAC addresses are easily spoofed, however. Anyone within range can capture Wi-Fi frames, extract authorized addresses, and use them to bypass MAC filters. Furthermore, if data payload is unencrypted, one can extract destination IP addresses, ports and service identifiers like URIs, thereby defeating upstream filters.

Some deployments also use wired equivalent privacy (WEP) to make packet analysis more difficult, but given contemporary WEP cracking tools, this raises the bar just slightly. In short, MAC ACLs are at best a weak deterrent, suitable for deflecting accidental connections but not incented intruders.

Simple secure setup
Today, all Wi-Fi certificated products are required to support WPA2, which combines Advanced Encryption Standard (AES) data protection with pre-shared key (PSK) or 802.1X authentication. But, to facilitate out-of-the-box interoperability, almost all Wi-Fi products are shipped with WPA2 turned off.

As a result, many Wi-Fi devices are still put into service with no wireless security. This problem has long plagued residential devices sold to consumers who lack the security awareness needed to configure PSKs. To close this gap, the Wi-Fi Alliance created an optional certification program called Wi-Fi Protected Setup (WPS). As it turns out, WPS is not just for SOHOs – it also provides a convenient way to enable WPA2 on many embedded Wi-Fi devices used in business WLANs.

More than 500 products have achieved WPS certification to date – nearly 300 with 802.11n. These devices include external and internal Wi-Fi adapters, laptops, display devices, print servers, cameras, voice handsets, smartphones, digital audio devices, media servers, set-top boxes and, of course, many APs and gateways. All can automate WPA-PSK2 configuration using one or more WPS techniques: personal information number (PIN), push-button configuration (PBC), and near-field communication (NFC).

With the PIN method, all devices are associated with a unique number printed on the device or its packaging, or displayed on the device's LCD panel or screen. To enroll a device, its PIN is entered into a "WPS registrar" – usually a configuration page on the AP, gateway or controller. The registrar and device complete a secure over-the-air WPS handshake, during which the registrar assigns a random PSK to the device. The device then self-enables WPA2-PSK, using those WPS-supplied SSID and PSK values.

Some devices also support the PBC method, where physical WPS buttons must be pushed simultaneously on the AP and the device to be registered. For a short period, the AP listens for and accepts any nearby device requesting WPS enrollment. This method eliminates PIN entry but creates a brief window of opportunity during which unauthorized devices might conceivably be added.

Last year, an optional NFC method was added to eliminate that gap. When an NFC-enabled client device is placed within 10 centimeters of the NFC "target mark" on the AP, the WPS registrar uses NFC communication to read the client's identity from a token embedded in the device. Once approved, that device is given the SSID and PSK that it needs to complete automated WPA2-PSK setup and join the WLAN.

In all three methods, WPS shifts security setup responsibility from the user to the network itself. Avoiding end-user configuration of Wi-Fi security parameters not only reduces human confusion and error, it can eliminate the need for manual WLAN configuration interfaces on embedded Wi-Fi devices.

Beyond PSK
WPS is a low-overhead way to secure many new embedded Wi-Fi devices. By assigning random SSIDs to each WLAN and random PSKs to each device, WPS also defeats PSK crackers that depend upon short, easily guessed pass-phrase values. However, PSKs still do not meet all business needs – for example, many businesses wish to use 802.1X to authenticate individual users, map them onto the appropriate VLAN, and track their network activities.

To participate in WPA2-802.1X (also known as WPA2-Enterprise), embedded devices must supply authorized credentials – for example, a digital certificate issued by a trusted certification authority, a unique subscriber identity module (SIM) associated with a cell phone, or protected access credential (PAC) issued to the device. Thus, each device's ability to authenticate to a business WLAN using 802.1X depends upon support for various Extensible Authentication Protocol (EAP) methods.

Devices that support EAP-SIM, for example, implement RFC 8146, a method defined for clients that communicate over both GSM cellular networks and WLANs -- a smartphone that roams between 3G and Wi-Fi might use 802.1X with EAP-SIM to authenticate when connecting to commercial hotspots. Today, 802.11n devices that support EAP-SIM are largely internal and external adapters and laptops, but future 802.11n smartphones may well support EAP-SIM.

EAP-SIM is of greater interest to carriers; enterprises may prefer issuing their own client credentials, even to embedded devices. One method that works this way is EAP-FAST, an integral component of Cisco's Unified Wireless Network architecture. EAP-FAST's PAC-based authentication can be used with Cisco and other-vendor clients that implement Cisco Compatible Extensions (CCX) version 3 or later. Currently, this list includes smartphones, Wi-Fi handsets, "wearable" computers, and ruggedized handhelds – but 802.11n CCX devices have yet to emerge in these categories.

In fact, the first embedded 802.11n WPA-Enterprise devices have been printers and print servers – these will no doubt be quickly followed by other stationary 802.11n devices that require high bandwidth. Mobile devices are expected to take longer to move to 802.11n because of power consumption/battery-life challenges.

Nonetheless, as next-generation embedded 802.11n devices emerge, businesses must prepare to secure them. In the short run, WPS will be a viable answer for many consumer electronic devices – and certainly an improvement over MAC ACLs. In the long run, businesses should use 802.1X to authenticate embedded 802.11n devices that support WPA2-Enterprise. Not only will 802.1X provide more robust wireless protection, it will dovetail with most network access control (NAC) architectures.

Persistent, secure connections for roaming WiMAX, 3G and 802.11x

Business adoption of wireless services is surging. According to the Webtorials 2008 WLAN State of the Market survey, 64% of enterprises now use 3G cellular broadband, while 32% plan to tap mobile WiMAX when it is available. Simultaneously, enterprise WLANs are continuing to grow: A whopping 91% already use 802.11g, while 68% have 802.11n upgrades under way.

But these wide-area and local-area wireless services are not competitors. Cellular data (WWAN) services excel at on-the-go/outdoor Internet access, whereas 802.11 WLANs are better suited for on-site/indoor private network access. Together, these technologies deliver more robust and ubiquitous connectivity than either by itself. But for mobile workers who use both, there's one big catch: seamless secure roaming.

Wireless security islands
WWANs and WLANs commonly employ different measures to authenticate and secure data in transit. Enterprise WLAN security is largely about keeping corporate networks (wired and wireless) safe from misuse and attack; enterprise WWAN security focuses on protecting business data as it traverses public networks.

Inside WLANs, administrators use 802.1x to control corporate network use, followed by 802.11i (AES) encryption to ensure privacy and integrity. Other methods may be applied to different user communities or applications – for example, WPA-PSK for handheld devices like VoIP phones, or captive portals for guests. However, all of these measures start and end inside the local network, securing just a thin sliver of that network – the wireless edge.

In contrast, workers who connect via WWANs use secure remote-access methods: SSL-protected Web portals, TLS-encrypted email connections, and/or virtual private network (VPN) tunnels. These approaches were developed to enable Internet-based access by business travelers, teleworkers and day extenders. As a result, they are network-independent, designed to tunnel private data nearly all the way to its final destination.

For users who stick to a single type of wireless network, the choice is simple. When mobile users roam between different networks, however, confusion and disruption can reign. First, there is the question of which wireless service should be used at any given time. Second, there is the impact of shifting from one network point of attachment to another. And, finally, there are the consequences of hopping between isolated security islands.

Mobile VPNs bridge the gap
How can enterprise administrators make sure that mobile PDAs and notebooks that roam between wireless networks stay safe and productive? By default, many companies start by requiring WWAN connectivity (and security) everywhere. This often results in slow or broken connections inside buildings that cellular cannot penetrate. Moreover, even where cellular works, companies chafe at paying carriers for WWAN access where higher-speed WLANs could be used.

The logical next step – using a simple connection manager to cut-over from WWAN to WLAN – creates a new set of problems. When users roam from one network point of attachment to another, application sessions must be mended quickly while minimizing disruption. Ordinary VPNs don't address this need; they can actually make matters worse by requiring tunnel reestablishment.

On the other hand, Mobile VPNs are explicitly designed to tackle the gaps between disjointed wireless and wired networks. Like conventional VPNs, Mobile VPNs use authenticated, encrypted tunnels to safeguard business data sent over untrusted networks. In addition, Mobile VPNs can offer the following features:

• Network independence: Mobile VPNs can operate over just about any kind of public or private network, including dial-up, residential broadband connections, Ethernet LANs, WLANs, WWANs, satellite data networks, and even non-IP radio networks.
• Network transparency: Mobile VPNs try to smooth over network differences by providing a consistent security environment, application interface, and user experience. From the worker's perspective, "the connection" is simply up or down. From the administrator's perspective, that connection always delivers the same security.
• Network persistence: When devices roam between networks, they lose their IP address and authenticated state. Mobile VPNs fix this by assigning each client its own virtual IP address that remains constant as physical IP addresses change. This persistent address avoids network connection resets and re-authentications while roaming.
• Suspend/resume transparency: Smartphones, PDAs and notebooks "sleep" when not busy in order to conserve power. Mobile VPN gateways serve as a proxy for suspended devices, letting them wake and resume communication without having to reestablish a VPN tunnel or repeat user login.
• Application persistence: Throughout each business day, most wireless users encounter coverage gaps – elevators, tunnels, airplanes, and regions without cellular coverage. Many mobile VPN gateways can queue application messages for later retransmission to those out-of-reach devices. This lets applications survive frequent or even lengthy disruptions – for example, transparently resuming a download started before boarding a flight immediately upon arrival and cellular service restoration.
• Policy-based roaming: Today, most notebooks and smartphones have multiple network interfaces; some Mobile VPNs can manage how available services are used based on roaming policies. For example, signal strength, link speed, pricing, usage budgets, native network security, and corporate preferences may all be factors in choosing the "best" service. Mobile VPN connection managers may trigger roaming at the appropriate time – some even use "make before break" logic to avoid loss of connectivity during handoff.
• Network-aware policies: While Mobile VPNs work hard to hide network differences from users and applications, administrators may want to consider network characteristics in policy. For example, some Mobile VPNs can automate portal login when roaming onto a known hotspot or defer routine OS and AV updates while connected to low-speed or high-cost wireless links.

Mobility and security: Past, present and future
Mobile VPNs were originally aimed at public safety personnel, utility and delivery workforces, healthcare providers, and other occupations where mobility, security and productivity simply had to be combined to meet business objectives. However, today's increased use of mobile devices and the availability of high-speed wireless services may well combine to generate broader interest in Mobile VPNs.

Companies that offer products with some of the Mobile VPN features enumerated above include Agito, AppGate, BirdStep, Columbitech, DiVitas, IBM, Identiprise, Microsoft, Mobile Aware, Motorola, NetMotion Wireless, Radio IP, Smith Micro, and Trellia. Mobile VPN products are a diverse lot, though. Some focus on a single OS (e.g., Win32 notebooks or Windows Mobile handhelds) while others cover a panopoly of mobile operating systems. Some focus on policy-based connection management, some focus on application persistence, and some do both. Some are targeted at enabling unified communications (UC) while others are wireless data-centric.

In short, enterprises must look very closely at Mobile VPN offerings to determine how well they do or don't align with mobile workforce needs. For example, those using Windows Mobile 6.1 smartphones will find they already have an embedded Mobile VPN client, administered via Microsoft SC-MDM. That embedded client can't be extended to support other platforms, however, and may not meet every company's security, network awareness, or application persistence requirements.

Also, consider emerging requirements such as the ability to integrate with your chosen Mobile Device Management, Network Access Control, and/or Unified Communication architectures; scalability when used with high-speed links (especially 802.11n); and support for latency-sensitive and bi-directional applications like Voice over IP and telepresence. Admittedly, such questions blur the boundaries between Mobile VPN gateways and other platforms used to satisfy broader business needs. Don't assume that Mobile VPNs necessarily need to (or should) do it all. But do consider how any Mobile VPN enables more seamless secure roaming while fitting into your overall workforce mobility architecture.

About the author:
Lisa Phifer is president and co-owner of Core Competence, a consulting firm focused on business use of emerging network and security technologies. At Core Competence, Lisa draws upon her 27 years of network design, implementation, and testing experience to provide a range of services, from vulnerability assessment and product evaluation to user education and white paper development. She has advised companies large and small regarding use of network technologies and security best practices to manage risk and meet business needs. Lisa teaches and writes extensively about a wide range of technologies, from wireless/mobile security and intrusion prevention to virtual private networking and network access control. She is also a site expert to SearchMobileComputing.com and SearchNetworking.com.