The practical security measures discussed in Chapter 20, “Basic Wireless Network Security,” are, as a general rule, sufficient for most home wireless users. Corporate users, however, should not rely on basic security measures alone to protect their wireless networks. In this chapter, we discuss some of the more advanced ways to reduce the risk of your wireless network being compromised.
In this chapter, you will also learn about different methods of secondary authentication such as Virtual Private Networks (VPNs) and Remote Authentication and Dial-In User Service (RADIUS). A secondary authentication mechanism requires that, in addition to association with a wireless access point, a user must authenticate (that is, log in) using some other means. But, first, we will look at the replacement for Wired Equivalent Privacy (WEP): Wi-Fi Protected Access (WPA).
Wi-Fi Protected Access (WPA) is designed to provide wireless users with an encryption mechanism that is not susceptible to the vulnerabilities of Wired Equivalent Privacy (WEP). Most 802.11g access points either ship with the option to use WPA or a firmware upgrade can be downloaded from the access point manufacturer.
Before enabling WPA, you should ensure that your wireless card has WPA drivers. As with access points, you often need to update the card’s drivers, firmware, or both in order to take advantage of WPA. This section details how to set up WPA encryption on two access points: the D-Link DI-624 and the Linksys WRV54G. You will also learn how to configure your wireless client to use WPA.
The D-Link DI-624 ships with WPA capability. This means that no firmware upgrade is necessary and you can start using WPA as soon as the DI-624 comes out of the box. First, you need to log into the DI-624 from a wired connection. Then, point your browser to 192.168.0.1 and supply the username admin with a blank password when prompted. This opens the initial configuration screen, as seen in Figure 21.1.
Next, click the Wireless button on the left to open the wireless configuration options window, as shown in Figure 21.2.
Next, choose either the WPA or WPA-PSK Authentication options. The WPA option requires a RADIUS server, whereas WPA-PSK (Pre Shared Key) sets a passphrase that must also be entered in the client WPA configuration settings. See Figures 21.3 and 21.4.
Damage & Defense
Known WPA-PSK Vulnerability
WPA-PSK utilizes a 256-bit pre-shared key or a passphrase that can vary in length from 8 to 63 bytes. Short passphrase-based keys (less than 20 bytes) are vulnerable to the offline dictionary attack. The pre-shared key that is used to set up the WPA encryption can be captured during the initial communication between the access point and the client card. Once an attacker has captured the pre-shared key, he can use that to essentially “guess” the WPA key using the same concepts used in any password dictionary attack. In theory, this type of dictionary attack takes less time and effort than attacking WER Choosing a passphrase that is more than 20 bytes mitigates this vulnerability.
Enter either your RADIUS server information and Shared Secret for WPA or a strong passphrase that is more than 20 bytes long, and then click Apply to save your settings and enable WPA.
The Linksys WRV54G VPN-Broadband Router may require a firmware upgrade to allow WPA capability. Firmware version 2.10 or later is required for WPA functionality on the WR.V54G. To enable WPA, you need to log in to the WRV54G, as shown in Figure 21.5. Point your browser to the IP address of the WRV54G. By default, this is 192.168.1.1. There is no username required and the default password is admin.
Next, click the Wireless tab to display the Wireless Network Settings, as seen in Figure 21.6.
Then, choose the Wireless Security option to display the Wireless Security settings, as seen in Figure 21.7.
The Security Mode drop-down box displays the four modes of security available on the WRV54G:
WPA RADIUS requires a RADIUS server, as shown in Figure 21.8. WPA Pre-Shared Key (Figure 21.9) allows you to enter a strong pre-shared key. All wireless clients must also be configured to use the WPA pre-shared key in order to authenticate to the wireless network.
Finally, enter the RADIUS server IP address and shared secret, or the pre-shared key and choose Save Settings to enable WPA support.
In order to take advantage of WPA, you must configure your wireless client. To allow Windows XP to work with WPA you must first install the Microsoft Update for Microsoft Windows XP (KB826942). This patch enables WPA compatibility in Windows XP. After installing KB826942, double-click the Wireless Network Connection icon on the toolbar. This opens the Wireless Network Connection Properties window, as seen in Figure 21.10. If you have a profile for your access point already set up, select it and click Properties. Otherwise, select Add under the Preferred Networks. The connection properties window will open.
Next, enter the SSID for your access point in the Network Name textbox, as shown in Figure 21.11. Then, choose the type of encryption you configured your access point to use—WPA or WPA-PSK—and then the encryption standard: WEP, Temporal Key Integrity Protocol (TKIP), or Advanced Encryption Standard (AES). Finally, input the pre-shared key configured on your access point into the Network key and Confirm network key textboxes.
Your client setup is now complete and you can utilize your wireless network with WPA security.
Notes from the Underground
WPA In Linux with Linuxant DriverLoader
In order to utilize WPA, you must have drivers for your wireless card that support it. Most 802.11g cards either have a WPA capable driver when they are purchased, or one can be downloaded. The problem is that these drivers are for Windows. Linux users have not been able to enjoy the benefits of WPA because there are very few card manufacturers that have released WPA drivers for Linux. Linuxant has offered a solution to this problem for many cards: DriverLoader.
DriverLoader allows you to use the Windows driver for cards based on the Atheros, Broadcom, Cisco, Intel Centrino, Prism, Realtek, and Texas Instruments chipsets in Linux. DriverLoader also supports WPA. It is available for a free trial from the Linuxant web site (www.linuxant.com/driverloader/) and a permanent license can be purchased for $19.95 at the time of this writing.
The first solution we’ll examine is freeware. Free is always a good thing, especially in the IT industry! Reef Edge (www.reefedge.com) produces several commercial products for use in securing wireless networks, including Connect Manager. Dolphin is a somewhat scaled-down version of Connect Manager that still provides the same basic features, but is flee. If you need to add an unlimited number of users, or add new user groups, you should investigate Connect Manager. The Dolphin FAQ (http://techzone.reefedge.com/dolphin/index/faq.page) provides more information on the limitations of Dolphin in comparison to Connect Manager.
Dolphin runs a hardened version of Linux and, once installed, acts almost the same as any other network appliance. The chief difference is that console and Telnet logins are not supported; all access is via the Secure Socket Layer (SSL) secured Web interface. An aging piece of Intel 586 hardware can be quickly and easily transformed into a secure wireless gateway, providing access control from the wireless network to the wired network, which we demonstrate in this chapter. Dolphin is a noncommercial product and not to be used in large implementations, but it does provide an ideal (and affordable) solution for Small Office/Home Office (SOHO) applications and serves as an excellent test bed for administrators who want to get their feet wet with wireless without opening their networks to security breaches. If you find that Dolphin is to your liking, you might want to consider contacting Reef Edge to purchase Connect Manager or an edge controller. An edge controller is a second, or satellite, machine that can be set up to support your wireless network. You will be able to easily move up to these solutions with the knowledge you gain by configuring and using Dolphin.
Note
SSL was developed in 1996 by Netscape Communications to enable secure transmission of information over the Internet between the client end (Web browsers) and Web servers. SSL operates between the application and transport layers and requires no actions on the part of the user. It is not a transparent protocol that can be used with any application layer protocol; instead, it works only with those application layer protocols for which it has been explicitly implemented. Common transport layer protocols that make use of SSL include: HyperText Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and Network News Transfer Protocol (NNTP).
SSL provides the three tenants of Public Key Infrastructure (PKI) security to users:
- Authentication Ensures that the message being received is from the individual claiming to send it.
- Confidentiality Ensures that the message cannot be read by anyone other than the intended recipient.
- Integrity Ensures that the message is authentic and has not been altered in any way since leaving the sender.
Dolphin provides some robust features that are typically found in very expensive hardware-based solutions, including secure authentication, IPSec security, and session roaming across subnets. Users authenticate to the Dolphin server over the WLAN using SSL-secured communications and then are granted access to the wired network. Dolphin supports two groups, users and guests, and you can control the access and quality of service of each group as follows:
Finally, Dolphin supports encrypted wireless network usage through IPSec tunnels. Through the creation of IPSec VPN tunnels, users can pass data with a higher level of security (encryption) than WEP provides.
To begin working with Dolphin, you need to register for the Reef Edge TechZone at http://techzone.reefedge.com. Once this is done, you will be able to download the CD-ROM ISO image and bootable diskette image files from the Reef Edge download page. The server that you are using for Dolphin must meet the following minimum specifications:
The Dolphin implementation is depicted in Figure 21.12.
Once you’ve gathered all the required items, you can begin installing Dolphin on your server. To do so, perform these steps:
Note
Although these are the default credentials to enter your Dolphin system, it is critical that you change them once you are done with the initial configuration. After you have created your first user account, Dolphin will delete the temp account for you automatically to ensure that no one compromises the server or gains unauthorized network access.
Note
If you don’t have a crossover cable, you can use a switch or hub and two standard straight-through cables. Simply connect the Dolphin server to the management station through the switch or hub. Ensure that you are using the uplink port on the switch or hub and, if required by your hardware, ensure that the uplink port is selected for uplink via regular use. Also make sure that you are on the right network segment with correct IP addressing configured.
Your Dolphin server is now installed and operable on your wireless network. You now need to perform some configuration and management tasks before your server is ready to be placed into production. You need to add users to the Dolphin database who will be allowed to gain access to the wireless network. (Dolphin does not support RADIUS and thus must use a local user database.) In addition, you might want to change the IP addresses and subnets assigned to the Dolphin server network adapters. The following steps walk you through the process of configuring some of these options:
Should you not want authorized users to need to use the Web interface to Dolphin to authenticate, you can equip them with a small utility that is available from Reef Edge, and can be used to perform regular and IPSec-secured logins/logouts. The process to install and use this utility is outlined here:
Tools and Traps
Using Enterprise Wireless Gateways
Don’t think of Dolphin as a full-featured Enterprise Wireless Gateway (EWG). However, you should consider it a wireless gateway. For a full featured EWG, you might want to consider one of the more capable and robust (and more expensive) solutions offered from one of the following vendors:
- Bluesocket www.bluesocket.com
- Columbitech www.columbitech.com
- Reef Edge www.reefedge.com
- Sputnik www.sputnik.com
- Vernier Networks www.verniernetworks.com
- Viator Networks www.viatornetworks.com
These solutions offer the same features as Dolphin—authentication and VPN support—but they also provide many other options, such as RADIUS server support, hot failover support, and multiple protocol support (such as WAP, 3G, and 802.11). The EWG market is still in a great deal of flux as vendors try to refine their products. That does not mean, however, that you cannot create very secure solutions using today’s technology. A word of caution, though: You should expect to find bugs and other errors with most of these solutions because the technology is still so new. Caveat emptor.
As you’ve seen in this chapter, the Dolphin product provides a very inexpensive solution for small wireless environments. It is very lightweight and has mammal hardware requirements; you most likely have an old PC stuffed in a storage room that could be turned into a dedicated wireless gateway by installing the Dolphin application on it.
On the up side, Dolphin is easy to use and configure, is inexpensive, and provides a relatively good amount of security for smaller organizations. In addition, Dolphin supports the creation of IPSec-secured VPN tunnels between the wireless clients and the Dolphin server. On the down side, Dolphin is limited in the number of users it can support as well as the number of groups you can create to classify users. Dolphin also does not provide for the use of an external RADIUS server. These limitations, however, are clearly stated by Reef Edge because Dolphin is not intended for commercial usage. If you have a small home or office wireless network that needs to be secured by an access-granting device, Dolphin might be an ideal choice for you.
Now that we’ve spent some time looking at the freeware Dolphin product, let’s step up the discussion and examine some more robust (and more costly) solutions that you might implement to secure a larger wireless network necessitating control over user access in a larger enterprise environment.
The Linksys WRV54G is an access point/router combination that Linksys designed for the small office, or home user that desires a higher level of security than WEP or WPA can provide. The W-RV54G offers all of the security features of other access points, but also provides the capability of setting up an IPSec VPN tunnel. A VPN tunnel allows two points to establish an encrypted session using a selected protocol. Other protocols can then be transmitted through this tunnel. A basic example of this is a Secure Shell (SSH) tunnel. A firewall can be configured to allow only SSH traffic (port 22) inbound. The client can then tunnel other traffic, such as HTTP (port 80) through the established SSH tunnel. This both encrypts the HTTP traffic, and removes the requirement to allow port 80 traffic through the firewall. Additionally, because some form of authentication (passphrase, key exchange, or both) is required to establish the initial SSH tunnel, additional user level access controls are in place.
This section describes the process of setting up an IPSec tunnel to utilize the VPN features on the WRKV54G. First, we discuss the steps that must be taken on Windows 2000 or XP clients to prepare for VPN access. Then, the configuration steps that are required on the WRKV54G are detailed.
There are four steps that you need to take to configure your Windows 2000 or XP computer to establish a VPN tunnel with the WRV54G.
Click Start | Run and type secpol.msc in the Open textbox to open the Local Security Settings screen, as seen in Figure 21.28.
Right-click IP Security Policies on Local Computer and select Create IP Security Policy to open the IP Security Policy Wizard. Click Next on the IP Security Policy Wizard window.
Enter a name for your security policy in the Name textbox (as shown in Figure 21.29) and click Next.
Remove the checkbox next to Activate the default response rule, as shown in Figure 21.30, and click Next.
Finally, make sure that the Edit properties checkbox is selected, as shown in Figure 21.31, and click Finish.
Selecting the Edit properties checkbox before finishing the IP Security Policy Wizard opens the Properties window for your new security policy (Figure 21.32).
Deselect the Use Add Wizard checkbox and click Add to open the New Rule Properties window. By default, this window opens on the IP Filter List tab. Click Add again to open the IP Filter List window. Enter a name for the filter, as shown in Figure 21.33. Deselect the Use Add Wizard checkbox and click Add.
The Filter Properties window opens on the Addressing tab. Choose My IP Address in the Source Address field and A specific IP Subnet in the Destination Address field. In the IP Address field enter 192.168.1.0. This represents all addresses in the range 192.168.1.1–192.168.1.255. If you are using a different range, make sure to adjust this accordingly. Enter the Subnet Mask for your network in the Subnet Mask field (see Figure 21.34). By default, this is 255.255.255.0. Click the OK button to close this window.
Next, click OK in Windows XP or Close in Windows 2000. This filter is used for communication from your computer to the router.
You will then need to create a filter for communication from the router to your computer. In the New Rule Properties window, highlight the rule you just created, as shown in Figure 21.35, and click Add.
This opens the IP Filter List window. Enter a name for the new filter in the Name textbox and click Add. On the Addressing tab, choose A specific IP Subnet in the Source Address field. In the IP Address field, enter 192.168.1.0. This represents all addresses in the range 192.168.1.1–192.168.1.255. If you are using a different range, you will need to adjust this accordingly. Enter the subnet mask for your network in the Subnet Mask field. By default, this is 255.255.255.0. Choose My IP Address in the Destination Address field (Figure 21.36).
Click the OK button to close this window. Next, click OK in Windows XP or Close in Windows 2000. This filter is used for communication from the router to your computer.
The rules that are employed by the tunnels must be set up in order to properly filter traffic through the VPN tunnel. First, select the tunnel you created for communication from your computer to the router and then click the Filter Action tab. Next, select the Require Security radio button and click Edit to open the Require Security Properties window, as shown in Figure 21.37.
Ensure that the Negotiate security radio button is selected. Then, deselect Accept unsecured communication, but always respond using IPSec and select Session key perfect forward security (PFS), as shown in Figure 21.38
Click OK to return to the New Rule Properties window. Select the Authentication Methods tab and click Edit to open the Edit Authentication Method Properties window. Choose the Use this string (preshared key) radio button and enter the pre-shared key in the textbox (Figure 21.39). This can be a combination of up to 24 letters and numbers, but special characters are not allowed. Make sure that you remember this key as it will be used later when the router is configured.
Next, click the OK button in Windows XP or the Close button in Windows 2000.
Select the Tunnel Setting tab on the New Rule Properties window. Select The tunnel endpoint is specified by this IP address and enter the external IP address of the WRV54G, as shown in Figure 21.40. This is the IP address your router uses to communicate with the Internet.
Next, click the Connection Type tab (as shown in Figure 21.41). Select All network connections if you want this rule to apply to both Internet and local area network (LAN) connections. Choose Local area network (LAN) if you want this tunnel to apply only to connections made from the local network. Choose Remote access if you want this rule to apply only to connections made from the Internet.
After you have selected the type of network connections that the rule applies to, click Close.
Another filter rule must be created to allow communication from the router to your computer. To create this rule, repeat the steps outline in this section, but enter the IP address of your computer as the Tunnel Endpoint instead of the IP address of the router.
Finally, you must assign your new security policy to the local computer. In the Local Security Settings window, right-click the new policy that you have just created and select Assign, as shown in Figure 21.42.
Your computer is now configured to communicate over a VPN tunnel.
Now that your computer is configured to communicate over an IPSec VPN tunnel, you must configure the WRV54G to communicate with your computer. Using your web browser, type the IP Address of the WRV54G into your address bar. This is 192.168.1.1, by default. You will be prompted for your username and password
From the setup screen, select Security | VPN to display the VPN settings, as seen in Figure 21.43.
Select the Enabled radio button for VPN Tunnel. Choose a name for this tunnel and enter it in the Tunnel Name textbox. Next, enter the IP address and netmask of the local network in the IP Address and Mask fields for the Local Secure Group. Use 192.168.1.0 to allow all IP addresses between 192.168.1.1–192.168.1.255.
Enter the IP address and netmask of the computer you just configured in the IP Address and Mask fields for the Remote Secure Group. Next, choose 3DES from the Encryption drop-down box. This requires the use of Triple Data Encryption Standard encryption. Choose SHA1 from the Authentication drop-down box.
Choose Auto(IKE) as the Key Exchange Method and select the Enabled radio button for PFS. This enables the use of Internet Key Exchange (IKE) and Perfect Forward Secrecy (PFS).
Finally, select the radio button next to Pre-Shared Key and enter the same pre-shared key you entered on your computer while setting it up.
Once you have entered these settings, your VPN setup screen should look similar to Figure 21.44.
Click Save Settings to save your settings and establish a VPN tunnel between the WRV54G and your computer.
The use of RADIUS servers to authenticate network users is a longstanding practice. Using RADIUS server dynamic per-user, per-session WEP keys combined with IV randomization is a fairly new practice. Another new addition is Cisco’s proprietary offering (now being used by many third-party vendors), Lightweight Extensible Authentication Protocol (LEAP).
LEAP is one of approximately 30 different variations of the Extensible Authentication Protocol (EAP). Other variants include Extensible Authentication Protocol-Message Digest Algorithm 5 (EAP-MD5), Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Extensible Authentication Protocol-Tunneled TLS (EAP-TTLS), and Protected Extenstible Authentication Protocol (PEAP). EAP allows other security products (such as LEAP) to be used to provide additional security to Point-to-Point Protocol (PPP) links through the use of special Application Programming Interfaces (APIs) that are built into operating systems and, in the case of the Cisco Aironet hardware, hardware device firmware.
LEAP (also known as EAP-Cisco Wireless) uses dynamically generated WEP keys, 802.1x port access controls, and mutual authentication to overcome the problems inherent in WEP. 802.1x is an access control protocol that operates at the port level between any authentication method (LEAP in this case) and the rest of the network. 802.1x does not provide authentication to users; rather, it translates messages from the selected authentication method into the correct frame format being used on the network. In the case of our example, the correct frame format is 802.11, but 802.1x can also be used on 802.3 (Ethernet) and 802.5 (Token Ring) networks, to name a few. When you use 802.1x, the choice of the authentication method and key management method are controlled by the specific EAP authentication being used (LEAP in this case).
Note
RADIUS is defined by Requests for Comments (RFC) 2865. The behavior of RADIUS with EAP authentication is defined in RFC 2869. RFC can be searched and viewed online at www.rfc-editor.org. 802.1x is defined by the IEEE in the document located at http://standards.ieee.org/getieee802/download/802.1X-2001.pdf.
LEAP creates a per-user, per-session dynamic WEP key that is tied to the network logon, thereby addressing the limitations of static WEP keys. Since authentication is performed against a back-end RADIUS database, administrative overhead is minimal after initial installation and configuration.
Through the use of dynamically generated WEP keys, LEAP enhances the basic security of WEP. This feature significantly decreases the predictability of the WEP key through the use of a WEP key-cracking utility by another user. In addition, the WEP keys that are generated can be tied to the specific user session and, if desired, to the network login as well. Through the use of Cisco (or other third-party components that support LEAP) hardware from end to end, you can provide a robust and scalable security solution that silently increases network security not only by authenticating users but also by encrypting wireless network traffic without the use of a VPN tunnel. (You can, however, opt to add the additional network overhead and implement a VPN tunnel as well to further secure the communications.)
Cisco LEAP provides the following security enhancements:
To put together a LEAP with RADIUS solution, you need the following components:
As shown earlier, our LEAP solution will look (basically) like the diagram shown in Figure 21.45.
Tools and Traps
Nothing in Life Is Perfect…
LEAP has two potential weaknesses that you need to be aware of.
The first weakness is that the EAP RADIUS packet transmitted between the AP and the RADIUS server is sent in cleartext. This packet contains the shared secret used to perform mutual authentication between these two devices. The reality of this weakness, however, is that you can mitigate its potential effects by having good network authentication policies for your wired network. Thus, an attacker would have to plug directly into a switch sitting between the AP and the RADIUS server and use a special network sniffing capable of sniffing over a switched network, such as dsniff.
The second weakness of LEAP is that the username is transmitted in cleartext between the wireless client and the AP. This opens the door to the possibility of a dictionary attack. Note that the password is encrypted using MS-CHAPv1. Your defense against a dictionary attack on your LEAP user’s passwords is to implement a solid login policy for your network. For example, if you are using Active Directory and performing network authentication against it using domain user accounts, you could require strong passwords through the Password Policy options and account lockout through the Account Lockout Policy options.
For more information on configuring Active Directory for enhanced security, see MCSE/MCSA Implementing and Administering Security in a Windows 2000 Network: Study Guide and DVD Training System (Exam 70-214) by Will Schmied (Syngress Publishing 2003, ISBN 1931836841).
To get started with your LEAP/RADIUS solution, you first need to install and configure the RADIUS server of your choosing. As previously stated, we’ll use Steel Belted RADIUS (SBR) for this purpose because it integrates tightly with Cisco LEAP. Perform the following steps to get SBR installed and configured for LEAP:
Once you’ve gotten your RADIUS server installed and configured, the hard work is behind you. All that is left now is to configure LEAP on the AP and client network adapter. To configure LEAP on the AP, perform the following steps. (Note that the exact screen will vary among the 350, 1100, and 1200 APs—the end configuration is the same, however. For this discussion, a Cisco Aironet 1100 AP is used with all configurations performed via the Web interface instead of the CLI.)
To enable the wireless client for LEAP, first ensure that it is using the most recent firmware and drivers. Once you’ve got the most up-to-date files, proceed as follows to get the client configured and authenticated using LEAP:
In the preceding sections, we only looked at creating native users in Steel Belted Radius. As mentioned, however, you can create AD domain users and authenticate directly against Active Directory. This offers many advantages, such as preventing dictionary attacks by enforcing account lockout policies. If you want to use domain user accounts for LEAP authentication, you need only perform the following additions and modifications to the procedures we outlined earlier in this chapter:
Now that you’ve had a chance to examine the workings of Cisco’s LEAP, you should see quite a few benefits to be gained through its use. LEAP, implemented with Funk Software’s Steel Belted Radius, is an ideal and very robust security solution for a wireless network of any size. By forcing users to authenticate to a back-end RADIUS server and creating per-user, per-session dynamic WEP keys, LEAP provides greatly enhanced authentication and security for your wireless network.
LEAP addresses all WEP’s vulnerabilities and is being implemented into the 802.11b standard by the Wi-Fi Alliance (www.wi-fialliance.org), which has implemented LEAP into its standards under the name of Wi-Fi Protected Access (WPA). You can read more about WPA at the Wi-Fi Alliance Web site. In addition, Cisco has licensed the LEAP technology to several third-party vendors, so you can expect to see many more LEAP-compatible devices in the near future. For example, Apple’s AirPort network adapter already supports LEAP with version 2 or better firmware.
To provide better security for wireless LANs, and in particular to improve the security of WEP, a number of existing technologies used on wired networks were adapted for this purpose, including:
These two services are used in combination with other security mechanisms, such as those provided by the Extensible Authentication Protocol (EAP), to further enhance the protection of wireless networks. Like MAC filtering, 802.1X is implemented at layer 2 of the Open System Interconnection (OSI) model: it will prevent communication on the network using higher layers of the OSI model if authentication fails at the MAC layer. However, unlike MAC filtering, 802.1X is very secure as it relies on mechanisms that are much harder to compromise than MAC address filters, which can be easily compromised through spoofed MAC addresses.
Although a number of vendors implement their own RADIUS servers, security mechanisms, and protocols for securing networks through 802.1X, such as Cisco’s LEAP and Funk Software’s EAP-TTLS, this section will focus on implementing 802.1X on a Microsoft network using Internet Authentication Services (IAS) and Microsoft’s Certificate Services. Keep in mind, however, that wireless security standards are a moving target, and standards other than those discussed here, such as the PEAP, are being developed and might be available now or in the near future.
Microsoft’s IAS provides a standards-based RADIUS server and can be installed as an optional component on Microsoft Windows 2000 and Net servers. Originally designed to provide a means to centralize the authentication, authorization, and accounting for dial-in users, RADIUS servers are now used to provide these services for other types of network access, including VPNs, port-based authentication on switches, and, importantly, wireless network access. IAS can be deployed within Active Directory to use the Active Directory database to centrally manage the login process for users connecting over a variety of network types. Moreover, multiple RADIUS servers can be installed and configured so that secondary RADIUS servers will automatically be used in case the primary RADIUS server fails, thus providing fault tolerance for the RADIUS infrastructure. Although RADIUS is not required to support the 802.1X standard, it is a preferred method for providing the authentication and authorization of users and devices attempting to connect to devices that use 802.1X for access control.
The 802.1X standard was developed to provide a means of restricting port-based Ethernet network access to valid users and devices. When a computer attempts to connect to a port on a network device, such as switch, it must be successfully authenticated before it can communicate on the network using the port. In other words, communication on the network is impossible without an initial successful authentication.
Two types of ports are defined for 802.1X authentication: authenticator or supplicant. The supplicant is the port requesting network access. The authenticator is the port that allows or denies access for network access. However, the authenticator does not perform the actual authentication of the supplicant requesting access. The authentication of the supplicant is performed by a separate authentication service, located on a separate server or built into the device itself, on behalf of the authenticator. If the authenticating server successfully authenticates the supplicant, it will communicate the fact to the authenticator, which will subsequently allow access.
An 802.1X-compliant device has two logical ports associated with the physical port: an uncontrolled port and a controlled port. Because the supplicant must initially communicate with the authenticator to make an authentication request, an 802.1X-compliant device will make use of a logical uncontrolled port over which this request can be made. Using the uncontrolled port, the authenticator will forward the authentication request to the authentication service. If the request is successful, the authenticator will allow communication on the LAN via the logical controlled port.
EAP is used to pass authentication requests between the supplicant and a RADIUS server via the authenticator. EAP provides a way to use different authentication types in addition to the standard authentication mechanisms provided by the Point-to-Point Protocol (PPP). Using EAR stronger authentication types can be implemented within PPP, such as those that use public keys in conjunction with smart cards. In Windows, there is support for two EAP types:
In a paper published in February, 2002 by William A. Arbaugh and Arunesh Mishra entitled “An Initial Security Analysis of the IEEE 802.1x Standard” the authors discuss how one-way authentication and other weaknesses made 802.1X vulnerable to man-in-the-middle and session-hijacking attacks. Therefore, while it might be possible to use EAP MD-5 CHAP for 802.1X wireless authentication on Windows XP (pre SP1), it is not recommended. EAP-TLS protects against the types of attacks described by this paper.
For 802.1X authentication to work on a wireless network, the AP must be able to securely identify traffic from a particular wireless client. This identification is accomplished using authentication keys that are sent to the AP and the wireless client from the RADIUS server. When a wireless client (802.1X supplicant) comes within range of the AP (802.1X authenticator), the following simplified process occurs:
Figure 21.70 shows a simplified version of the 802.1X authentication process using EAP-TLS.
When the authentication process successfully completes, the wireless station is allowed access to the controlled port of the AP, and communication on the network can occur. Note that much of the security negotiation in the preceding steps occurs on the 802.1X uncontrolled port, which is only used so that the AP can forward traffic associated with the security negotiation between the client and the RADIUS server. EAP-TLS is required for the process to take place. EAP-TLS, unlike EAP MD-5 CHAP, provides a mechanism to allow the secure transmission of the authentication keys from the RADIUS server to the client.
There are a number of significant advantages to using EAP-TLS authentication in conjunction with 802.1X:
For these reasons, using EAP-TLS for 802.1X authentication removes much of the vulnerability associated with using WEP and provides a high degree of assurance.
In the following section, we will look at how to configure 802.1X using EAP-TLS authentication on a Microsoft-based wireless network. If you are using other operating systems and software, the same general principles will apply. However, you might have additional configuration steps to perform, such as the installation of 802.1X supplicant software on the client. Windows XP provides this software within the operating system.
Before you can configure 802.1X authentication on a wireless network, you must satisfy a number of prerequisites. At a minimum, you need the following:
Notes from the Underground
Beyond ISA Server
Certificates issued by a Microsoft certification authority (CA) will work for wireless authentication. However, certificates issued by other CAs probably will not work. Certificates that are used for wireless 802.1 X authentication must contain an optional field called Enhanced Key Usage (EKU). The field will contain one or more object identifiers (OlDs) that identify the purpose of the certificate. For example, the EKU of a typical client certificate used for multiple purposes might contain the following values;
- Encrypting File System (1.3,6.1.4.1.311.103.4)
- Secure Email (1.3.6.1.5.5.7.3.4)
- Client Authentication (1.3.6.1.5.5.7.3.2)
The EKU of the certificate installed on the IAS server and the wire-less client for computer authentication will contain a value for server authentication (1.3.6.1.5.5.7.3.1). Because the EKU is an optional field, it might be absent on certificates issued by non-Microsoft CAs, rendering them useless for 802.1 X authentication in a Microsoft infrastructure. Furthermore, the certificate must contain the fully qualified domain name (FQDN) of the computer on which it is installed in the Subject Alternate Name field, and, in the case of certificates used for user authentication, the user principal name (UPN). You can confirm whether these fields and values exist by viewing the properties of the certificate in the Certificates snap-in of the MMC console. (Steps for loading this snap-in are detailed later in this chapter.) There are some other certificate requirements not mentioned here that must be also be satisfied. If you would like to use a third-party CA to issue client certificates for 802.1 X authentication, you should contact the vendor to see if it is supported for this purpose. If not, and you must use a third-party CA, you might need to look at solutions provided by other vendors of wireless hardware to use 802.1 X.
After configuring a PKI and installing IAS on your Windows 2000 network, there are three general steps to configure 802.1X authentication on your wireless network:
After deploying Active Directory, the first step in implementing 802.1X is to deploy the PKI and install the appropriate X.509 certificates. You will have to install (at a minimum) a single certificate server, either a standalone or enterprise certificate server, to issue certificates. What distinguishes a standalone from an enterprise certificate server is whether it will depend on, and be integrated with, Active Directory. A standalone CA does not require Active Directory. This certificate server can be a root CA or a subordinate CA, which ultimately receives its authorization to issue certificates from a root CA higher in the hierarchy, either directly or indirectly through intermediate CAs, according to a certification path.
Note
The certification path can be viewed in the properties of installed certification.
The root CA can be a public or commercially available CA that issues an authorization to a subordinate CA, or one deployed on the Windows 2000 net-work. In enterprise networks that require a high degree of security, it is not recommended that you use the root CA to issue client certificates; for this purpose, you should use a subordinate CA authorized by the root CA. In very high-security environments, you should use intermediate CAs to authorize the CA that issues client certificates. Furthermore, you should secure the hardware and software of the root and intermediate CAs as much as possible, take them offline, and place them in a secure location. You would then bring the root and intermediate CAs online only when you need to perform tasks related to the management of your PKI.
In deploying your PKI, keep in mind that client workstations and the IAS servers need to be able to consult a certificate revocation list (CRL) to verify and validate certificates, especially certificates that have become compromised before their expiration date and have been added to a CRL. If a CRL is not available, authorization will fail. Consequently, a primary design consideration for your PKI is to ensure that the CRLs are highly available. Normally, the CRL is stored on the CA; however, additional distribution points for the CRL can be created to ensure a high degree of availability. The CA maintains a list of these locations and distributes the list in a field of the client certificate.
Note
It is beyond the scope of this book to discuss the implementation details of a PKI. For more information, please see the various documents available on the Microsoft Web site, in particular www.microsoft.com/windows2000/technologies/security/default.asp, www.microsoft.com/windows2000/techinfo/howitworks/security/pkiintro.asp, and www.microsoft.com/windows2000/techinfo/planning/security/pki.asp.
Whether you decide to implement a standalone or an enterprise CA to issue certificates, you will need to issue three certificates: for both the computer and the user account on the wireless client, as well as the RADIUS server. A certificate is required in all of these places because mutual authentication has to take place. The computer certificate provides initial access of the computer to the network, and the user certificate provides wireless access after the user logs in. While the RADIUS server will authenticate the client based on the wireless client’s computer and user certificates, and the wireless client will authenticate the RADIUS server based on the server’s certificate.
The certificates on the wireless client and the RADIUS server do not have to be issued by the same CA. However, both the client and the server have to trust each other’s certificates. Within each certificate is information about the certificate path leading up to the root CA. If both the wireless client and the RADIUS server trust the root CA in each other’s certificate, mutual authentication can successfully take place. If you are using a standalone CA that is not in the list of Trusted Root Certification Authorities, you will have to add it to the list. You can do this through a Group Policy Object, or you can do it manually. For information on how to add CAs to the Trusted Root Certification Authorities container, please see Windows 2000 and Windows XP help files. The container listing these trusted root certificates can be viewed in the Certificates snap-in of the MMC console, as shown in Figure 21.71.
Using an enterprise CA will simplify many of the tasks related to certificates that you have to perform. An enterprise CA is automatically listed in the Trusted Root Certification Authorities container. Furthermore, you can use auto-enrollment to issue computer certificates to the wireless client and the IAS server without any intervention on the part of the user. Using an enterprise CA and configuring auto-enrollment of computer certificates should be considered a best practice.
If you put an enterprise CA into place, you will have to configure an Active Directory Group Policy to issue computer certificates automatically. You should use the Default Domain Policy for the domain in which your CA is located. To configure the Group Policy for auto-enrolment of computer certificates, do the following:
After you have configured a Group Policy for auto-enrollment of computer certificates, you can force a refresh of the group policy so that it will take effect immediately, rather than waiting for the next polling interval for Group Policy Changes, which could take as long as 90 minutes. To force Group Policy to take effect immediately on a Windows XP computer, type the command gpupdate/target: computer.
Note
On a Windows 2000 client, group policy update is forced by using the secedit/refreshpolicy command.
Once you have forced a refresh of group policy, you can confirm if the computer certificate is successfully installed. To confirm the installation of the computer certificate:
The next step is to install a user certificate on the client workstation and then map the certificate to a user account. There are a number of ways to install a user certificate: through Web enrollment: by requesting the certificate using the Certificates snap-in, by using a CAPICOM script (which can be executed as a login script to facilitate deployment), or by importing a certificate file.
The following steps demonstrate how to request the certificate using the Certificates snap-in:
You now should have a user certificate stored on the computer used for wireless access. However, this user certificate will not be usable for 802.1X authentication unless it is mapped to a user account in Active Directory. By default, the certificate should be mapped to the user account. You can verify if it has been mapped by viewing the Properties of the user account in Active Directory Users and Computers. The certificates that are mapped to the user account can be viewed in the Published Certificates tab of the Properties of the user account object.
After you configure certificate services and install computer and user certificates on the wireless client and a computer certificate on the RADIUS server, you must configure the RADIUS server for 802.1X authentication.
If you have configured RRAS for dial-in or VPN access, you will be comfortable with the IAS Server interface. It uses the same interfaces for configuring dial-in conditions and policies as does RRAS. You can use IAS to centralize dial-in access policies for your entire network, rather than have dial-in access policies defined on each RRAS server. A primary advantage of doing this is easier administration and centralized logging of dial-in access.
Installing an IAS server also provides a standards-based RADIUS server that is required for 802.1X authentication. As with configuring RRAS, you will need to add and configure a Remote Access Policy to grant access. A Remote Access Policy grants or denies access to remote users and devices based on matching conditions and a profile. For access to be granted, the conditions you define have to match. For example, the dial-in user might have to belong to the appropriate group, or connect during an allowable period. The profile in the Remote Access Policy defines such things as the authentication type and the encryption type used for the remote access. If the remote client is not capable of using the authentication methods and encryption strength defined in the profile, access is denied.
For 802.1X authentication, you will have to configure a Remote Access Policy that contains conditions specific to 802.1X wireless authentication and a Profile that requires the use of the Extensible Authentication Protocol (EAP) and strong encryption. After configuring the Remote Access Policy, you will have to configure the IAS server to act as a RADIUS server for the wireless AP, which is the RADIUS client.
Before installing and configuring the IAS server on your Windows 2000 or .NET/2003 network, you should consider whether you are installing it on a domain controller or member server (in the same or in a different domain). If you install it on a domain controller, the IAS server will be able to read the account properties in Active Directory. However, if you install IAS on a member server, you will have to perform an additional step to register the IAS server, which will give it access to Active Directory accounts.
There are a number of ways you can register the IAS server:
Note
Perhaps the simplest way to register the IAS server is through the netsh command. To do this, log on to the IAS server, open a command prompt, and type the command netsh ras add registeredserver. If the IAS server is in a different domain, you will have to add arguments to this command. For more information on registering IAS servers, see Windows Help.
Once you have installed and, if necessary, registered the IAS server(s), you can configure the Remote Access Policy. Before configuring a Remote Access Policy, make sure that you apply the latest service pack and confirm that the IAS server has an X.509 computer certificate. In addition, you should create an Active Directory Global or Universal Group that contains your wireless users as members.
The Remote Access Policy will need to contain a condition for NAS-Port-Type that contains values for Wireless-Other and Wireless-IEEE802.11 (these two values are used as logical OR for this condition) and a condition for Windows-Groups=[the group created for wireless users]. Both conditions have to match (logical AND) for access to be granted by the policy.
The Profile of the Remote Access Policy will need to be configured to use the Extensible Authentication Protocol, and the Smart Card or Other Certificate EAP type. Encryption in the Profile should be configured to force the strongest level of encryption, if supported by the AP. Depending on the AP you are using, you might have to configure vendor specific attributes (VSA) in the Advanced tab of the Profile. If you have to configure a VSA, you will need to contact the vendor of the AP to find out the value that should be used, if you can’t find it in the documentation.
To configure the conditions for a Remote Access Policy on the IAS server:
You can change the port numbers for RADIUS accounting and authentication by obtaining the properties of the Internet Authentication Service container in the IAS console. You can also use these property pages to log successful and unsuccessful authentication attempts and to register the server in Active Directory.
After installing certificates on the wireless client and IAS server and configuring the IAS server for 802.1X authentication, you will need to configure the AP and the wireless client. The following text shows the typical steps to complete the configuration of your wireless network for 802.1X authentication.
Generally, only enterprise-class APs support 802.1X authentication; this is not a feature found in devices intended for the SOHO market. Enterprise-class APs are not likely to be found in your local computer store. If you want an AP that supports 802.1X, you should consult the wireless vendors’ Web sites for information on the features supported by the APs they manufacture. Vendors that manufacture 802.1X-capable devices include: 3Com, Agere, Cisco, and others. The price for devices that support 802.1X authentication usually starts at $500 (USD) and can cost considerably more, depending on the vendor and the other features supported by the AP. If you already own an enterprise-class AP, such as an ORiNOCO Access Point 500 or Access Point 1000, 802.1X authentication might not be supported in the original firmware but can be added through a firmware update.
Regardless of the device you purchase, an 802.1X-capable AP will be configured similarly. The following text shows the typical configuration of 802.1X authentication on an ORiNOCO Access Point 500 with the most recent firmware update applied to it.
Note
For more information about the ORiNOCO device, see www.orinocowireless.com.
The configuration of the AP is straightforward and simple (see Figure 21.80). You will need to configure the following:
Depending on your AP, you might have to go through additional configuration steps. For example, you might have to enable the use of dynamic WEP keys. On the AP 500, this configuration is automatically applied to the AP when you finish configuring the 802.1X settings. Consult your AP’s documentation for specific information on configuring it for 802.1X authentication.
If you have been following the preceding steps in the same order for configuring 802.1X authentication, the final step is to configure the properties of the wireless interface in Windows XP. You will have to ensure that the properties for EAP-TLS authentication and dynamic WEP are configured. To do this, perform the following steps:
That’s it. You’re finished. The next time you attempt to authenticate and associate with the 802.1X-enabled AP, you might be presented with a prompt asking you to verify the identity of the IAS server certificate. By clicking OK, you will permit the authentication process to complete, thus allowing you secure access to the network.
Let’s briefly review the steps to enable 802.1X authentication. We are assuming that you are using Active Directory, already have a PKI in place, can issue certificates from a Microsoft CA, and have installed and registered (if necessary) an IAS server. Your steps would be as follows:
Although this might seem like a lot of work, the enhanced security provided by 802.1X might well justify the expense and effort of setting it up. Furthermore, much of the effort is up-front. Since you don’t have to worry about frequently rotating static WEP keys, you will realize significant savings in effort and time later.
802.1X authentication in combination with EAP-TLS is not the final word in wireless security. It mitigates many of the vulnerabilities associated with wireless networks, but other types of attacks might still be possible.
Corporate or SOHO wireless networks require a level of security that goes beyond the basics. They have an obligation to protect their business proprietary and customer data. There are many different technologies that can be utilized to accomplish this. WiFi Protected Access (WPA) addresses many of the flaws inherent in WEP. WPA can utilize the Advanced Encryption Standard (AES) to encrypt wireless network transmissions.
Corporate wireless networks should never be deployed without a virtual private network. There are countless commercial VPN products available. Reef Edge Dolphin is a freeware wireless gateway that can be deployed with VPN capabilities. For SOHO users that don’t have the time or the technical staff to deploy and configure a product like Dolphin, Linksys has developed the WRV54G VPN-Broadband Router. The WRV54G provides many enhanced security features. Designed specifically with the small business in mind, the WRV54G provides complete VPN support using IPSec tunnels.
802.1X was originally developed to provide a method for port-based authentication on wired networks. However, it was found to have significant application in wireless networks. With 802.1X authentication, a supplicant (a wireless work-station) needs to be authenticated by an authenticator (usually a RADIUS server) before access is granted to the network. The authentication process takes place over a logical uncontrolled port that is used only for the authentication process. If the authentication process is successful, access is granted to the network on the logical controlled port.
802.1X relies on the Extensible Authentication Protocol (EAP) to perform the authentication. The preferred EAP type for 802.1X is EAP-TLS. EAP-TLS provides the ability to use dynamic per-user, session-based WEP keys, thereby eliminating some of the more significant vulnerabilities associated with WEP. However, to use EAP-TLS, you must deploy a public key infrastructure (PKI) to issue digital X.509 certificates to the wireless clients and the RADIUS server.