Secure Wireless Access Point Configuration

On This Page

	Introduction
	Definition
	Challenges
	Solutions
	Summary

Introduction

Welcome to this document from the Midsize Business Security Guidance collection. Microsoft hopes that the following information will help you create a more secure and productive computing environment.

Executive Summary

Wireless local area networks (WLANs) are a controversial topic in the business world; most businesses have either already deployed a WLAN of some sort or have at least debated the pros and cons of wireless technology. Either way, businesses that have deployed wireless networks usually have many concerns about the security of their solution whereas businesses that have shied away from wireless technology worry about the obvious productivity and infrastructure savings they may have missed.

Most technology decision makers have been rightfully nervous about the security of wireless technology in the past and even today wireless technology suffers from the stigma of not being secure ever because well publicized flaws were discovered in the first generation of IEEE 802.11 WLAN security protocols. Even though many workarounds have been developed through the years, the typical solutions offered to address wireless security issues have either been too costly or have had their own inherent flaws.

Many developments have occurred because those early days of wireless networks and just as the technology have matured to allow for higher speeds and more reliability, so too have the standards used to secure wireless transmissions. The latest wireless security protocols, WPA and WPA2, based on the IEEE 802.11i standard, help provide strong protection for wireless traffic even in the most rigorous security environments. These current standards, when configured properly, are much more secure and can be used with a high level of confidence in a midsized business environment.

Overview

This paper consists of four main sections that focus on details that are necessary to design and implement an effective solution for securing a midsize business wireless network. These sections include:

Who Should Read This Paper

This paper is targeted to midsized business technical staff, technology implementers, and technical managers who are considering using Wi-Fi Protected Access (WPA) or Wi-Fi Protected Access 2 (WPA2) to secure their wireless infrastructure. This document assumes the reader has general technical knowledge regarding wireless devices, basic networking concepts, Microsoft® Windows Server™ 2003, Internet Authentication Service (IAS), Certificate Services, the Active Directory® directory service, and the configuration and application of Group Policy.

Top of page

Definition

The reader should understand and be familiar with the following terms and concepts that are used in this document.

AES. Advanced Encryption Standard (AES) uses a symmetric block data encryption technique and is part of WPA2.

EAP. Extensible Authentication Protocol (EAP) is an 802.1X standard that allows developers to pass authentication data between RADIUS servers and wireless access points. EAP has a number of variants, including: EAP MD5, EAP-TLS, EAP-TTLS, LEAP, and PEAP.

EAP-TLS. EAP Transport Layer Security (EAP-TLS) was developed under the 802.1X standard by Microsoft to use digital certificates for authentication and is currently the industry standard for 802.11i authentication.

IEEE 802.1X. The IEEE 802.1X governs the EAP encapsulation process that occurs between supplicants (clients), authenticators (wireless access points), and authentication servers (RADIUS).

IEEE 802.11. The IEEE 802.11 standard governs over-the-air network communications and includes several specifications that range from the 802.11g, which provides 20+ Mbps traffic in the 2.4 GHz band, to the 802.11i standard, which governs WPA2 encryption and authentication.

IEEE 802.11i. The IEEE 802.11i amendment to the 802.11 standard specifies security methods (WPA2) that make use of AES block cipher to secure origin authentication processes (EAP) to address previous inadequacies in the wireless security standards and specifications.

MS-CHAP v2. Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) is a password-based, challenge-response, mutual authentication protocol that uses MD4 and DES encryption. Used with PEAP (PEAP-MS-CHAP v2) to secure wireless communication.

PEAP. Protected Extensible Authentication Protocol (PEAP) is a type of EAP communication that addresses security issues associated with clear text EAP transmissions by creating a secure channel encrypted and protected by TLS.

SSID. Service set identifier (SSID) is the name given to a WLAN and used by the client to identify the correct settings and credentials necessary for access to a WLAN.

TKIP. Temporal Key Integrity Protocol (TKIP) is part of the WPA encryption standard for wireless networks. TKIP is the next generation of WEP, which provides per-packet key mixing to address flaws discovered in the WEP standard.

WEP. The Wired Equivalent Privacy (WEP) is part of the IEEE 802.11 standard and uses 64 or 128 bit RC4 encryption. Serious flaws were found in the WEP standard in 2001, mostly due to the length of the initialization vector of the RC4 stream cipher, which allowed for passive decoding of the RC4 key.

WLAN. Wireless local area network.

WPA. In response to weaknesses found in the WEP standard the Wi-Fi Protected Access (WPA) was introduced in 2003 as an interoperable wireless security specification subset of the IEEE 802.11 standard. This standard provides authentication capabilities and uses TKIP for data encryption.

WPA2. WPA2 was established in September 2004 by the Wi-Fi Alliance and is the certified interoperable version of the full IEEE 802.11i specification ratified in June 2004. Like its predecessor, WPA2 supports IEEE 802.1X/EAP authentication or PSK technology but includes a new advanced encryption mechanism using Counter-Mode/CBC-MAC Protocol (CCMP) called the Advanced Encryption Standard (AES).

Top of page

Challenges

Many organizations see the benefits of using wireless technology to improve productivity and collaboration but hesitate to implement this technology due to understandable concerns about the vulnerabilities that wireless networks apparently present to an organization’s environment. Even more confounding are the wide variety of suggested methods that can be used to help secure wireless communications and mixed reports as to the effectiveness of these measures.

Wireless technology poses many challenges to a midsized business, not only as a matter of securing a deployment, but also a question of whether to deploy it at all. The following are some of the more common issues regarding wireless networking that this paper will address.

Top of page

Solutions

This section describes the design, development, implementation, and support of secure wireless solutions that can be deployed in midsized business environments. As mentioned in previously, there are many concerns about the use of wireless technology. Each of those will be addressed so that the benefits of wireless networking can be taken advantage of as efficiently and safely as possible.

