WIRELESS SECURITY IN (WI-FI ) NETWORKS

Download (0)

Full text

(1)

WIRELESS SECURITY IN 802.11 (W I -F I ®) NETWORKS

With the increasing deployment of 802.11 (or Wi-Fi) wireless networks in business

environments, IT organizations are working to implement security mech- anisms that are equivalent to those existing today for wire-based net- works. An important aspect of this is the need to provide secure access to the network for valid users. Existing wired network jacks are located inside buildings already secured from unauthorized access through the use of keys, badge access, and so forth. A user must gain physical access to the building in order to plug a client computer into a network jack. In con- trast, a wireless access point (AP) may be accessed from off the premises if the signal is detectable (for in- stance, from a parking lot adjacent to the building).

There are a number of approaches to secure 802.11 net- works. No one approach works for all environments and situations. The optimal solution(s) in a particular net- work depends on factors such as the level of security required, size of the network, whether access is re- quired for remote workers, and so forth. Because of this diversity, Dell is committed to offering a broad set of standards-based tools and solutions that offer custom- ers flexibility in designing and implementing 802.11 security solutions.

This white paper begins by discussing the basic securi- ty control methods that form the basis of the original 802.11 architecture. The paper continues with the more-robust virtual private network (VPN) alternative, as well as the upcoming IEEE 802.11i standard that ad- dresses weaknesses in 802.11 native security. Both VPN and 802.11i-based security solutions provide bet- ter security and scale well to large networks. The paper also presents Wi-Fi Protected Access (WPA), which is an interim release of key components of 802.11i. Wi-Fi products based on WPA are expected by the middle of 2003.

Basic 802.11 Security

Three well-known methods to secure access to an AP are built into 802.11 networks. These basic methods are widely available and may be sufficient for some deployments:

Service set identifier (SSID)

Media Access Control (MAC) address filtering

Wired Equivalent Privacy (WEP)

One or more of these methods may be implemented, but all three together provide a more robust solution.

SSID

Network access control can be implemented using an SSID associated with an AP or group of APs. The SSID provides a mechanism to “segment” a wireless network into multiple networks serviced by one or more APs.

Each AP is programmed with an SSID corresponding to a specific wireless network. To access this network, cli- ent computers must be configured with the correct SSID. A building might be segmented into multiple net- works by floor or department. Typically, a client com- puter can be configured with multiple SSIDs for users who require access to the network from a variety of dif- ferent locations.

Because a client computer must present the correct SSID to access the AP, the SSID acts as a simple pass- word and, thus, provides a measure of security.

However, this minimal security is compromised if the

AP is configured to “broadcast” its SSID. When this

broadcast feature is enabled, any client computer that

is not configured with a specific SSID is allowed to re-

ceive the SSID and access the AP. In addition, because

users typically configure their own client systems with

the appropriate SSIDs, they are widely known and easily

shared. (Dell strongly recommends that APs be config-

ured with broadcast mode disabled, which is referred to

as “closed mode.”)

(2)

MAC Address Filtering

While an AP or group of APs can be identified by an SSID, a client computer can be identified by the unique MAC address of its 802.11 network card. To increase the security of an 802.11 network, each AP can be pro- grammed with a list of MAC addresses associated with the client computers allowed to access the AP. If a cli- ent's MAC address is not included in this list, the client is not allowed to associate with the AP.

MAC address filtering (along with SSIDs) provides im- proved security, but is best suited to small networks where the MAC address list can be efficiently managed.

Each AP must be manually programmed with a list of MAC addresses, and the list must be kept up-to-date. In practice, the manageable number of MAC addresses fil- tered is likely to be less than 255 clients. In addition, MAC addresses can be captured and “spoofed” by an- other client to gain unauthorized access to the network.

WEP-Based Security

Wireless transmissions are easier to intercept than transmissions over wired networks. The 802.11 stan- dard currently specifies the WEP security protocol to provide encrypted communication between the client and an AP. WEP employs the symmetric key encryption algorithm, Ron’s Code 4 Pseudo Random Number Gen- erator (RC4 PRNG).

