Chapter 6: Designing the Wireless LAN Security Using 802.1X

On This Page

	Introduction
	Using 802.1X and Encryption to Secure WLANs
	Deciding on Certificates or Passwords
	Solution Prerequisites
	Considering WLAN Security Options
	Determining Software Settings Required for 802.1X WLANs
	Additional Considerations
	Summary

Introduction

This chapter describes the architecture and design of the 802.1X-based secure wireless network components for the wireless LAN (WLAN) solution. The chapter presents the design decisions involved with securing wireless network components and the reasoning behind those decisions.

A important goal of the chapter is to help you determine the suitability of the design for your own organization. Where there are alternative design choices available, other relevant options are given alongside the option used in this solution. To help you understand the implications of the step without you having to refer to other documents, some topics are more detailed than might otherwise be necessary.

Chapter Prerequisites

Before reading this chapter, you should be familiar with both 802.11 wireless local area network (WLAN) concepts, 802.1X network access control, Remote Authentication Dial-In User Service (RADIUS) concepts, Microsoft Internet Authentication Service (IAS), and  WLAN deployment options using Microsoft Windows XP Professional. You can familiarize yourself with these topics by reading the references listed at the end of this chapter in the “More Information” section. The Microsoft Windows Server™ 2003 Resource Kit and the Microsoft Windows Server 2003 Deployment Kit contain particularly valuable information.

Chapter Overview

The following flowchart illustrates the chapter structure.

Figure 6.1 Planning WLAN security using 802.1X

This chapter covers six main steps:

Top of page

Using 802.1X and Encryption to Secure WLANs

WLANs are becoming increasingly widespread with the adoption of industry standards such as IEEE 802.11 and 802.11b. WLANs allow users to roam around a building or campus and automatically connect to the network when they are in proximity to a wireless AP.

While providing convenience, WLANs pose the following security risks:

To counter the first security risk, you can configure IEEE 802.1X wireless APs as RADIUS clients to send access requests and accounting messages to RADIUS servers running IAS. IAS performs authentication of users and devices, and controls network access through centralized remote access policies.

To counter the second security risk, you can protect data sent between the wireless devices and the wireless APs by using 128-bit WEP encryption or WPA encryption capabilities built into 802.11 networking equipment.

Static WEP has serious design flaws and includes no native encryption key management to allow the keys to be regularly updated. This can expose encryption keys to determined malicious users. IAS enables strong WEP keys to be dynamically assigned to client computers running Windows XP during certificate-based authentication. In addition, WEP keys can be regenerated at regular intervals to thwart attack tools designed to discover those keys.

WPA is a subset of the forthcoming 802.11i security standard for 802.11-based WLAN equipment. WPA includes enhanced encryption designed to address security issues with static WEP. The solution presented in this guide also is suitable for use with WPA (this requires WPA capable hardware and an update to the Windows XP client).

Top of page

Deciding on Certificates or Passwords

Microsoft offers native support for several different authentication methods that you can use with the 802.1X protocol. Most commonly, organizations select WLAN client authentication methods based on either passwords or certificate-based credentials.

As stated earlier, the authentication method selected can have a significant effect on the infrastructure required for your solution. The 802.1X standard uses an authentication scheme called Extensible Authentication Protocol (EAP) that allows you to “plug in” different authentication types.

The following table illustrates the EAP types that you can use in a Microsoft 802.1X infrastructure, and the advantages and disadvantages of each type.

Table 6.1: Advantages and Disadvantages of EAP Types

The recommended EAP type for performing certificate-based client authentication is EAP – TLS, and the recommended EAP type for performing password-based client authentication is EAP – MSCHAPv2 within Protected Extensible Authentication Protocol (PEAP), also known as PEAP – EAP – MSCHAPv2.

Password-based 802.1X authentication using PEAP and MSCHAPv2 is a low cost and robust solution. It is suitable for organizations that do not currently have a certificate infrastructure in place and do not need certificates for other purposes, such as using the Encrypting File System (EFS) or a virtual private network (VPN). You can easily migrate from password-based 802.1X authentication to certificate-based authentication. This provides flexibility for your organization to later change from one authentication method to the other.