Assessing WLAN Security

Although wireless technology has now matured to the point that it is now fast and secure enough to be deployed in a midsized business environment, there are still many different factors to consider and a variety of methods available to secure a wireless network. This section discusses many common methods used to help secure wireless networks, offers guidance to determine the best solution for a particular environment, and provides arguments for and against each approach.

Benefits of Wireless Networking

The benefits that can be gained by implementing WLAN technology can be placed within two distinct categories: business benefits and operational benefits. Operational benefits include a lower management cost and reduced capital expenditures whereas business benefits include improved productivity, more efficient business processes, and an increased potential for the creation of new business functions.

Business Benefits

Most core business benefits derived from the use of WLAN technology stem from an increase in employee flexibility and mobility. When using wireless networks the workforce is no longer tethered to a desk and can move around the office with relative ease. This kind of freedom can generate the following benefits:

Operational Benefits

The operational benefits of wireless technology are also varied and depend on the specific type of business and the facilities used. Some of these benefits include:

Wireless Networking Vulnerabilities

To understand the level of security offered by the various security solutions available to wireless networks it is important to understand the common threats that wireless networks can face. The vulnerabilities and attack profiles that traditional networks must address are widely known, but wireless networks suffer from vulnerabilities that go beyond these traditional risks.

Table 1. Typical WLAN Security Threats

Although many of these security risks associated with transmitting data over the air are fairly apparent in today’s security-conscious environment, such concerns were not as obvious when the first generation of wireless security technology was established. When WEP was created to secure wireless data broadcasts there seemed to be little need to compensate for the inherent lack of security in comparison with the inherent security that comes with transmitting data over the wire because the technology was so new that few people had considered the possible threats such networks could face. As the methods that attackers use evolved it became clear that data transmission over the air traversed potentially hostile environments and must be secured as such and made as secure as cabled LAN communications.

When the WEP security flaws started to become widely publicized, the network security environment was changing rapidly. Stories of War-Drivers were prominent in mainstream media while governments implemented legislation to regulate industries in regard to data and identity security. In response to these developments, many businesses either dismissed wireless technology as unfeasible and unsafe or developed complex workarounds to address the flaws inherent in the WEP standard.

Some of these complex workaround solutions are still used and even marketed to this day. However, as the following sections make clear, such complex solutions are no longer required to secure wireless networks against such threats and may need to be reevaluated because wireless technology has matured in response to the changing security landscape.

Selecting the Right WLAN Security Solution

Ever since the first generation WLAN technological weaknesses were revealed there has been a great deal of effort to address wireless vulnerabilities. While the wireless industry, Microsoft, and other vendors focused on improving the wireless standard, many other analysts, network security vendors, and others were finding ways to work around the weaknesses in the older wireless standard. This has led to a variety of approaches available to deal with wireless security issues.

Aside from the most common approach, which is deciding not to implement WLAN technology, the principle alternatives are compared in the following table.

Table 2. Comparison of WLAN Security Approaches

Note   Regarding strong authentication, many VPN implementations that employ IPsec tunnel mode use a weak shared key authentication scheme called XAuth.
Current versions of the Windows operating system do not support user authentication of IPsec associations but this functionality will be available with Windows Vista and Longhorn.
Computer authentication means that the computer will stay connected to the WLAN and LAN even when no user is logged on to the computer. This capability is needed for some domain-based functionality, such as roaming profiles, to work properly.

As this table demonstrates, there are a number of factors to consider when examining the varied possibilities available for securing wireless networks. Such an evaluation involves everything from costs associated with implementation and management to the general security of the solution in question. Each approach has benefits and detractors and so each solution requires a more detailed examination to ensure that an informed decision can be made.

To facilitate a better understanding of the options available for securing WLAN implementations, the following topics are discussed in detail, arranged by the degree of security they provide.

Not Deploying WLAN Technology

There is a common maxim among security professions that states, “The most secure system is the one that is never turned on.” So the most secure method of deploying any technology, including wireless networking, is never to deploy it. Of course, the problem with this approach is that a business that never uses any technology may find itself uncompetitive in today’s business world in which every advantage, especially in regards to technology, counts.

As mentioned previously it is important for every company to assess their own needs, their tolerance for risk, and the amount or risk involved with any technology that is under consideration for adoption, and wireless technology is no different. There are many advantages that wireless networks can offer, but those advantages might be undervalued or not even applicable to a specific organization.

When assessing the appropriate wireless security solution for a business, take all options into consideration, including the option not to deploy a wireless solution at all. However, should an organization determine that it is not ready to deploy a WLAN, this decisions should be part of an actively enforced company policy to prevent rogue WLANs from being deployed by end users and thus compromising network security.

Using WPA with EAP-TLS

WPA or WPA2 with Extensible Authentication Protocol Transport Layer Security (EAP-TLS) with both user and computer certificates is the strongest method of 802.1X authentication supported by current versions of Windows–based wireless clients. EAP-TLS uses digital certificates to provide mutual authentication, in which the wireless client authenticates to the authentication server and vice-versa. EAP-TLS authentication requires a public key infrastructure (PKI) to issue certificates and keep them current. For the highest level of security the PKI should be configured to issue both user and computer certificates for wireless access.

Because of the implementation costs and administrative overhead associated with PKIs, this very secure solution used to be limited to midsized or large businesses but can now be used in small business environments due to the introduction of Microsoft Small Business Server, which provides the underlying certificate services that implementing EAP-TLS requires.