Under WEP, all clients and APs on a wireless network typically use the same key to encrypt and decrypt data.

The key resides in the client computer and in each AP on the network. The 802.11 standard does not specify a key-management protocol, so all WEP keys on a net- work usually must be managed manually unless they are used in conjunction with a separate key-manage- ment protocol. For example, 802.1X (discussed later in this paper) provides WEP key management. Support for WEP is standard on most current 802.11 cards and APs.

WEP specifies the use of a 40-bit encryption key and there are also implementations of 104-bit keys. The en- cryption key is concatenated with a 24-bit “initialization vector” (IV), resulting in a 64- or 128-bit key. This key is input into a pseudorandom number generator. The re- sulting sequence is used to encrypt the data to be transmitted. (WEP keys can be entered in alphanumeric text or hexadecimal form.)

Figure 1 depicts WEP-based security with MAC address filtering.

WEP encryption has been shown to be vulnerable to at- tack. Because of this, static WEP is only suitable for small, tightly managed networks with low-to-medium security requirements. In these cases, 128-bit WEP should be implemented in conjunction with MAC ad- dress filtering and SSID (with the broadcast feature disabled). Customers should change WEP keys on a regular schedule to further minimize risk.

For networks with high security requirements, the VPN or emerging 802.11i standards-based solutions dis- cussed in the next sections are preferable. These solutions are also preferable for large networks, in which the administrative burden of maintaining MAC addresses on each AP makes this approach impractical.

The point at which the number of wireless client sys- tems becomes unmanageable varies depending on the organization’s ability to administer the network, the choice of security methods (SSID, WEP, and MAC ad- dress filtering), and its tolerance for risk. If MAC address filtering is used on a wireless network, the fixed upper limit is established by the maximum num- ber of MAC addresses that can be programmed into each AP used in an installation. This upper limit varies,

Figure 1. 802.11 Security Using SSID, MAC Address

Filtering, and WEP

(3)

but the practical problem of manually entering and maintaining valid MAC addresses in every AP on a net- work limits the use of MAC address filtering to smaller networks.

VPN Wireless Security

VPN solutions are widely deployed to provide remote workers with secure access to the network via the Inter- net. In this remote user application, the VPN provides a secure, dedicated path (or “tunnel”) over an “untrusted”

network—in this case, the Internet. Various tunneling protocols, including the Point-to-Point Tunneling Proto- col (PPTP) and Layer 2 Tunneling Protocol (L2TP) are used in conjunction with standard, centralized authenti- cation solutions, such as Remote Authentication Dial-In User Service (RADIUS) servers.

The same VPN technology can also be used for secure wireless access. In this scenario, the “untrusted” net- work is the wireless network. The APs are configured for open access with no WEP encryption, but wireless access is isolated from the enterprise network by the VPN server. The APs can be connected together via a virtual LAN (VLAN)

1

or LAN that is deployed in the De- militarized Zone (DMZ)

2

and connected to the VPN server. (The APs should still be configured in closed mode with SSIDs for network segmentation.) Authenti- cation and full encryption over the wireless network is provided through the VPN servers that also act as fire- walls/gateways to the internal private network. Unlike the WEP key and MAC address filtering approaches, the VPN-based solution is scalable to a very large number of users.

Figure 2 shows how VPN connections can provide flex- ible access to a private network. Remote workers can use a dial-up, cable modem, Digital Subscriber Line (DSL), or cellular data (such as General Packet Radio Service [GPRS]) connection to the Internet and then es- tablish a VPN connection to the private network. Public wireless LAN (WLAN) networks in locations such as air- ports can also be used to establish a VPN connection back to the private network. Finally, on-campus 802.11 wireless access can be implemented via a secure VPN

connection. The user login interface is the same for each of these scenarios, so that the user has a consis- tent login interface.

The VPN approach has a number of advantages:

Already deployed on many enterprise networks.

Scalable to a large number of 802.11 clients.

Low administration requirements for 802.11 APs and clients. The VPN servers can be centrally ad- ministered.

Traffic to the internal network is isolated until VPN authentication is performed.