Note that even with a password solution using PEAP, a certificate is required on each RADIUS server. You should weigh the costs involved with purchasing server certificates from a commercial certificate provider against the value that a certificate infrastructure will bring to your organization.

This solution uses certificate-based client authentication because of the greater security level that the authentication method provides. The authentication method uses the Extensible Authentication Protocol – Transport Layer Security (EAP – TLS) protocol.

For guidance on how to deploy a password-based 802.1X solution that uses PEAP and MSCHAPv2, see the discussion in Chapter 2 "Deciding On a Secure Wireless Networking Strategy," and the reference at the end of this chapter to the companion solution guide, Securing Wireless LANs with PEAP and Passwords.

Top of page

Solution Prerequisites

It is important that you understand the prerequisites for the environment for this solution before starting the design. This section details these prerequisites.

Client Computer Requirements

This solution has been designed and tested using Windows XP Professional with Service Pack (SP) 1. Windows XP with SP1 provides certain 802.1X and WLAN feature functionality that is required to achieve an extremely low cost and easily managed solution.

Testing this solution included client computers running both Windows XP Professional and Windows XP, Tablet PC Edition. Both Windows XP editions provide automatic certificate enrollment and renewal of computer and user WLAN authentication certificates that are required for EAP-TLS client authentication. This feature alone significantly reduces the cost typically associated with certificates, and thus a certificate-based 802.1X solution.

Microsoft also provides 802.1X clients for Windows 2000 (available as a free download), and Windows 9x and Microsoft Windows NT 4.0 (available free of charge to customers with a support agreement). However, these client types were not tested in this version of the solution.

Required Server Infrastructure

This solution depends on the Certificate Services and IAS components of Windows Server 2003. There are features of Certificate Services and IAS that have been designed explicitly for 802.1X-based WLANs. Some of the features used in this solution include editable certificate templates and remote access policy settings that allow you to simplify deployment settings required for the 802.1X protocol.

The solution was designed with both Windows Server 2003 and Windows 2000 Active Directory environments in mind. However, the solution was tested only with Windows Server 2003 domain controllers. If you choose to, you can install IAS on to existing domain controllers. For a detailed discussion of co-location considerations related to this option, see Chapter 5, “Designing a RADIUS Infrastructure for Wireless LAN Security.”

Required WLAN Equipment

This solution assumes that your organization has already deployed a well designed and fully functional WLAN infrastructure. This guide does not include any instructions on wireless network design, such as wireless AP positioning and channel selection. If your organization has not deployed a WLAN infrastructure, ensure that you have the appropriate level of expertise available to accomplish this before you start deploying the WLAN security components.

The network hardware must support 802.1X, and 128-bit WEP for encryption. In this solution guidance, it is assumed that the WLAN infrastructure is operating without error, and that either no security controls are enabled, or only basic 802.11 security controls are enabled. Migrating from either a Shared Key (static WEP) WLAN or an Open System (unsecured) 802.11 WLAN to this solution is very similar. You should be able to accomplish either type of migration without any significant problems.

Top of page

Considering WLAN Security Options

If you have not already, you should spend time planning a WLAN security policy for your organization. Your planning discussions should include representatives from hardware purchasing, security policy, usability, network engineering, and network operations. Your security policy discussions with these people should include how your organization will address the threats it faces and what security controls you will use to mitigate them.

It is also important to document your WLAN security policy and make it available and visible to all of your network users. This solution provides security controls to mitigate the risk associated with modern WLAN technology. However, the solution cannot mitigate the risks of users in your organization who are performing unsecured, improvised networking, and deploying rogue wireless APs.

Selecting User- and Computer-Based Authentication

User authentication is a natural choice when considering identification to WLAN infrastructure. However, in most cases you also will want to implement computer (or device) authentication to ensure a comprehensive security solution for your WLAN.

There are a number of features in Windows XP Professional that will only work correctly with an active network connection. Using 802.1X computer authentication ensures that the WLAN network connection is established during the computer startup sequence before users see the initial Windows logon screen. The computer re-authenticates to the WLAN after the user logs off, ensuring that there is always a connection to the network.

Table 6.2: Reasons for using Computer Authentication