Note   Currently there is no supporting Group Policy objects (GPOs) for the WPA2 standard that can affect the ability to efficiently implement this standard in larger environments. However, updates are being developed for Windows Server 2003 and Windows XP to add GPO support for WPA2. The next generation of Windows, Vista and Longhorn, will have native support for the WPA2 standard.

Using WPA with PEAP-MS-CHAP v2

WPA or WPA2 with Protected EAP (PEAP) and Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) with strong password requirements is the second most effective secure implementation supported by current versions of Windows–based clients. If a PKI deployment is not feasible, PEAP-MS-CHAP v2 is a viable and secure option for deploying a reliable wireless network. PEAP is a one-way authentication scheme that uses TLS to create an encrypted channel from the authentication server, over which the client uses another protocol to authenticate itself. Originally designed for dial-up and VPN remote access, MS-CHAP v2 can support strong password-based authentication of wireless clients but only when used in conjunction with the use of strong user password policies on the network.

Using WPA with PEAP-MS-CHAP v2, and Certificate Services

It is possible to combine the use of certificate services with a password-based PEAP-MS-CHAP v2 solution for businesses that need elements of both approaches in their solution. However, the addition of PEAP-MS-CHAP v2 does not add any recognized additional security benefit of note to the reasonably secure EAP-TLS solution, as of the writing of this document. In fact, using PEAP-MS-CHAP v2 with EAP-TLS actually slows down the authentication process because it creates two TLS channels, one inside the other. This double encryption provides no added value.

Using a VPN

When WEP security flaws were first discovered, one of the first responses proposed by many security experts and industry leaders was to use VPNs to secure wireless networks. VPN technology is certainly a secure and time-tested method of protecting network communications that traverse over hostile networks, like the Internet, and this solution to the problem of WEP flaws is still used in many environments.

Although this seems like an advantageous solution from a security standpoint, it suffers from some obvious flaws that make it an unattractive option when compared to the flexibility offered by solutions using WPA, which was designed specifically to address wireless threats. Even though it is quite possible to implement WPA solutions in combination with VPN technology to help secure a wireless network, such a solution provides no advantage over a pure WPA-based solution, especially when factoring in the additional layer of complexity added to a wireless network when a VPN solution is introduced into the mix.

Usability is another issue to consider when debating whether to add a VPN as part of a WLAN security solution. Although the additional authentication requirements and time-out limits associated with VPN usage are expected by users when connecting to a business network over the Internet, such extra steps may seem onerous to a user who is used to connecting easily to resources from inside a local area network.

Some businesses may want to use this solution simply because they already have a VPN solution in place for remote users and feel it necessary to press more utilization through that system to further justify costs. If this is the case, additional issues should be considered before choosing this route, including the following:

Using IPsec

The use of IPsec to secure wireless networks originated out of the same need as the use of VPNs to secure WLANs, as a workaround for the flaws found in WEP. Of course, IPsec is reliable way to secure many specific kinds of network traffic and has some points for its use on WLANs, among these are its transparency, its independence from WLAN hardware constraints, and its low overhead because it does not require additional servers or software to function.

However, there are some problems associated with using IPsec to secure wireless networks, some of which include:

Using WEP

The most basic form of 802.11-based security is static WEP, which uses a shared key to control access and uses that same key as a base for encrypting wireless traffic. The main attraction of this method is its simplicity and although it does provide a slight increase of security over an unprotected wireless setup, it suffers from some serious management and security problems, namely that it can take anywhere from a couple minutes to a few hours of effort to discover the shared key and SSID (if it isn’t broadcasted) on a WEP WLAN and thus gain access to a network using an ordinary laptop and simple tools readily available on the Internet.

One way of improving upon static WEP is to configure access points to allow only a predefined group of clients to access the network by using MAC filtering. However, this approach is also easily attacked by using tools to discover and spoof the MAC addresses of computers attached to a WLAN.

It is possible to use some combinations of security technologies with WEP to increase security somewhat in environments that do not have WPA or WPA2 support, but even these configurations are discouraged except for use during a transition phase between an unsecured WLAN implementation and a secure WPA-based configuration. These methods, in order of most to least secure, are as follows:

No WLAN Security

Although implementing an unsecured wireless network should never be recommended for just about any midsized business environment, there are still some select few situations in which an unsecured wireless network configuration may be a preferred solution. For example, many cities and municipalities have considered or even implemented free wireless access zones and in such a situation it may be preferred to use a network of unsecured wireless access points that only provide direct connections to the Internet. However, for all intents and purposes, it should be understood that unsecured wireless networks are incredibly vulnerable to a wide variety of attacks.

WPA or WPA2

The Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access 2 (WPA2) protocols are both designed specifically to address the threats against IEEE 802.11–based wireless networks. However, there are some differences between the two protocols. WPA was developed in 2003 as a response to the security flaws discovered in the WEP standard and addressed those flaws quite well by implementing support for mutual authentication, using TKIP for data encryption, and incorporating a signed message integrity check to thwart spoofing and replay attacks. WPA2 improves upon that security by using AES instead of TKIP to secure network traffic, thus it should always be a preferred over the WPA standard.

Both WPA and WPA2 are vastly more secure than WEP and, when properly secured, there are no currently known security flaws for either protocol. However, WPA2 is still widely considered to be more secure than WPA and when possible WPA2 should be used so long as the infrastructure supports it and the additional management overhead can be mitigated.

Most wireless access devices made today support are WPA2 certified as are the most recent versions of Windows, specifically Windows XP with Service Pack 2 (SP2) and Windows Server 2003 with SP1. Wireless devices and clients that support WPA2 are also able to use the older WPA standard in case some wireless access points or clients currently deployed in an environment do not support WPA2.