WEP key and MAC address list management is not needed because of security measures created by the VPN channel itself.

Addresses general remote access with a consistent user interface in different locations such as at home, at work, and in an airport.

A drawback to current VPN solutions is the lack of sup- port for multicasting, which is a technique used to deliver data efficiently in real time from one source to many users over a network. Multicasting is useful for

1. A VLAN is a logical subgroup of client nodes in a local area network that is created using software. The purpose of a VLAN is to isolate “untrusted” traffic within the VLAN.

2. The DMZ is a middle ground that lays between an organization's trusted internal network and an untrusted, external network such as the Internet. It is a subnetwork (or subnet) that may reside between firewalls or off one leg of a firewall.

Figure 2. 802.11 VPN Wireless Security

(4)

streaming audio and video applications such as press conferences and training classes.

Another minor issue of VPNs is that roaming between wireless networks is not completely transparent. Users receive a logon dialog when roaming between VPN servers on a network or when the client system re- sumes from standby mode. Some VPN solutions address this issue by providing the ability to “auto-re- connect” to the VPN.

When using a VPN solution, it is still recommended that client computers be equipped with personal firewall protection (such as Norton Internet Security, Black Ice, or the built-in firewall in Microsoft® Windows® XP) to protect against attacks by nearby wireless client systems.

VPNs are a good solution for many networks, particular- ly those with existing VPN infrastructure for remote access. Additional wireless security alternatives are emerging that are based on the IEEE 802.11i standard.

IEEE 802.11i Standards-Based Wireless Security

802.11i is a new security standard being developed by the IEEE Taskgroup i (TGi). 802.11i addresses the weak- nesses of WEP-based wireless security. Scripting tools exist that can be used to take advantage of weaknesses in the WEP key algorithm to successfully attack a net- work and discover the WEP key. The industry and IEEE are working on solutions to this problem through the TGi working group. Substantial components of the 802.11i standard have already been released or an- nounced and products are beginning to appear in the market.

The 802.11i standard addresses the user authentication and encryption weaknesses of WEP-based wireless se- curity. The components of 802.11i include the already- released IEEE 802.1X port-based authentication frame- work, the Temporal Key Integrity Protocol (TKIP), the Advanced Encryption Standard (AES) encryption algo- rithm (to replace WEP’s RC4 encryption), key hierarchy and management features, and cipher and authentica- tion negotiation. 802.11i addresses the security requirements of AP-based (or Basic Service Set [BSS]) and ad hoc (or Independent BSS [IBSS]) 802.11 wireless

networks. The formal completed 802.11i standard is ex- pected in the second half of 2003.

Meanwhile, because of important security require- ments of 802.11 wireless networks, a subset of the 802.11i standard has been released under the auspices of the Wi-Fi Alliance. Formerly called WECA, the Wi-Fi Alliance is a nonprofit organization that certifies interop- erability of 802.11 products and promotes 802.11 as the global, wireless LAN standard. A strong supporter of the Wi-Fi Alliance, Dell is a member of its board of direc- tors and is very active in Wi-Fi Alliance committees.

In November 2002, the Wi-Fi Alliance announced WPA, which is based on those components of the 802.11i standard that are stable and may be deployed on exist- ing 802.11 network and client equipment with a software upgrade. When it is released, 802.11i will be backward-compatible with WPA. In fact, the final stan- dard will be adopted by Wi-Fi as WPA, version 2. Wi-Fi expects to begin certifying WPA solutions in the first quarter of 2003, and these solutions will begin appear- ing in the market shortly thereafter.

The initial release of WPA addresses AP-based 802.11 networks. Ad hoc (or peer-to-peer) networks will be ad- dressed in the final standard. The following

components of 802.11i are included in the initial WPA release:

802.1X authentication framework

TKIP

Key hierarchy and management

Cipher and authentication negotiation

WPA also specifies an 802.1X/RADIUS implementation and a preshared key implementation discussed later in this paper.

Port-Based Authentication With 802.1X The IEEE 802.1X standard specifies generic, extensible port-based authentication that applies to both wireless and wired Ethernet networks. 802.1X authentication so- lutions that use WEP encryption exist in the market today, but they provide for dynamic WEP keys. Under WPA, 802.1X supports the other components of WPA.