The best strategy is to use user–based authentication when possible, and computer-based authentication when required. This solution uses the default behavior of the Windows XP Professional 802.1X client. This is to perform computer authentication when no user is logged on at the computer console, user authentication when a user logs on to Windows, and computer authentication again when the user log off. This ensures that authentication to the network uses user account credentials where possible for accountability, while still it ensures that Windows features that require network access continue to work properly when no one is logged on.

Validating Certificate Based Credentials

It is important to check for valid credentials as part of your certificate-based WLAN authentication strategy. Checking for revoked certificates allows you to block the use of client certificates stored on lost or stolen computer equipment. Forcing clients to verify server certificates helps prevent sophisticated man-in-the-middle attacks involving rogue APs and RADIUS servers.

Windows provides extensive support for validating certificates when performing certificate-based operations. Both IAS and the Windows XP Professional 802.1X features use this support to ensure that the certificates used for EAP – TLS are valid and represent a trusted security principal.

Table 6.3: IAS Validation of Client Certificate Credentials

Windows XP Professional also performs the following IAS server credentials validation by default.

Table 6.4: Windows XP Validation of IAS Certificate Credentials

When authenticating to the WLAN, the client computer cannot perform a full revocation check of the server certificate, because network access is not available prior to the completion of a successful authentication.

You should also consider enabling the following additional credential validation options (that the client performs) to increase the security of the validity check.

Table 6.5: Advanced Windows XP Validation of IAS Certificate Credentials

Note that the subject name checking option on client computers will produce a trust decision prompt to users. In addition, you need to implement a management process to keep the permitted server certificate subject names up to date on the WLAN clients. You can do this using the Wireless Network Policies GPO settings. For these reasons, this solution does not implement this option. If you operate a high security environment, you may want to consider the threats that rogue IAS servers with wireless APs pose when deciding whether you need this extra level of validation.

Explicit selection of trusted root authorities minimizes the risk of forged server certificates from alternate CAs in the trusted root store. However, this setting requires an additional management process to ensure that changes to trusted root authority certificates are reflected in the WLAN client settings. These settings are also deployed using Wireless Network Policies GPO settings.

Determining Network Authorization Requirements

The key goals to achieve when designing network access management policies are to match organizational security policies as closely as possible and minimize management cost. A centralized representation of network authorization policy such as IAS remote access policies is well suited for this task.

Note: This solution uses network authorization administration through IAS remote access policy. For more information about the decisions involved to select a remote access policy administration model, refer to the resources listed in the “More Information” section at the end of this chapter.

Flexible yet simple management of network authorization should be a primary goal for any organization. Minimizing the number of remote access policies while still ensuring that all organizational security policies are represented is the key to achieving simplified management.

Determining Connection Criteria

IAS remote access policies can either allow or deny connections. A policy contains a set of criteria against which to match each connection attempt. The first policy found that matches a particular connection will be used to allow or deny access. The main connection attributes against which a policy can be matched are the following:

In addition, you can specify many other advanced filter criteria such as the following:

This solution uses IAS connection criteria based on domain security group and source network type (rather than time of day, authentication method, or other condition). This ensures that the remote access policies are created for a particular type of network access (such as, wireless, VPN, wired, or dial-up) and client grouping, while keeping the policy criteria broad enough to minimize the number of policies required.

Note: This solution uses custom security groups (Remote Access Policy – Wireless Users, and Remote Access Policy – Wireless Computers) to restrict which users and computers are allowed access to the WLAN. If you want all of your domain users and computers to be able to access the WLAN, you can add the Domain Users and Domain Computers groups to these custom security groups to simplify administration.

Determining Connection Restrictions

Once a connection is authorized, the remote access policy also specifies connection restrictions and other attributes to be applied to that connection. These include the following:

In addition, you can apply the following attributes to the connection:

One major determining factor for the number of remote access policies that your organization will require is the number of different user types who need access to the wireless network. For example, full-time staff in many organizations requires full, unrestricted access to the entire corporate network. However, contractors and business partners may only require access to specific applications on specific network subnets.

Connection restriction profiles are unique to each remote access policy. Therefore, if multiple types of connection restriction profiles are required, so are multiple remote access policies.

The following table illustrates examples of various types of users and the some of the connection restrictions that you can apply through remote access policy.