Note   Windows XP SP2–based clients require an additional update package, the Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) Update, to enable support for WPA2 certification. For more information about this update, see http://support.microsoft.com/default.aspx?scid=kb;en-us;893357.
Also, current versions of Windows do not have GPO support for WPA2, which is a considerable management disadvantage that makes WPA2 implementation much more complex than WPA. This may be a determining factor in choosing between WPA or WPA2 because both standards are relatively secure.

Developing a Secure WLAN Solution

The previous section helped explain some of the background history surrounding the different WLAN security options available for consideration along with an explanation of the common threats wireless networks face and how each approach either deals with or is vulnerable to those threats. With that information it is possible to make informed decisions in regards to how each options may be applied to specific business environments.

The latest security enhancements made to the wireless network standards with the implementation of WPA and WPA2 have addressed the serious flaws in WEP and thus have marginalized the need for workarounds such as using IPsec or a VPN to secure wireless connections. The options of using static or dynamic WEP are not recommended in any form and the use of no security functionality is only useful in few situations. Given these assumptions, there are only a couple options still open to consideration when formulating a comprehensive and efficient security solution for WLAN implementations.

This section serves to guide decision makers through the remaining recommended approaches to securing wireless networks. These Microsoft-recommended solutions are widely accepted by industry analysts, security experts, and leading vendors as the most secure methods of implementing a secure and efficient wireless network. Even though this paper will focus on the method that applies best to a midsized business environment, it is still important to consider all the options and step through a decision making process because there are always valid exceptions to the rule.

The Microsoft Secure WLAN Decision Process

There are two recommended WLAN security processes to choose from along with a third mixed approach. The two main solutions, arranged by level of security, are:

Aside from the level of security that each provides, the basic deciding factor between these two approaches boils down to resources required to implement and support each solution.

WPA or WPA2 with PEAP-MS-CHAPv2 has fewer requirements in terms of technical expertise and equipment because it does not require an underlying certificate infrastructure. Because all devices currently on the market are WPA2 certified and not very cost prohibitive it makes some sense to use devices that support WPA2 even if WPA is selected for use due to the current administrative advantage it has over WPA2. The WPA2 AES encryption method is widely considered to be more secure than WPA’s TKIP and with GPO support for WPA2 planned for future release it makes sense to have the foundation in place for WPA2 implementation in the future.

Using WPA or WPA2 with EAP-TLS is the most secure option available for securing a WLAN but has higher implementation and management costs associated due to its reliance on the underlying certificate infrastructure. However, many midsized business environments already have the systems in place that meet the necessary requirements for WPA2 with EAP-TLS so this may actually be a more attractive option for many businesses. Even without the requisite technology in place, many businesses have other needs for the same technology that this solution relies on, certificates and RADIUS, so even then there are some very good business and technical reasons to implement this solution.

Figure 1. The Microsoft WLAN Decision Tree
See full-sized image

The flowchart in figure 1 has been used in previous guidance from Microsoft to assist organizations in determining which secure WLAN approach was best suited to their environment and makes certain assumptions as to the definition of a large business. When using this flowchart keep in mind that large business should equate to 500 or more employees and an IT staff of at least five technology professionals.

As explained earlier, the decision tree is a bit misleading in this case because many midsized businesses, for which this paper is designed, have the resources and capability to implement WPA2 EAP-TLS with Certificate Services quite easily given the assumption that most midsized businesses have at least five IT professionals on staff and can support the additional infrastructure requirements for a basic EAP-TLS implementation, (four additional servers, one of which will remain disconnected from the network).

Given these facts, it becomes clear that the best solution for most midsized businesses is a WPA2 using EAP-TLS with Certificate Services and thus this will be the focus of this paper. However, there are always valid exceptions to the rule and if an organization requires a different approach there are numerous guides to accommodate those needs. Namely, if WPA with PEAP-MS-CHAP v2 is preferred, additional information can be found in Securing Wireless LANs with PEAP and Passwords at http://go.microsoft.com/fwlink/?linkid=23459

EAP-TLS Server Requirements

As mentioned briefly earlier, EAP-TLS requires at least four servers, (more if a distributed environment or larger environment demands it), of which two will be used as redundant Internet Authentication Service (IAS) servers (the Microsoft implementation of a Remote Authentication Dial-in User Service) and two will be part of a basic certificate infrastructure (PKI). Of the two certificate servers, the root certification authority (CA) will be stand alone and remain off the network to protect the root certificate.

Table 3. Suggested Hardware Requirements for Root CA Server

As the table shows, the requirements, based on the generic requirements for Windows Server 2003 Standard Edition, for the root CA are quite minimal and can even be built on an older platform that is slated for retirement or created as a virtual machine if need be. Many customers find it effective to use a laptop because it can easily be physically secured in a safe in the computer room. No matter what approach is taken to create the root CA, it is important to make certain that, if needed, the computer in question can be started or restored reliably.

The issuing certificate authority hardware requirements are similar but have additional storage requirements and the server does need to be attached to the network. Because this server must store all certificates issued, it is recommended that this server is provisioned with at least 2 GB of hard drive capacity for every 1,000 users.

Radius server requirements are more involved because these servers are critical to maintain WLAN functionality and must be able to handle many authentication attempts in brief periods of time. Thus a more robust hardware platform may be required for environments that will have thousands of wireless clients. Also, although the certificate authorities need only use Windows Server 2003 Standard Edition, the IAS servers may need to use Enterprise Edition because Standard Edition is only capable of supporting 50 RADIUS clients.

Due to these reasons, it is a common recommendation for IAS to be installed on domain controllers because this reduces the need for additional server hardware by taking advantage of existing robust server platforms that domain controllers require and using IAS on domain controllers actually increases the performance of IAS by reducing the network traffic that occurs between domain controllers and IAS for user authentication.

