| Introduction | |
| Conceptual Design | |
| Solution Design Criteria | |
| Solution Logical Design | |
| Design Criteria Re-Evaluated | |
| Summary |
The previous chapter discussed the options for wireless local area network (WLAN) security and described why 802.1X wireless authentication using the Extensible Authentication Protocol – Transport Layer Security (EAP-TLS) protocol was selected for this solution. This chapter describes the solution architecture, and then a logical design is derived based on design criteria taken from an example company. You can use this information as the foundation to implement the solution. The logical design is based on 802.1X WLAN network hardware, Remote Authentication Dial-In User Service (RADIUS) authentication, and a Public Key Infrastructure (PKI).
You should have an understanding of IT infrastructure design concepts, as well as a familiarity with the key components that form part of the design. The key components are: WLANs and networking components, RADIUS, the Active Directory directory service, and PKIs. Detailed knowledge of these items is not required.
This chapter aims to:
| • | Provide a conceptual overview of how a secure WLAN solution based on the 802.1X and EAP – TLS protocols functions and the key components of this type of solution. |
| • | Define the solution design criteria for the logical design and the later stages of the detailed technical design. |
| • | Produce a coherent logical design that will form the basis for the detailed design in the subsequent chapters. |
| • | Explain how you can scale the solution to meet the needs of organizations of different sizes. |
| • | Detail some of the ways in which you can extend the proposed design or use it as the basis to build other network access solutions that include virtual private networks (VPN) and wired network access control, and examine how you can use the PKI component of the design as the foundation for a variety of security applications. |
Subsequent chapters will look at the detailed design process for each of the main components of the logical design (WLAN, RADIUS, and PKI) in preparation to build and operate the solution.
As discussed in the previous chapter, there are a number of serious security vulnerabilities inherent in wireless networking. At best, these weaknesses are only partially addressed by the use of Wired Equivalent Privacy (WEP) as specified in the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. The solution proposed in this guide addresses the problem of how to improve the security of wireless network communications. To do this, the ideal solution needs to have the following features:
| • | Robust wireless client authentication. This should include mutual authentication of the client, the wireless access point (AP), and the RADIUS server. |
| • | An authorization process to determine who will be allowed to access the wireless network. |
| • | Access control to only permit network access to authorized clients. |
| • | Strong encryption of wireless network traffic. |
| • | Secure management of encryption keys. |
| • | Resilience to denial of service (DoS) attacks. |
The 802.1X protocol standard for network access control combined with a secure authentication method such as EAP-TLS fulfills some of these requirements. High strength WEP provides relatively secure encryption of network traffic, but poor key management. Methods to manage WEP encryption keys inherent in 802.1X and EAP are much more secure than the 802.11 base standards permit. The WiFi Protected Access (WPA) standard is a collection of industry-based standards that includes 802.1X and EAP (among other improvements), and a standardized protocol for key management called Temporal Key Integrity Protocol (TKIP). The WPA standard represents a considerable step forward for WLAN security and has been endorsed by most analysts and vendors.
Note: None of the WPA improvements address some of the DoS weaknesses inherent in both 802.11 and 802.1X. The DoS weaknesses are not as serious as any of the other WEP flaws, and almost all of the demonstrated DoS attacks cause only temporary network disruption. However, the threat of DoS attacks are still a serious concern for some organizations, and one that is unlikely to be resolved before the release of the IEEE 802.11i standard that is anticipated in 2004.
Although support for WPA is now widespread, there are still many existing devices and systems that do not support it. For this reason, the solution for this guide is designed to work with both dynamic WEP and WPA. Most network hardware vendors sell products that support 802.1X with dynamic WEP keys and WPA. For the purposes of this design chapter, the two approaches are treated interchangeably — the use of one instead of the other has no significant impact on the design.
A conceptual figure of the solution (802.1X EAP-TLS Authentication) is displayed in the following figure.
The figure depicts four main components:
| • | The wireless client. This component is a computer or device running an application that requires access to network resources. The client has the capability of encrypting its network traffic and of storing and securely exchanging credentials (such as keys or passwords). |
| • | The wireless AP. In general networking terms, this component is known as the Network Access Service (NAS), but wireless standards refer to this as the AP. The wireless AP implements access control functions to allow or deny access to the network and provides the capability to encrypt wireless traffic. The AP also has the means to securely share encryption keys with the client to secure network traffic. Finally, it can query an authentication and authorization service for authorization decisions. |
| • | The Authentication Service (AS). This component stores and verifies the credentials of valid users and makes authorization decisions based on an access policy. It may also collect accounting and audit information about client access to the network. The RADIUS server is the main component of the AS but the directory and the CA also contribute to this function. |
| • | The internal network. This component is a secure area of networked services that the wireless client application needs to gain access. |
The numbers on the figure illustrate the network access process, which the following steps describe in more detail:
1. | The wireless client must establish its credentials with the AS before wireless network access is established. (This may be accomplished using some out–of–band means — for example, by floppy disk exchange — or it may take place on a wired or other secure network.) | ||||||||
2. | When the client computer is in range of the wireless AP, it tries to connect to the WLAN that is active on the AP. The WLAN is identified by its Service Set Identifier (SSID). The client detects the WLAN SSID and uses it to determine the correct settings and credential type to use for this WLAN. The wireless AP is configured to allow only secured (802.1X authenticated) connections. When the client tries to connect to it, the AP issues a challenge to the client. The AP then sets up a restricted channel that allows the client to communicate only with the RADIUS server. This channel blocks access to the rest of network. The RADIUS server will only accept a connection from a trusted wireless AP, or one that has been configured as a RADIUS client on the Microsoft Internet Authentication Service (IAS) server and that provides the shared secret for that RADIUS client. The client attempts to authenticate to the RADIUS server over the restricted channel using 802.1X. As part of the EAP – TLS negotiation, the client establishes a Transport Layer Security (TLS) session with the RADIUS server. Using a TLS session serves the following purposes:
During this exchange, the traffic within the TLS tunnel is only visible to the client and RADIUS server and is never exposed to the wireless AP. | ||||||||
3. | The RADIUS server validates the client credentials against the directory. If the client is successfully authenticated, the RADIUS server assembles information that allows it to decide whether to authorize the client to use the WLAN. It uses information from the directory (such as group membership) and constraints defined in its access policy (for example, the time periods in which WLAN access is allowed) to either grant or deny access to the client. The RADIUS then relays the access decision to the AP. | ||||||||
4. | If the client is granted access, the RADIUS server transmits the client master key to the wireless AP. The client and AP now share common key information that they can use to encrypt and decrypt the WLAN traffic passing between them. When using dynamic WEP to encrypt the traffic, the master keys need to be changed periodically to thwart WEP key recovery attacks. The RADIUS server does this by regularly forcing the client to re-authenticate and generate a new key set. If WPA is used to secure the communication, the master key information is used to derive the data encryption keys, which are changed for each packet transmitted. WPA does not need to force frequent re-authentication to ensure key security. | ||||||||
5. | The AP then establishes the client WLAN connection to the internal LAN, allowing the client unrestricted access to the systems on the internal network. Traffic sent between the client and AP is now encrypted. | ||||||||
6. | If the client requires an IP address, it can now request a Dynamic Host Configuration Protocol (DHCP) lease from a server on the LAN. Once the IP address has been assigned, the client can start exchanging information normally with the systems on the rest of the network. |
The following figure displays this process in more detail.
The figure displays the individual components in more detail. Later sections of this chapter will return to this diagram to expand on it. For now, you should note the subcomponents of the AS: the certification authority (CA), the directory, and the RADIUS server. Although conceptually these subcomponents perform a relatively simple set of tasks, carrying out these operations securely and in a way that is scalable, manageable, and reliable requires quite a sophisticated infrastructure. The majority of the planning, implementation, and management effort required for this is detailed in the remaining chapters of this guide.
Now that the the basic concepts of the solution have been described, the key design criteria for the solution can now be addressed. These criteria provide the guidelines that will turn the solution concept into a design that you can actually implement.
The design criteria are derived from the requirements of a typical organization implementing this solution. The following sections describe that organization and its main technical requirements.
The description of the organization in this section is intended only to provide a context for the design criteria. When assessing the suitability of the solution for your organization, focus on whether the design criteria make sense for you, not on whether your organization is exactly like the one described in this chapter.
The target organization for the solution may have deployed a WLAN in some locations to minimize network infrastructure costs, and increase staff mobility and productivity. The organization has a clear sense of the need for security and has already deployed a number of technologies to enhance its IT security. For example, it has deployed domain authentication, Internet firewalls, virus scanners, and a remote access or VPN solution. It also has longer term plans to use a number of other high security applications, such as file encryption and secure e-mail.
The simplified logical and physical network layout of this organization might look like the one defined in the following figure:

Figure 3.3 The schematic of the target organization's network and physical layout
See full-sized image
Although only one large and one small outlying office are in the figure, in reality there could be several of each. For clarity, only a small numbers of servers and clients are depicted This small number of hosts is not representative of a typical organization.
Within limits, the size of the target organization has relatively little effect on the design criteria for the solution. On the smaller end of the scale, the head office may employ a few hundred staff who work with branch offices that serve tens of staff. On the larger end of the scale, the head office staff may number in the thousands, and outlying offices may have hundreds of staff. At both ends of the scale, organizations will typically also have smaller offices with small numbers of staff.
The following requirements are typical of the organization depicted in this scenario:
| • | The organization must improve the security of the WLAN to eliminate or substantially reduce the following threats:
| ||||||||||
| • | The security measures should not reduce the usability of the network and not lead to any significant increase in help desk calls. | ||||||||||
| • | The deployment and ongoing management costs should be low enough to justify them even if only a relatively small number of users (less than 10 percent of the workforce) use the WLAN solution. | ||||||||||
| • | The design should be capable of supporting a broad variety of clients and devices. |
In addition, there are usually a number of other, more general technical requirements:
| • | Resilience to single component failure should be maintained. |
| • | Scalability should exist to cope with higher levels of use in the future possibly beyond 100 percent of the existing workforce . The cost to support increased numbers of users should be minimal or at least in proportion to the expansion required. |
| • | Reusability of components — wherever possible. The solution should reuse existing infrastructure and any new components introduced by the solution should be reusable by future projects. |
| • | Existing management and monitoring infrastructure should easily accommodate the new solution. |
| • | The ability to recover from a catastrophic failure (for example, by restoring backups to alternative hardware) should be maintained. |
| • | Reliance on industry standard protocols and formats should be followed. Where no current standards yet exist, the solution should align with future standards. |
| • | Robust security (including regular renewal) of credentials and keys should be provided in the solution. |
| • | Full audit information for user enrollment and client access to the network should be provided. |
From these requirements, the criteria in the following table can be derived to support the solution design.
Table 3.1: Solution Design Criteria
| Design factor | Criteria |
Security | –Robust authentication and authorization of wireless clients. –Robust access control to limit network access to authorized clients. –High strength encryption of wireless network traffic. –Secure management of encryption keys. –Resilience to DoS attacks. |
Scalability | Basic design that scales up and down to include a broad range of organizations. |
–Min/Max users supported | –500 – 15,000or more WLAN users. –500 – 15,000or more certificate users. |
–Number of sites supported | –Multiple large sites — with local authentication domain controllers and Microsoft Internet Authentication Service (IAS) — supported with resilience to wide area network (WAN) failure. –Multiple small sites supported with no resilience to WAN failure. |
Component reuse (use of existing infrastructure) | Use Active Directory, network services, and Microsoft Windows XP clients. |
Component reuse (usability by future applications) | –Support for other network access applications (VPN and 802.1X wired network access) by the authentication infrastructure. –Support for a wide variety of applications — for example, Encrypting File System (EFS) and VPN — by PKI. |
Availability | Resilience to single component or network link failure. |
Extensibility | –Extensible to support future capabilities and standards (for example, 802.11i, WPA, 802.11a for WLAN). –Certificate infrastructure is extensible to support most common uses of public key certificates (secure e-mail, smart card logon, code signing, and Web Service Security). |
Manageability | Integration into existing corporate management solutions (includes system and service monitoring, backup, configuration management). |
IT organization structure | Favors centralized IT (department of at least five and typically 20 – 30 IT staff). |
Standards conformance | Adherence to current relevant standards and a clear migration path to future relevant standards. |
This section describes the logical and logical-physical solution design. This involves specification and placement of actual components, although it does not include physical design details such as server hardware specification.
Using the following figure, which was shown earlier in the chapter, this section examines how the different components fit together in the overall design.
The previous figure divided the logical components to make it easier to understand the WLAN access process. However, to simplify deployment and management, it makes sense to slightly re-group the components.
The component grouping allows the whole design to be viewed in a modular way that allows for maximum reuse of these components. For example, it would be possible to implement the PKI component only to authenticate WLAN users. However, this may limit the reusability of the PKI component for other applications. Similarly, the RADIUS component for the solution should be designed while keeping in mind what other applications this component might be required to support in the future.
The IT services in the design are grouped into the following categories:
| • | WLAN components — Wireless clients and Access Points (AP) |
| • | RADIUS component |
| • | PKI component — Certification Authorities (CA) |
| • | Infrastructure services component |
This last component includes a directory and supporting network services. These are made up of IT services that will typically already exist in the organization that the solution interacts with in some way.
At the logical-physical level, the design now shows how these components will be implemented as physical servers, how they will be linked together, and how they will be distributed between the different sites of the target organization. However, the numbers of servers displayed in the following figure is a generalization. The final definition of the number and placement of the servers will be discussed in the later planning chapters of this guide.
The following figure illustrates the server implementation in the head office. Only the top three components represent new servers or components that must be acquired. The infrastructure services components already exist in some form for many organizations. If your organization has already deployed 802.1X-capable WLAN equipment, the WLAN component may also already exist.
The following figure illustrates the physical layout for a larger branch office, which is distinguished from a small branch office by having a local domain controller on site. A single IAS server is deployed to the remote office. Although the IAS server is depicted as a separate server, you could run this service on the domain controller.
Note: If the WAN link to the head office is reliable (that is, there are redundant network links) and not overly congested, the large branch office can use the head office RADIUS services rather than its own. This option is discussed further in Chapter 5, "Designing the RADIUS Infrastructure for Wireless LAN Security."
All other services (for example, the CAs) are supplied from the head office.
The small branch office may have some IT infrastructure — for example, a file server and printer — but it will typically not have any authentication infrastructure. Some organizations believe that these offices do not require or justify any WLAN services. Other organizations, using temporary offices, find that not needing to lay and manage network cables is an attractive option.
If WLAN services are needed in a small office that lacks a local domain controller, the local wireless APs will rely on the IAS server and domain authentication infrastructure at headquarters. The main problem with this approach is that all WLAN connectivity is lost if the WAN link to the head office fails. Although there is no easy solution to this scenario.you can address this weakness (at a cost) by providing WAN redundancy or by deploying local domain controllers.
If WAN resilience or locating local domain controllers in the small branch offices of your organization is too expensive, an alternative is to deploy isolated wireless APs using the WPA pre-shared key (PSK) mode. All Wi – Fi certified wireless APs now support WPA. Although this is much more secure than static WEP, there is additional management overhead associated with this option.
One of the key design criteria is to ensure that the design can scale. The solution has to support a wide range of implementation sizes at a cost that is appropriate for each one. For example, an implementation for 500 users should cost proportionally less than one for 5,000 users. The complexity of implementing and managing the solution must also be realistic across this range of organizations.
The following figure illustrates how the design would scale to accommodate large numbers of users in a head office and larger regional offices. It is possible that the IAS servers would also service other network applications, such as VPN. For more information about this subject, see the "Extending the Design" section later in this chapter. This consideration could also potentially influence the precise layout and number of the servers. The extra IAS servers are displayed in the following figure for illustration only.
The additional servers required for the scaled version of the solution are shaded.
At the other of the spectrum, the solution can be implemented with a relatively modest amount of new hardware and software. This is mainly achieved by running the IAS service on existing domain controllers. This configuration has been extensively tested by the IAS product group at Microsoft and is recommended for many scenarios. The following figure illustrates this version of the design.
The RADIUS component is still displayed in the figure as logically separate (in order to match the layout of the previous figure for comparison) but the component is actually implemented as a service on the pre-existing domain controllers. The only servers required in this version of the solution are the CAs that reside in the PKI area of the solution design.
Another key design criterion of the solution is the reusability of the components in future applications. You can reuse both the RADIUS component and the PKI component to provide authentication and other security services for a variety of applications.
This solution's RADIUS design can provide authentication, authorization, and accounting services for other network access servers, such as 802.1X wired network authentication, and VPN and remote access authentication.
The simplest application, which requires no modification of the basic WLAN RADIUS design, is 802.1X wired authentication. Organizations that have a widely distributed wired network infrastructure may find it difficult to control unauthorized use of the corporate network. For example, it is often difficult to prevent visitors plugging in laptops or employees adding unauthorized computers to the network. Some parts of the network, such as data centers, may be designated high security zones. Only authorized devices should be allowed in these high security zones — even to the exclusion of employees with corporate computers.
The following figure displays how a wired network access solution integrates with the design: The bold-edged area represents the 802.1X wired components, while the other areas of the layout contain the relevant services displayed in the previous design figure.
Networks that use 802.1X switches play a role that is identical to the wireless APs role in the core solution. Moreover, these networks can use the same RADIUS infrastructure to authenticate clients and selectively authorize access to the appropriate network segment. This version of the solution includes the obvious advantages of centralizing the account management in the corporate directory while leaving the network access policies under the control of the network security administrator.
Another network access service that could use the RADIUS components is VPN and remote dial-up. Particularly in larger organizations, it is likely that some additions would need to be made to the design as it stands, such as the addition of RADIUS proxies. The following figure displays how the extended solution might look.
The VPN servers in this solution play the same NAS role as the wireless APs in the core design: They pass the clients' authentication requests to the RADIUS infrastructure. Although it is possible to directly pass the RADIUS requests to the internal IAS servers, it is more secure to use a RADIUS proxy layer that forwards the requests to the internal IAS servers.
This solution combines the advantages of using existing infrastructure and centralizing account management, while leaving the access policy control under the supervision of the network security administrator. Further enhancements, such as mandating smart card-based user authentication, add to the overall security of the solution. Microsoft uses a very similar configuration to allow its internal staff to securely connect to the corporate network.
Dial-up remote access works in a similar way by using the dial-up server capability of the Windows Routing and Remote Access service instead of the VPN functionality.
Using RADIUS (specifically IAS) in this scenario offers another advantage: the ability to use quarantining policies. This takes advantage of the Routing and Remote Access service in Microsoft Windows Server 2003, and Connection Manager (the Windows-enhanced remote access client) to allow or deny access based on the security state of the client computer. With this configuration, IAS can verify the client meets certain requirements when it connects to the network. For example, this procedure can check to ensure that the client has up-to-date antivirus software or is running a corporate-approved operating system build. If the client fails either of these checks, the RADIUS server denies it access to the network. In this way, even a properly authenticated user and computer may be denied access if they present a possible security threat to the company network.
Because the solution criteria for reusability and extensibility are important, the PKI component was designed in the knowledge that it may be used in the future for a variety of different security applications. As the next chapter will discuss, the PKI design is therefore a blended strategy; minimizing cost and complexity as part of a secure wireless solution, while also maintaining enough flexibility for you to use it as a basis for other applications in the future.
The following figure illustrates a few of the applications that the PKI component could support in addition to the secure wireless application. Some are relatively simple applications that can use the PKI developed in this solution with little or no modification to the core design. Others, such as secure e-mail and smart card logon, are more complex, and will almost certainly require more careful consideration and some extension of the PKI design.
Before closing this chapter, it is worth re-examining the list of design criteria for the solution to examine how well the proposed design now meets the goals set earlier. This evaluation is summarized in the following list. However, many of these items are only fully addressed in the detailed design chapters that follow this one.
| • | Security. The solution design includes robust authentication, authorization, and access control. Strong (128 bit) encryption is a function of the network hardware and is supported on most currently available devices. Secure management of the encryption keys is provided by a combination of the Microsoft 802.1X client, the 802.1X–enabled wireless AP and the wireless network cards, and the RADIUS server. Achieving resiliency in the face of DoS attacks remains an area where there is still work to do — current industry standards (until the advent of 802.11i) are still vulnerable to a variety of DoS attacks. |
| • | Scalability. The basic design accommodates a wide range of organizations in a cost-effective manner from a few hundred to many thousands of users. The design is also flexible with regard to geographic and network layout. Small offices without a local domain controller are dependent on WAN reliability or a lower grade security solution. |
| • | Component reuse (use of existing infrastructure). The design uses Active Directory and many existing network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS). |
| • | Component reuse by future applications. The RADIUS design, implemented using IAS, can be used by or easily extended to support other network access applications (such as VPN, 802.1X wired network access, and remote access dial-up). The PKI is also capable of supporting simple public key applications, such as EFS, and provides the environment to work with more complex applications that can perform such things as smart card logon. This item also meets the design criterion — Extensibility. |
| • | Availability. The solution design is resilient to a single component or network link failure at the head office, and for all outlying offices where a RADIUS server can be deployed. Small offices without a local RADIUS server are vulnerable to a WAN failure. |
| • | Manageability. The ability to manage the solution is not apparent from the design, but this requirement is accounted for in the design of the operational framework |
| • | IT organization structure. Some level of specialization with WLANs in the organization's IT department is essential for deploying and managing a solution of this type. |
| • | Standards compliance. The solution adheres to current official and industry standards. This is most relevant in the area of WLAN security where the solution is based on the 802.1X protocol, EAP – TLS, and 128-bit dynamic WEP or WPA. Microsoft recently announced product support for WPA for Windows XP, approving the highest available standards of native WLAN security. The design will support either WPA or dynamic WEP. |
This chapter examined the conceptual design of a secure wireless LAN network solution based on using the 802.1X protocol and EAP – TLS . The key components of the solution were explained at an architectural level. An outline of the target organization for this solution was then described, together with the design criteria used to engineer the solution.
The design criteria were used to translate the conceptual solution into a logical solution design. This included examining implementation options to scale the solution for organizations of different sizes with different requirements, and how to extend the basic design to provide support for other network access and security applications. Finally, the main design criteria were reviewed against the features of the proposed design. This criteria review serves as an entry point to the remainder of the Planning Guide chapters.
The next three chapters of the guide detail the design of each major architectural components of the solution: the PKI, the RADIUS infrastructure, and the WLAN security design.