Table 6.6: Examples of WLAN Connection Restrictions

This solution only configures support for authenticated, full-time staff. Thus, only a single remote access policy with a simplified connection restriction profile is required. If your organization has additional requirements, such as a requirement to support restricted access users to the wireless network, you must add remote access policies to provide for this. See the references in the “More Information” section at the end of this chapter for more information about planning additional types of remote access policies.

Choosing a Client Configuration Strategy

Automating client computer configuration settings is an essential step to reducing the cost of deploying wireless networking security, and minimizing support issues that result from incorrectly configured settings.

Windows XP Professional has sophisticated features for reducing the need for manual configuration and reconfiguration of wireless network and 802.1X security settings on the WLAN clients. Windows Server 2003 adds the capability to completely automate client configuration using  the Wireless Networking Policies settings in Group Policy. This solution uses the Wireless Networking Policy feature in Windows Server 2003 to automatically configure all wireless network clients.

You can deploy  these GPO settings to client computers even before distributing WLAN network interface cards (NIC). This allows end users to simply install the wireless NICs and, using the WLAN settings deployed via the GPO, automatically connect to the secure 802.1X WLAN.

Determining Traffic Encryption Requirements

You should keep up to date on the evolving threats to 802.11 WEP encryption when determining your strategy for protecting your WLAN traffic. As discussed earlier, it is possible for determined malicious users to take advantage of cryptographic flaws in WEP to perform attacks that can disclose the WEP encryption key. To perform this kind of attack an intruder needs to capture several million packets that have been secured with the same encryption key.

The best strategy for mitigating threats to the security of a WEP-based WLAN is to ensure that keys used to encrypt network traffic are refreshed periodically. This can be done at a frequency that prevents an attacker ever being able to capture enough traffic to perform a successful attack. You can accomplish this by setting the IAS RADIUS options to enforce automatic client re-authentication, which initiates WEP key regeneration.

This solution configures IAS RADIUS options to enforce Windows XP client re-authentication every 10 minutes to ensure short-lived WEP session keys. This decision was based on known WEP attack tools and scenarios at the time of writing. Basic WEP encryption includes flaws such as poor initialization vector (IV) sequencing that an attacker can exploit to more quickly compromise keys. Ensure that your APs have the capability to generate less predictable and therefore stronger IVs.

Important: Using a session timeout of 10 minutes may be too short for many scenarios. Short timeouts place a high load on the IAS servers. Short timeouts also increase the possibility of making your IAS server temporarily unavailable, which will result in disconnecting clients from the WLAN. For these reasons, you can use a longer timeout of 60 minutes without significantly compromising the WLAN security.

The use of EAP – TLS ensures that unique WEP session keys are generated for each client during the TLS negotiation process, and that they are transported safely across the network between solution components. Unlike static WEP, the encryption keys are never reused and never shared between clients.

Choosing a WLAN Migration Strategy

If you have an existing wireless network in place, you should plan a migration strategy up front to ensure minimal disruption to users and the environment.

Studies have shown that many organizations have 802.11-based WLANs in place and are operating without network authentication or data protection. This type of 802.11 network security strategy is called Open System authentication. Other organizations have implemented static key network authentication and encryption. This type of 802.11 network security is also known as Shared Key authentication.

Migrations from Open System or Shared Key network security models to 802.1X security are very similar. The primary difference is that Shared Key security provides some security protection, thus migration schedules from Shared Key security may be more relaxed for some organizations.

Migration from either of these authentication strategies to the 802.1X security model typically involves the following steps:

As with all migration strategies, careful planning is essential. Configuring client computers and wireless APs erroneously can cause disruptive changes to your environment. You should test the intended changes thoroughly prior to deployment.

Note: Some wireless APs support configuring one 802.11 radio for static WEP security and another 802.11 radio for 802.1X. However, 802.11 channel separation issues may make this strategy impractical for many organizations.

Obtain commitment from your WLAN equipment vendors to support wireless AP and wireless NIC upgrades to WPA. Microsoft has released an update to Windows XP that provides support for WPA (it is included in SP2). Also, plan to upgrade your WLAN infrastructure in the future to support 802.11i, which will likely require you to update the firmware on your APs and wireless NICs.