Failover and redundancy, as well as remote location considerations, also come into play when determining the requirements for RADIUS servers. Although the minimum recommended requirement is for two IAS servers, some businesses may have many remote offices and require IAS servers at some of those locations. Some businesses may also have higher requirements for server redundancy or load balancing.

Although there are no recommendations against using multifunction servers as RADIUS servers, it is important to consider the additional load that could be put on such a server and the nature of those demands. A RADIUS server should be capable of scaling to handle a situation in which all wireless clients attempt to connect within a brief period of time.

Certificates

No matter which WPA approach is taken to secure a WLAN, certificates are required, in some form, as part of that solution. PEAP only requires certificates on the authentication server thus it would be possible to simply use a third party certificate service to supply the needed certificates, which would mean a PKI implementation would not be needed. This is the main reason that the PEAP approach is recommended for smaller organizations that may lack the expertise or resources to implement and support a certificate infrastructure.

The Windows-supported implementation of EAP-TLS using Certificate Services does not necessarily require that there be an underlying PKI to support the issuance of certificates, but because every client must have a certificate to establish authentication with the RADIUS server, the use of third party certificates can be cost-prohibitive to all but the smallest businesses. The same considerations are required for using the combined PEAP with Certificate Services approach as well.

If an organization already has a PKI, the decision process is likely somewhat simpler, after all, if the components are already in place they might as well use them and implement the most secure option for WLAN security. Even if there is not an established PKI implementation, a midsized business may still find that investing in a certificate infrastructure might be wise given the other applications such implementations can be used for, which include:

All things considered, the approach of using Certificate Services either with EAP-TLS or PEAP is the best suited approach for midsized businesses and thus is the focus of this paper.

Creating a Certificate Practices Statement

Initial planning for a PKI should include the documentation of how certificates will be used in the business environment. Although such decisions can be amended as needs progress, it is important to lay out these decisions in a formal certificate policy statement.

In formal terms, a certificate policy is a set of rules under which the PKI operates. It records information regarding the applicability of certificates to specific organizational groups or applications with common security requirements. A certificate practices statement outlines the practices that a business uses to manage the certificates it issues. It describes how the certificate policy is interpreted in the context of the business systems infrastructure and operating procedure policies. Although a certificate policy is an organization-wide document the certificate practices statement is specific to a CA, although CAs can have a common certificate practices statement if they perform the same duties.

For some businesses, these statements are legal documents that must be crafted due to regulatory requirements that govern the industries in which they operate and that require legal assistance to create. However, even if a business is not governed by such requirements it is still a good idea to create such documents.

Certification Authority Hierarchy

The design specified in this guide uses a hierarchical trust model with a single internal root. There are a number of advantages and disadvantages to this approach, so further discussion may be necessary to determine if this specific approach is suitable in the business where it will be implemented. For more information about this topic, see the “Designing a Public Key Infrastructure” chapter of the Windows Server 2003 Deployment Kit at http://technet2.microsoft.com/WindowsServer/en/library/b1ee9920-d7ef-4ce5-b63c-3661c72e0f0b1033.mspx.

Figure 2. Certification Authority Hierarchy

Securing the Root Certification Authority

The Microsoft implementation of EAP-TLS will not function unless the root CA is secured “off the wire”, (unattached to the network). There are some sound security reasons for the use of a stand-alone root CA design such as this instead of a enterprise root CA design and thus it is usually the recommended approach for any PKI implementation.

Because such an approach may seem like a waste of resources, there are some methods a business can use to redeploy at least a portion of the hardware used to create a root CA that will never be attached to the network. Some of these suggestions include:

Internet Authentication

Internet Authentication Service (IAS) is the Microsoft implementation of a RADIUS and proxy server. IAS can perform centralized authentication, authorization, and accounting for a variety of network connections. IAS can be used with other RADIUS servers as an authentication, authorization, and accounting forwarder, with other VPN servers such as routing and remote access servers, or with other network infrastructure, such as a wireless access points.

When developing a deployment plan for an IAS infrastructure, it is important that the value of an IAS-based RADIUS infrastructure is taken advantage of because it is not intended to provide access to a single isolated network. Thus planning and deploying an IAS infrastructure should include a decision about whether to use a centralized service for network access management, including the use of a centralized account database such as Active Directory, and should ensure that present and future organizational needs will be met. In other words, the deployment of an IAS infrastructure should be strategic, not just tactical.

This guide will only deal with IAS planning and deployment as it relates to a secure wireless infrastructure. For other IAS planning and deployment possibilities and issues, see the "Deployment Resources" section of the Internet Authentication Service home page at www.microsoft.com/technet/itsolutions/network/ias/default.mspx.

Pre-Existing RADIUS Implementations

Even though this solution can be integrated with pre-existing RADIUS implementations, this guide does not provide for such a process. In most cases it would be advantageous to use IAS for the features described in this guide. To achieve this end, it is possible to either upgrade older platforms to Windows 2003 Server to serve as the core RADIUS servers or modify existing RADIUS servers to proxy RADIUS traffic to new Windows Server 2003–based RADIUS servers.

For detailed planning guidance concerning the migration of existing RADIUS infrastructure to Windows Server 2003–based RADIUS servers, see the IAS Technical Reference page at http://technet2.microsoft.com/WindowsServer/en/Library/8f5c89d5-fdaf-430c-9ef4-318f8c15baf11033.mspx or contact a Microsoft Account Representative or appropriate Microsoft Consulting Services professional.

RADIUS Server Failover and Load Balancing

Because RADIUS is a critical component of any 802.1X wireless security solution, so the availability of a wireless network is dependent on the availability of RADIUS servers. Therefore a RADIUS solution that supports wireless networks must be reliable, responsive, and redundant to ensure availability and performance is equivalent to a wired network and this is why it is a common recommendation for IAS to be installed on existing domain controllers.