802.1X is supported in several current operating sys-

tems (see discussion of operating system support later

in this paper) and in the enterprise APs offered by major

(5)

vendors, including Dell. The standard specifies a frame- work that accommodates various authentication methods such as certificate-based authentication, smart cards, and traditional passwords.

In the context of an 802.11 wireless network, 802.1X is used to securely establish an authenticated association between the client and the AP.

Generally, the scenario would be as shown in Figure 3.

The user of an 802.11 wireless client system requests access to an AP. The AP passes the request to a central- ized authentication server that handles the

authentication exchange and, if successful, provides an encryption key to the AP. The AP uses the key to se- curely transmit a unicast session or multicast/global encryption key to the client. (Prior to the WPA an- nouncement, WEP was the only encryption method supported by the 802.11 standard, but upcoming TKIP solutions will replace WEP.) At this point, the client has access to the network, transmissions between the cli- ent and AP are encrypted, and the user may log on to the network domain. During the session, new keys are generated between the client and AP (referred to as dy- namic WEP key exchange) to help mitigate exposure to WEP attacks.

802.1X does not require a specific protocol for authen- tication. Instead, it specifies that the Extensible

Authentication Protocol (EAP) will be used. EAP is an encapsulation protocol that allows different authentica- tion protocols to be selected and used. Effectively, EAP serves as a conduit for other authentication protocols.

There are four main authentication protocols:

MD5 — One-way authentication to network using a password.

Cisco Lightweight Authentication Extension Proto- col (LEAP) — Cisco proprietary username-based au- thentication.

EAP-Transport Layer Security (TLS) — IETF-stan- dardized authentication. Public Key Infrastructure (PKI) certificate-based authentication of both the user (or client system) and the authentication serv- er.

EAP-Tunneled TLS (TTLS) and Protected EAP (PEAP) — PEAP and TTLS are similar approaches that are based on TLS extensions. These approach- es can be used with higher-layer authentication pro- tocols (such as MS-CHAPv2) and do not require certificates on the client.

The best method for a particular installation depends on the specific requirements of the environment. Howev- er, while MD5 is the simplest authentication method, it is also the weakest, so it is not recommended for use in wireless networks. Under MD5, the user passwords are stored in a way that allows the authentication server ac- cess to the plain-text password. This approach makes it possible for entities other than the authentication server to gain access to the password. This weakness is com- pounded by the fact that MD5 only authenticates the user and not the authentication server. More robust methods provide “mutual authentication” of both entities.

Cisco LEAP offers stronger security than MD5, but should be considered a proprietary solution that could limit choices and lead to potentially higher long-term costs. In contrast, the following standards-based EAP solutions offer stronger authentication and offer the benefit of broader vendor equipment support.

The IETF-standardized EAP-TLS, EAP-TTLS, and PEAP methods offer the strongest authentication and are rec- ommended for 802.1X implementations. TLS is based on an authentication protocol that is nearly identical to the protocol used in the Secure Sockets Layer (SSL)

1. User requests authentication. AP prevents network access.

2. Encrypted credentials sent to authentication server (RADIUS).

3. Authentication server validates user and grants access rights.

4. AP port is enabled and WEP keys are assigned to client (encrypted).

5. Wireless client accesses general network services securely.

Figure 3. 802.1X/RADIUS Authentication

(6)

protocol for securing Web transactions. TLS provides mutual authentication between the supplicant and the authentication server. Once authentication is complet- ed, 802.1X enables dynamic WEP keys to be generated.

In EAP-TLS, PKI-based digital certificates are used for mutual authentication. (PKI digital certificates can be stored on Smart cards or on the client computer.) Alternatively, EAP-TTLS is an extension of EAP-TLS that is designed for organizations that are not ready to im- plement PKI on every client. (This is required to achieve mutual authentication with digital certificates). Instead, it only requires PKI for digital certificate-based authenti- cation of the authentication server. In some cases, self- rooted certificates can be used instead of a PKI, as long as each client has a copy of the server certificate. EAP- TTLS supports legacy authentication methods for the client system or user.