This guidance does not include detailed migration planning for production WLANs that use proprietary security or Open System/Shared Key security. For assistance with detailed migration planning from production WLANs, see your Microsoft partner or contact your Microsoft Account Executive who can connect you with the appropriate partner or Microsoft Consulting Services professionals.

Wireless Network Infrastructure Design

General discussion on 802.11-based WLAN equipment and network design is beyond the scope of this guidance. The WLAN chapter in the Microsoft Windows Server 2003 Deployment Kit provides general guidance on this topic.

Effort has been made to ensure that this solution will work on a broad variety of products from various network equipment vendors. Configuration planning and procedures for specific wireless AP products is beyond the scope of this solution.

However, when you decide on the security settings and security management of your 802.11 equipment, educate yourself on the following topics by using documentation available from your hardware manufacturer:

For assistance with these topics and wireless AP configuration, consult your vendor documentation or enlist the assistance of an equipment specialist. Some of these items are discussed in the "802.11 Wireless Network Technical Reference" topic in the Windows Server 2003 Technical Reference in the "More Information" section at the end of this chapter.

Wireless Network Group Policy Considerations

Consult with your domain GPO administrators to determine the strategy for applying Wireless Network Group Policy to client computers. The following table lists the key items that you need to decide on for your own environment and the settings that have been selected in this solution.

Table 6.7: Wireless Network Policy Planning

Note: This solution grants a custom security group (Wireless Network Policy – Computer) "Apply Policy" permission on the "Wireless Network Policy" GPO. Membership of this group therefore determines which computers receive the WLAN GPO settings. If you want to allow all computers to receive the WLAN configuration settings, you can add the Domain Computers or Authenticated Users group to this group to simplify administration. However, you should be aware that doing this will apply the policy settings to all servers and clients in the domain (Domain Computers) or forest (Authenticated Users).

This solution uses a simple Wireless Network policy management strategy by creating a single GPO linked to the domain object. This means that any computer in the domain who is also a member of the "Wireless Network Policy — Computer" group will receive the policy settings. You may want to consider more sophisticated Group Policy management standards and apply your Wireless Network policies accordingly. Most organizations, however, will need only one Wireless Network Policy GPO (although you may choose to link it to a location other than the domain object).

Top of page

Determining Software Settings Required for 802.1X WLANs

There are two major software solution components that you must configure to achieve 802.1X WLAN security:

IAS network access policy is at the heart of your network access management solution. Settings that represent your WLAN security policy are deployed on each IAS-based RADIUS server in an automated fashion. This policy includes settings for:

Remote access policies enforce access to your networks via your wireless APs. Connection request policies determine the handling of RADIUS requests from various wireless APs configured as RADIUS clients.

Active Directory Group Policy for client computers contains all of the settings that will be deployed to Windows XP-based client computers. This Group Policy affects client interaction with the wireless APs, the RADIUS server, and other wireless networks.

Configuring Remote Access Policies

You must plan the creation of remote access policies on IAS servers to satisfy your organizational wireless network access strategy. Creating and configuring remote access policies involves establishing the following three setting types for each policy:

This solution uses a single remote access policy that grants unrestricted access to the wireless network for full-time employees. The following table details the remote access policy conditions for this solution.

Table 6.8: Remote Access Policy Conditions

The policy permission for the remote access policy in this solution is set to Grant, and user accounts are configured with the Control access through Remote Access Policy setting.

The following table details the remote access policy profile options that this solution uses. You may need to add additional settings to suit your particular environment.

Table 6.9: Remote Access Policy Profile Options

Important: Using a session timeout of 10 minutes may be too short for many scenarios. Short timeouts place a high load on the IAS servers. Short timeouts also increase the possibility of making your IAS server temporarily unavailable, which will result in disconnecting clients from the WLAN much sooner. For these reasons, you can use a longer timeout of 60 minutes without significantly compromising the WLAN security.

Configuring Connection Request Policies

You should plan how IAS will handle RADIUS requests when it is operating as a RADIUS server and as a RADIUS Proxy. Discussion of selecting the RADIUS role for IAS appears in Chapter 5, “Designing a RADIUS Infrastructure for Wireless LAN Security.”