Before deciding on a load balancing strategy, it is important to understand that 802.1X implements EAP within RADIUS (EAP-RADIUS) between the wireless access point and the RADIUS server. Even though RADIUS uses UDP, EAP is a session-oriented protocol that is tunneled within RADIUS. Which means that the multiple EAP-RADIUS packets comprising a single authentication operation must return to the same RADIUS server or else that particular authentication attempt will fail.

There are two approaches available for load balancing and failover on IAS servers in regards to wireless networking. The first is to use IAS proxy servers with RADIUS server groups and the other is to configure primary and secondary RADIUS servers through wireless access point hardware settings. The following table lists the advantages and disadvantages of each approach.

Table 4. RADIUS Failover and Load Balancing for EAP

Larger business should consider the use of RADIUS proxies configured into RADIUS server groups to distribute loads on RADIUS servers. This provides a degree of flexibility by allowing the distribution of traffic based on a number of configurable items including RADIUS traffic type and RADIUS attributes in addition to weighted and prioritized values. This type of architecture also provides the most flexibility and scalability for servicing authentication requests while being less demanding from an administrative perspective.

The simpler RADIUS server failover functionality built into wireless access points is capable of providing a sufficient level of resilience for most organizations but is not as sophisticated a solution as the use of proxy server groups. However, the migration path from this architecture to a RADIUS proxy server–based failover and load balancing solution is relatively straight forward so this solution also provides for some room to grow. For companies that are only considering small or limited wireless coverage, this solution is easy to implement and effective, however the management and implementation effort grows as does the size and complexity of a wireless network because each device needs careful monitoring and planning to maintain effective load balancing across all servers.

Figure 3. RADIUS WLAN Failover and Load Balancing Methods
See full-sized image

Load balancing with the built-in functionality of wireless access points involves the configuration of about half the wireless access points in each location to use on primary RADIUS server with another set as secondary whereas the other half of wireless access points use reverse assignments in the primary and secondary fields, as demonstrated in figure 3. The high overhead becomes apparent because there may be more load on some access points than on others so there is a lot of monitoring involved in achieving and maintaining an effective level of load balancing.

RADIUS Logging Requirements

IAS servers are capable of logging two types of optional events:

Authentication events are generated by devices and users when attempting to access the WLAN and are recorded by IAS in the Windows Server 2003 System Event Log. These events are useful both for troubleshooting and as part of a security auditing and intrusion detection system. These events should be enabled for both success and failure events initially but should be filtered eventually to prevent System Event Log overflow. The use of RADIUS authentication request logging can make the use of these events unnecessary for security purposes if enabled.

Centralized or Distributed IAS Servers

A centralized IAS server architecture should be considered as a starting point design for most midsized businesses given that most companies of this size have resilient high speed WAN connections to remote facilities and that RADIUS traffic does not consume much bandwidth because it’s designed to work over WAN links and dial-up connections. A centralized design is also more cost effective so long as an underlying redundant and high-speed WAN infrastructure is already in place.

Even still, care must be taken to analyze the current capacity of existing WAN links to determine whether this is the best option because other communication, such as DHCP traffic, could time out while waiting for 802.1X authentication attempts to complete over congested connections. Client connectivity is not the only concern when considering whether to use a centralized IAS architecture because the communication between IAS servers and domain controllers require robust network connections to avoid time-outs while determining network access rights and group memberships.

Some businesses may not be in a position to take advantage of a centralized architecture due to the costs associated with redundant high bandwidth WAN connections and the sophisticated network equipment. Such companies will opt to use a distributed IAS design, especially if a decentralized server infrastructure is already in place.

Yet another approach is a hybrid of the two which allows for the strategic placement of IAS servers at sites that can support the infrastructure and allowing those servers to supply authentication for branch offices that may not have an underlying server base, as shown in the following figure.

Figure 4. Mixed IAS WLAN Infrastructure Approach
See full-sized image

This guide accommodates all three models by providing guidance for configuring large hub offices with two RADIUS servers that can service both local and remote requests and guidance for configuring large home offices with optional single server branch offices.

Note   Again, WLAN access at remote offices without a server infrastructure is dependent on WAN availability.

IAS Server Placement and Co-Location Considerations

To maintain accessibility to WLAN services there needs to be at least two RADIUS servers for each independent Active Directory forest. Beyond this basic requirement there are a number of factors that determine how many servers are needed and whether they can be candidates for collocation with other server functions.

In general the placement of IAS servers should follow the placement of domain controllers, that is, if an office already depends on a high speed WAN link to another office for domain services, it’s likely that it should use a remote RADIUS server as well. Larger offices that already have their own domain controllers will likely need to have at least one RADIUS server with a possible failover located elsewhere depending on the WAN link available. Care must be taken to assess the WAN link capacity when planning placement of RADIUS servers both for local user authentication reliability and for placement of domain controllers used for authentication due to the extra traffic generated. Also, for improved performance, RADIUS servers should be located in the root domain of a forest to optimize Kerberos operations.

Another consideration may involve whether it is even feasible to place additional servers at remote locations when there appears to be a need to do so because some smaller offices may not have the space or infrastructure to support additional server hardware. To address such issues it is possible to co-locate an IAS server with an Active Directory domain controller. The following table describes some advantages and disadvantages to this approach.

Table 5. IAS and Domain Controller Co-location Considerations

As this table shows, there is a reason why many organizations have existing policies that isolate domain controller functionality to their own servers because they are critical to the network environment. There may also be security concerns associated with placing IAS services on a domain controller when there is a separation of duties involved between both administrative groups because there is no inherent separation of IAS administration from local Windows administrator group functions. Such issues must be considered before deciding on the possibility of co-locating IAS services, but otherwise there are some performance benefits to doing so, let alone the obvious cost benefit, especially at remote locations.