An extension to EAP called PEAP is also designed to overcome problems associated with certificate man- agement under EAP-TLS. PEAP can be used in conjunction with a higher-layer authentication mecha- nism such as MS-CHAPv2. EAP and PEAP occur during the IEEE 802.1X authentication process before WEP keys are generated and distributed. PEAP uses the TLS handshake solely to identify the network to a client de- vice. This approach avoids the need to assign signed certificates to individual client devices. Client authenti- cation is done inside the established TLS tunnel (thus providing the advantages of TLS communication) using a higher-layer protocol such as MS-CHAPv2. Any EAP- based authentication method might be used inside the established secure channel.

TTLS and PEAP are very similar. Both use a one-way TLS tunnel. The difference is in the upper-layer authen- tication method after the tunnel is established. TTLS uses simple, less-structured, token-pair-based authenti- cation mechanisms. In contrast, PEAP uses more structured EAP-compatible authentication mecha- nisms. Because Microsoft has created MS-CHAPv2 as an EAP-compatible authentication mechanism, TTLS and PEAP are nearly identical when MS-CHAPv2 is used.

Table 1 compares the main 802.1X authentication protocols.

The 802.1X standard also includes a management spec- ification for complete end-to-end management of the 802.1X protocol.

The 802.1X approach has the following advantages:

Standards-based.

Flexible authentication: administrators may choose the type of authentication method used.

Scalable to large enterprise networks by simply adding APs and, as needed, additional RADIUS servers.

Centrally managed.

Client keys are dynamically generated and propa- gated.

Because authentication is central, rather than at each AP, roaming can be made as transparent as possible. At most, the user may be asked for alter- nate credentials if an AP requires alternate identifi- cation.

Table 1. Comparison of Main 802.1X Authentication Protocols

Characteristic MD5 Cisco LEAP EAP-TLS PEAP and TTLS

Key length None 128 128 128

Mutual authentication

No. Authenticates user, but not authentication device.

Yes Yes Yes

Rotating keys Yes Yes Yes Yes

Overall security Weak Stronger than MD5; weaker than

other EAP solutions.

Strongest Strong

Client software support

Native support in Windows XP.

Other operating systems require client software.

Requires proprietary features in the NIC and AP. Wide range of operating-system support with Cisco 802.11 wireless card.

Native support available in Windows XP and Windows 2000.

Other operating systems may require additional client software.

PEAP support available natively in Windows XP and Windows 2000.

TTLS support available via third- party software.

(7)

802.1X requires software support on the client system and AP, as well as a RADIUS server that supports a strong EAP authentication method such as EAP-TLS and EAP-TTLS. Currently, client operating-system sup- port for 802.1X is limited, with native support provided only in Microsoft Windows XP. Microsoft recently intro- duced support for 802.1X in Windows 2000. This support is available in a software patch that can be downloaded from the Microsoft website. This patch will be incorporated in the next Windows 2000 service pack.

In addition, there are now Microsoft PEAP solutions for Windows XP and Windows 2000.

802.1X support is expected to expand as 802.1X ma- tures and becomes established. Meanwhile, third-party client software exists for other PC client operating systems.

802.1X is designed to authenticate and distribute en- cryption keys between the wireless client and an AP. It is not an encryption protocol, nor is it designed to be a generalized VPN solution suitable for secure remote ac- cess. VPNs are still required for remote access using public APs (in airports or hotels) and from remote or home offices.

TKIP

TKIP enables secure, dynamic key generation and ex- change. TKIP continues to use the RC4 encryption engine used by WEP, but provides the following impor- tant improvements over WEP:

Dynamic keys — Allows per-session and per-packet dynamic ciphering keys.

Message integrity checking (MIC) to ensure that the message has not been tampered with during trans- mission. (The TKIP MIC is sometimes referred to as

“Michael.”)

48-bit IV hashing — Longer IV (used in conjunction with a base key to encrypt and decrypt data) avoids the weaknesses of the shorter 24-bit WEP RC4 key.