Regardless of which role you select for the IAS server, you must configure the following components of the connection request policies before you can achieve wireless network access:

This solution uses IAS as a RADIUS server, thus connection requests are processed locally on each server. The settings in the following table illustrate policy conditions configured in the connection request policy for this solution.

Note: The connection request policy settings in this solution use the defaults that install with IAS in Windows Server 2003.

Table 6.10: Connection Request Policy Conditions

The following table illustrates profile settings used in the connection request policy for this solution.

Table 6.11: Connection Request Policy Profile Settings

Configuring Group Policy for Client Computers

Planning is required prior to using Active Directory Group Policy to configure WLAN settings and 802.1X security settings on client computers via Wireless Network (IEEE 802.11) Policies. This section details a number of the settings in this solution and the reasons to include them. You will find the Wireless Network (IEEE 802.11) Policies on the \Computer configuration\Windows Settings\Security Settings\Wireless Network (IEEE 802.11) Policies object within the Group Policy Object Editor.

Configuring Wireless Network Settings

You configure WLAN settings by editing the properties of the WLAN policy objects within Group Policy. These include the following setting types:

The following table illustrates general settings in the Wireless Networks Policy for this solution.

Table 6.12: Wireless Network Policies General Settings

You must create an entry for your 802.1X WLAN SSID on the Preferred Networks tab in the Wireless Networks Policy. Once a preferred network is created, you must edit the network properties from the defaults.

The following table details network properties settings for the newly enabled 802.1X network in the Wireless Networks Policy for this solution.

Table 6.13: Wireless Network Policy Properties Settings

Configuring 802.1X Settings on Client Computers

You configure 802.1X settings via your Wireless Network Policy, which includes the following setting types:

The following table details 802.1X settings for the newly enabled 802.1X network in the Wireless Networks Policy for this solution.

Table 6.14: Wireless Network Policy 802.1X Settings

The following details the EAP settings for the newly enabled 802.1X network in the Wireless Networks Policy for this solution.

Table 6.15: Wireless Network Policies EAP Settings

The following table details computer authentication settings for the newly enabled 802.1X network in the Wireless Networks Policy for the solution.

Table 6.16: 802.1X Computer Authentication Behavior Options

Top of page

Additional Considerations

This section briefly mentions additional topics to consider that are outside the scope of this solution but that may have an impact in your environment.

Supporting Roaming Profiles and Roving Users

EAP–TLS-based 802.1X components of Windows depend on certificates and private key information being available within the certificate store on your client computers. For most organizations, wireless users have portable computers or Tablet PCs that travel with them, and thus the certificates and key information is always available.

However, if your WLAN strategy includes users who share computers, you will want to consider implementing roaming profiles. You can use roaming profiles to ensure that private key information and certificates are always available for use within your 802.1X-based environment.

Alternatively, Wireless Network Policy allows you to configure computers running Windows XP to perform computer-only authentication. Although not implemented in this solution, this may be useful for some organizations.

Supporting Clients Without Wired LAN Connections

Although not common for large organizations, some environments may not have a wired LAN at all. Wired LAN infrastructure is required to join client computers to a domain, and receive certificates and Group Policy. Without computer and user certificates, and appropriate client WLAN configuration, users cannot access the 802.1X-based WLAN. This issue also arises when an organization has deployed a wired network that always requires 802.1X authentication.

If you have such an environment, you should consider a strategy whereby users provide a password-based credential using PEAP-MSCHAPv2 to the RADIUS server for connection to a controlled VLAN with the Certificate Services Web enrollment pages. From there, users can enroll and install certificates to gain full access to the corporate WLAN using EAP – TLS. Such a strategy is currently outside the scope of this solution and would require an additional remote access policy on the IAS servers, in addition to specific VLAN design.

Top of page

Summary

This chapter described the process of designing WLAN security using the 802.1X protocol, which included determining WLAN prerequisites, considering security options, establishing strategy, and additional considerations. Once you have established your design based on the options discussed in this chapter, you are in a position to deploy 802.1X-based WLAN security in your environment.

The design in this chapter will be used in the later Build and Operations chapters for this solution to implement the 802.1X WLAN security infrastructure.

More Information

For more information about secure wireless networking, see the following resources:

Top of page