To offset the cost considerations involved with adding server hardware to remote offices, it is possible to use existing domain controllers, which may already exist at remote locations, as IAS servers either directly or with the addition of a virtual machine to the existing domain controller.

Estimating Server Load and Hardware Requirements

Assessing and planning for potential server loads should be approached by using worst case scenarios. Specifically, what if all potential WLAN users needed to perform authentication in a short period of time during a failover event? Of course, the optimal design is one that deploys the minimum number of servers required for resilience while still leaving room for future growth as needed.

The following information should be considered when planning for IAS server loads and requirements:

For this solution, using WPA or WPA2 with EAP-TLS certificate services it is important to note that, unlike WEP, WPA and WPA2 alleviate the need for forced reauthentication to refresh session keys thus require less overhead in that regard. It is also important to note that EAP-TLS requires a CPU-intensive public key operation upon each initial authentication but then uses cached credentials for fast reconnect during each subsequent logon until the cached credential expires, which is every 8 hours by default. Also noteworthy is that reauthentication will occur when a client roams from a wireless access point that authenticates to one RADIUS server to a wireless access point that authenticates to another authentication server; this only happens once per each authentication server and is transparent to the user.

When estimating IAS server capacity it is helpful to use the number of authentications per second as an estimate of potential loads. The following table shows the estimated authentication per second capacity of an IAS server with Active Directory on an Intel Pentium 4 2-GHz CPU platform.

Table 6. Authentications Per Second

Note   The information in this table should only be considered an estimate that can be used as a possible guideline for capacity planning purposes.

This table suggests that such a server would be able to process 36 new authentications per second in case of a failover or peak demand event, thus it would take about 3 seconds to authenticate 100 users.

Another factor to consider is the effect of disk-based logging on authentication times. A slow disk subsystem can have a negative impact on authentication times when detailed logging is used to track authentication activity. Be sure to use a fast disk subsystem to maintain a reasonable response time on each IAS server.

WPA 802.11 Authentication

The use of a certificate infrastructure and RADIUS to secure wireless communications by providing user and device authentication has been covered and now it’s time to discuss how data transmitted between wireless devices is secured from probing and other risks.

The use of radio transmissions has always been considered less secure than wired communications because it takes much less effort to intercept data transmitted over the air than it is to tap into a cable or patch panel, especially when port security is used. To counter the inherently insecure nature of wireless communication it is necessary to encrypt the data so that any interception does not yield easily readable information to potential eavesdroppers.

The initial WEP specifications for wireless encryption were found to be inadequate for this task and so WPA was created as a stopgap and subset of the 802.11i specification, which was pending at that time. Finally, WPA2 was drafted as the full implementation of the now official 802.11i standard. The primary difference between WPA and WPA2 is in the method of encryption, with WPA using TKIP and WPA2 using the more secure AES-CCMP standard.

Although the solution provided in this guide can be used to secure WEP or WPA, it is recommended that WPA2 be used to ensure the highest and most reliable form of security available for wireless communication when it is feasible from a management perspective to do so. Otherwise, the use of WPA along with the solution provided in this guide delivers an adequate level of security as well.

Client Requirements

The solution outlined in this guide was designed for wireless capable client computers using Windows XP Professional with SP2 or Windows XP Tablet Edition. These versions of Windows operating system offer the built-in 802.1X and WLAN support. Additionally, Windows XP–based clients supply automatic certificate enrolment and renewal functionality, which makes a certificate-based solution such as this particularly cost effective when tied to a certificate infrastructure.

Although Windows XP SP2 offers built-in support for WPA, it is necessary to install an additional update to enable IEEE 802.11i WPA2 support on Windows XP SP2–based clients. For more information about this additional update along with download instructions, see Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Service Information Element (WPS IE) update
for Windows XP with Service Pack 2 is available at http://support.microsoft.com/default.aspx?scid=kb;en-us;893357.

Server Infrastructure Requirements

As discussed previously, this solution requires use of the Certificate Services and IAS components of Windows Server 2003. There are some built-in features supported by the Windows Server 2003 implementation of Certificate Services and IAS that are specific to 802.1X WLANs. Although IAS and Certificate Services can be deployed on older versions of Windows, this guide was written specifically for a Windows Server 2003 Active Directory environment.

Wireless Access Point Requirements

This guide focuses on the security element of a WLAN solution, thus there is no guidance for the deployment, positioning, or channel selection for wireless access point hardware. For more information about specific wireless access point hardware issues, configurations, or placement guidance, see the vendor’s instructional material or Web site.

This solution is most secure when using wireless access point hardware that is IEEE 802.11i WPA2–certified and that offer built-in failover/failback functionality. It is possible to implement this solution using WPA-certified equipment without much modification to this guidance and still maintain a very high level of security. However, although it is also possible to implement this solution with the WEP standard, doing so is not recommended and is not supported by this guide.

Deployment and Management

Although this section includes step-by-step guidance regarding the installation and configuration of servers and services required for the solution, it does not include the actual installation and configuration steps required for operating systems such as Windows Server 2003 and Windows XP Professional. It is assumed that most businesses have established build processes and hardening guidelines.

Certificates

Although this section offers detailed guidance on the installation of a PKI, it does not include any details for a server build and hardening process because it is assumed that there is already an established standardized process in place for these procedures.

It is also assumed that the CA servers have already been configured with a base image and hardened per a standard organizational process prior to this phase of the solution.

Note   Remember that the root CA will never be attached to the network and thus any steps in an organizational server build and hardening process that involve a network connection should be modified to accommodate this exception.

Prerequisite User-Defined Configuration Information