Correction of WEP security vulnerability in which the IV is sent in clear text over the wireless connec- tion.

Ultimately, a more robust encryption method based on the next-generation AES is being considered as a future replacement for RC4 in TKIP.

Key Hierarchy and Management

WPA provides for more-secure and better key creation and management. This capability helps to safeguard against known key attacks. Client keys received via 802.1X key messages are used to derive base keys that are, in turn, used to derive per-packet keys. The master and base keys are not used to directly encrypt the data traffic.

Cipher and Authentication Negotiation WPA improves interoperability by requiring APs to “an- nounce” their supported ciphers and authentication mechanisms. Clients wishing to authenticate to the AP via WPA can receive this announcement and respond appropriately (via a policy-based decision). In addition, the client can now choose the most secure cipher and authentication mechanism that it and the AP both support.

WPA Modes: 802.1X/RADIUS or Preshared Key

WPA can be implemented with 802.1X and a RADIUS server (referred to by the Wi-Fi Alliance as “enterprise mode”) or with a simple preshared key (referred to as

“home mode”).

802.1X/RADIUS

In this implementation, WPA requires 802.1X and is used in conjunction with an authentication server to provide centralized access control and management.

This includes managing user credentials, authorizing users requesting network access, and generating ses- sion and group encryption keys. Figure 4 shows the components of this implementation.

Figure 4. WPA 802.1X/RADIUS Solution

(8)

Preshared Key

In the home, small office, or even some enterprises, WPA can be used in a preshared key mode that does not require an authentication server (or 802.1X). Access to the Internet and the rest of the wireless network ser- vices is allowed only if the preshared key of the computer matches that of the AP. This approach offers the setup simplicity of the WEP key, but uses the stron- ger TKIP encryption.

The WPA preshared key differs dramatically from the WEP key. Under WPA, the preshared key is used only in the initial setup of the dynamic TKIP key exchange. As described in “Key Hierarchy and Management,” this base key is never sent over the air or used to directly en- crypt the data stream. In contrast, the WEP key is static until manually changed by the user or administrator.

Figure 5 shows the components of this implementation.

WPA is the first phase of the overall 802.11i standard.

WPA immediately addresses the current weaknesses found in WEP. WPA also leverages the power of 802.1X, while providing the same capability to nonenterprise home users.

Future releases of WPA will include increased security measures such as stronger ciphers (that is, AES), addi- tional countermeasures (that is, additions to MIC), and additional design changes to TKIP.

Wi-Fi Security Implementation on Dell Network

Internally, Dell was an early adopter of Wi-Fi technology and has a large Wi-Fi network implementation. Dell al- ready had a VPN solution in place for remote worker access to the corporate network. Dell extended this so- lution to provide security for its internal Wi-Fi users. The result is robust security with a consistent interface re- gardless of where or how the user connects—via WLAN on campus; an airport hot spot; or from home via dial-up, cable, or DSL modem.

Conclusion

Recent industry efforts are bringing more-robust native security to Wi-Fi networks. The basic 802.11 security solutions that are available “out of the box”—SSID, MAC address filtering, and WEP—are soon to be strengthened by replacing important components of WEP with WPA via software upgrades to the wireless client systems and APs. This solution will provide suit- able security for both small home or business networks and larger networks. 802.1X- and/or VPN-based solu- tions provide more scalable solutions for large enterprise networks or networks that require more ro- bust security.

Because no one of these approaches addresses all en- vironments and situations, Dell is committed to providing a wide range of standards-based security so- lutions that can be implemented flexibly to address varying customer requirements and environments.

Figure 5. WPA Preshared Key Solution

Information in this document is subject to change without notice.

© 2003 Dell Computer Corporation. All rights reserved.

Trademarks used in this text: The DELL logo is a trademark of Dell Computer Corporation; Microsoft and Windows are registered trademarks of Microsoft Corporation; Wi-Fi is a registered trademark of Wireless Ethernet Compatibility Alliance, Inc. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell Computer Corporation disclaims any proprietary interest in trademarks and trade names other than its own.

Figure

Updating...

References