The following table lists organization-specific parameters that should be collected or decided upon before beginning a deployment of the solution provided later in this guide. Throughout guide there will be placeholders used to describe settings using a format similar to the setting name. For example, the DNS name of an Active Directory forest root domain might be shown as DomainName.com. The values listed in italic text should be substituted with the specific organizational information gathered during this process.

Table 7. User-Defined Configuration Information

Prerequisite Solution Prescribed Configuration Items

The settings identified in the following table do not need to be changed unless a different setting is warranted. Make certain that any implications that can occur and any dependencies that may be altered by changing these parameters are fully understood before altering the settings listed here.

Table 8. Solution Prescribed Configuration Items

Note   Using 4096 bit length keys may cause some compatibility issues if they are used by some devices or older software from other vendors. All applications that might use certificates issued by the root CA should be tested with certificate keys of this size to ensure proper functionality. The root CA key length can be reduced to 2048 bits if there are any concerns about key length compatibility.

Installing Configuration Scripts on CA Servers

The support scripts supplied with this guidance are to assist with the setup of the solution supplied in the following sections. These scripts must be installed in each CA server and should not be deleted after use to assist with the operation of these servers. To install these scripts first create a folder called C:\MSSScripts and then copy the scripts to that directory.

Installing and Configuring IIS on the Issuing CA Server

Internet Information Services (IIS) is used as a download point for non-Windows clients to retrieve CA certificates and CRLs. The root CA does not need to provide this service, especially because it is not supposed to be attached to a network, but the issuing CA should have access to this service

IIS can also be used to host the Certificate Services Web enrollment pages, although these are not used in this solution. If the Web enrollment pages are installed on a system other than the issuing CA that server must be marked as “Trusted for Delegation” by setting that property on the server’s computer object in Active Directory.

IIS can be installed using the Windows Optional Components Manager, which is accessed through Add/Remove Components item in Control Panel. The following list shows the components that need to be installed:

To install IIS

Sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIIS.txt

[Components]
complusnetwork = On
iis_common = On
iis_asp = On
iis_inetmgr = On
iis_www = On

sysocmgr /i:sysoc.inf

Configuring IIS for AIA and CRL CDP Publishing on the Issuing CA

A virtual directory must be created on IIS to use as the HTTP location for CA certificate and CRL publishing points (referred to as the Authority Information Access (AIA) and CRL Distribution Point (CDP) respectively).

To create a virtual directory on IIS

Choosing a DNS Alias for the HTTP Publishing Point

A generic DNS alias (CNAME) should be created to resolve the IIS server hosting the CDP and AIA. This DNS alias should be used when configuring the CDP and AIA paths for the CAs in subsequent sections. By using aliases, the CA publishing points can be easily moved to other servers or network locations without the need to reissue CA certificates.

Other Configuration and Operating System Component Items

In addition to the configuration steps outlined so far there are some other recommended items that may require attention, these include:

sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_RemoveRootUpdate.txt

[Components]
rootautoupdate = off

Preparing Active Directory for the PKI

The fundamental requirements for an Active Directory domain infrastructure that are outlined in this section are based on a Microsoft Windows Server 2003 Active Directory architecture. If the implementation of Active Directory in use is Windows 2000–based, other requirements may be necessary. For more information about additional requirements for a Windows 2000–based domain structure, see How to raise domain and forest functional levels in Windows Server 2003 at http://support.microsoft.com/kb/322692.

This solution also requires a minimum domain functional level of Windows 2000 Native Mode, at least for the domain where the CA servers will be installed. The requirement exists because this solution uses Active Directory Universal groups, which are available in Windows 2000 Native Mode and up.

Creating PKI and CA Administration Groups

This solution defines several security groups that correspond to separate administrative roles. This approach provides a lot of control over delegation for CA administration in conjunction with least privileges security principles. However, there is no other reason that these must be used if they do not correspond with any specific organizational administrative model.

To create CA administration groups in a domain

Cscript //job:CertDomainGroups C:\MSSScripts\ca_setup.wsf

The setup procedures in the remainder of this document require the use of accounts that are members of the Enterprise PKI Admins, Enterprise PKI Publishers, and CA Admins so these groups should be populated with the appropriate accounts before continuing. If there is only one person responsible for all CA-related roles, a single account could be assigned to all groups, however, most businesses do have some degree of separation of roles and duties among staff, though not as complex as those listed in the previous table. For those businesses that have a simplified separation of duties, the following chart lists common responsibility divisions.

Table 11. Simplified Administration Model

Suggested Domain OU Structure

There are a number of groups and user accounts that will be associated with the management and operation of a PKI. Depending on the established policies in place it may be necessary to organize these groups and users into a specific OU structure. Because this structure may be dictated by already existing company guidance, the following is a suggested structure which can be modified as needed.

To create a Certificate Services OU hierarchy

Granting Permissions to the Public Key Services Container

The security for the Public Key Services container needs to be altered to enable Enterprise PKI Admins to install Enterprise CAs and to configure certificate templates without requiring that group’s accounts be members of the Enterprise Admins group. This is also necessary to allow Enterprise PKI Publishers to publish certificate revocation lists and CA certificates without needing Enterprise Admin rights.

To make the following changes, an Active Directory Enterprise Admin equivalent account will need to be used.

To grant permissions to Enterprise PKI Admins

To grant permissions to Enterprise PKI Publishers

Granting Permissions to the Cert Publishers Group

All Enterprise CA computer accounts in the domain will reside within the Cert Publishers security group. This group will be used to apply permissions to user and computer objects and to the objects in the CDP container mentioned in the previous procedure. Whenever a CA is installed, its computer account will need to be added to this group.

To allow members of the Enterprise PKI Admins group to install enterprise CAs, the permissions on this group must be changed.

To grant the modify membership permissions on Cert Publishers