Chapter 12

Advanced Enterprise WLAN Security Design

THE FOLLOWING CWDP EXAM TOPICS ARE COVERED IN THIS CHAPTER:

• Recommend appropriate authentication solutions and explain design concepts related to their use.
• Illustrate common deployment and design strategies for AAA, especially RADIUS.
• Consider the following network services and protocols as they relate to wireless interaction with the wired network:
  • RADIUS
  • Directory Services (LDAP)
  • Certificate Authority (CA)
• Understand design strategies for integration of client authentication with directory services.
• Identify the role and limitations of client capabilities in security planning.
• Describe the methods of designing a secure network with segmentation and filtering.
• Explain best practice security design concepts for guest and public access Wi-Fi networks.
• Describe and implement common VPN uses with WLANs.
• Describe deployment and design strategies for Wireless Intrusion Prevention Systems (WIPS).
• Identify and explain factors that motivate AP and WIPS sensor placement.
• Demonstrate the importance of, and design considerations related to, Fast BSS Transition (Fast/Secure Roaming).

As with the SOHO market, Wi-Fi networks are becoming increasingly important to enterprise companies. Home users have experienced the benefits of wireless and mobility, and they now bring the same expectations for productivity to work. The benefits of Wi-Fi are easy to see, but enterprise deployments also have stringent network performance, ease of use, and security demands. These competing requirements make the network designer’s job, as it relates to security design, more difficult.

In an exploration of security technologies and best practices for security design, this chapter will demonstrate that WLANs can be very secure if proper design techniques are followed.

In this chapter, we will take a look at the best security strategies for WLANs in the enterprise along with some common challenges. We will discuss the best ways to implement security to maintain network integrity and privacy, to control access, and to protect all of the valuable resources that are contained within a network, while maintaining the required level of application performance and network service.

All of these steps require some strategic planning as well as an intimate knowledge of the network user population, client and infrastructure devices, existing security resources (such as user databases and public key infrastructure [PKI]), client applications, and many more factors.

If you have previous experience with the breadth of topics within WLAN security, you’re probably wondering how we will address enterprise security design in a single chapter. Our answer to that question is that, in some instances, we will defer to more exhaustive resources, such as the Certified Wireless Security Professional Official Study Guide: Exam PW0-204 (Sybex, 2010), on some topics. However, we will attempt to address the most important security design strategies from head to toe. With that challenge ahead, let’s get going.

WPA-Enterprise and WPA2-Enterprise

As we discussed in Chapter 11, “Basic LAN Security Design,” the Wi-Fi Alliance introduced WPA and WPA2 for different reasons. WPA includes support for TKIP encryption for backward compatibility with legacy devices, whereas WPA2 includes support for both CCMP and TKIP for future-proof and backward-compatible encryption. There are a few significant differences between WPA/WPA2-Personal and WPA/WPA2-Enterprise—the most important difference is the method and strength of authentication. We will focus on that here.

As we discussed in the previous chapter, WPA/WPA2-Personal employs passphrase or PSK authentication in an attempt to maintain simplicity. In some instances—such as for devices with limited authentication support or for those requiring fast secure roaming—WPA/WPA2-Personal may be useful in the enterprise, but where possible, WPA/WPA2-Enterprise is preferred because of its superior security.

WPA-Enterprise and WPA2-Enterprise employ the 802.1X port-based access control authentication standard along with the Extensible Authentication Protocol (EAP).

802.1X-2004

The 802.1X-2004 standard defines a framework for authentication in which access to network resources is managed via controlled and uncontrolled authentication ports (port-based access control). During a client authentication, the 802.1X/EAP exchange is permitted on the uncontrolled port of the authenticator (i.e., the AP or WLAN controller). When a successful authentication completes, the controlled port is unblocked, providing client access to network resources. A conceptual rendering of port-based access control within the authenticator is shown in Figure 12.1.

802.1X-2004 also defines supplicant, authenticator, and authentication server (AS) roles for the devices participating in an 802.1X authentication exchange. These roles and devices are shown along with the generic 802.1X/EAP framework in Figure 12.2.

WPA/WPA2-Enterprise security introduces the requirement of an authentication server (as prescribed by 802.1X-2004), which is usually a RADIUS server. The authentication server (AS) must also query a user database of some type for user authentication. These AS and user database requirements are not present in WPA/WPA2-Personal networks, which is why WPA/WPA2-Enterprise is significantly more complex than WPA/WPA2-Personal. Integration, availability, and configuration of the AS and user database plays a large part in this complexity.

Extensible Authentication Protocol

The Extensible Authentication Protocol (EAP) is a generic authentication framework defined by IETF (RFC 3748) that provides flexibility for different implementations that serve specific needs. Specific EAP types—such as PEAP or EAP-TLS—are based on the EAP framework and have been created by various organizations (infrastructure, client, and supplicant vendors, neutral industry organizations, etc.) to meet market demands. The generic EAP framework is shown in Figure 12.2. We will discuss the most common EAP types later in this chapter with a focus on their strengths, weaknesses, and ideal use cases.

As we mentioned, 802.1X introduced several roles that are important for enterprise authentication. The supplicant and authenticator are the entities within the endpoints of the Wi-Fi connection—that is, the client device and the Wi-Fi infrastructure, respectively. Since 802.1X/EAP authentication relies on an additional component called the authentication server, we must look at the backend infrastructure entities that facilitate this function.

AAA

To perform the role of the AS, an Authentication, Authorization, and Accounting (AAA) server is typically used. AAA is defined by the IETF in a number of different RFCs (see the sidebar “More Information about AAA”). These three services are essential for user-based access control in the enterprise.

Here’s a description of each of the three components of AAA:

Authentication Authentication is the process by which a user’s or device’s identity is verified against a trusted, reliable database. In other words, authentication validates that you are who you say you are. The process of validating an identity usually comes in the form of comparing user-provided access credentials, such as username/password combinations, digital certificates, one-time passwords (OTP), smart cards, and/or biometrics, with the same credential stored in the database.

Authorization The next step in the AAA process is authorization. After a user or entity is positively identified (authentication), they are allocated or restricted from network resources in accordance with the privileges of their role, as defined by a user or group policy. In other words, the user’s role is associated with permissions, and these permissions dictate how a user’s connection is handled within the network. This application of a policy often comes in the form of specific ACLs, firewall rules, bandwidth restrictions, VLANs, as well as other permissions like time of day, length of connectivity, and physical location restrictions. Policies can be as simple or complex as necessary, but the assignment of these policies is a function of authorization.

Accounting The third function for an AAA server is accounting. Once resources have properly been authorized and a user has performed actions while connected to a network, it is important to track and log those actions so that an accounting trail is available. General accounting functions include monitoring and logging of events, behavior analysis, and reporting of network threats/events. AAA server accounting reports the who, what, when, and where of network use, and may be used to generate alarms or notifications. Accounting records aren’t very detailed, but they at least give enough information for an investigation to be performed based on specific time events and other useful information.

The basic function of an AAA server is that of an access controller. AAA clients (e.g., Ethernet switches, APs or WLAN controllers, guest access controllers, or VPN servers) provide services to end users on a network. However, most AAA clients do not maintain local user databases with lists of permissions and access rules. Therefore, AAA clients often defer authorization of end user devices to an AAA server, which acts as a middleman between the AAA client and user database to control authentication and authorization for network services. End user devices request access to network services, the provider of the network service (i.e., the AAA client) proxies the request to the AAA server, and the AAA server validates the client’s authentication and authorization status by checking against a user database—or by validating a specified condition, such as username, MAC address, password, VLAN, time of day, etc. Once the AAA client receives a user’s permission rules, it can apply the policy to actual data traffic as necessary.

Selection

In most cases, enterprise networks will already have a fully operational and interoperable (with a user database, that is) AAA server in the network. For this reason, wireless design professionals may have little or no control or input regarding the AAA server that is used for Wi-Fi authentication. This is also true of user databases. In most cases, services for the Wi-Fi network are added onto existing infrastructure solutions. This may limit the scope of the wireless professional’s selection tasks to that of integration with existing infrastructure and does not typically require selection or configuration of these platforms. That being said, it is not against best practices to use a different AAA server for wireless authentication. Since it may be a different server anyway, using a different server product is possible.

Every small-medium business (SMB) and enterprise network has a user database, and most databases are compatible with the Lightweight Directory Access Protocol (LDAP) retrieval protocol. In fact, some enterprises have more than one user database, which will add complexity to the design. However, not all networks use LDAP, so it is important to know what is and what isn’t supported by the user database. The AAA server must use a protocol that is capable of exchanging authentication, authorization, and accounting information with the existing user database(s). Generally speaking, the AAA server’s role is as a middleman between the WLAN authenticator and the user database. This functionality is provided by means of a common protocol between the authenticator and AAA server (usually RADIUS) as well as the AAA server and user database (often Microsoft Windows Active Directory or LDAP). The AAA server takes requests from the authenticator and queries the user database for information. For most networks, this exchange is not just about validating a username and password, but may also include the assignment of user or group privileges based on attributes held in the user database. Figure 12.3 illustrates how an AAA server will have to proxy authentication requests to many different databases, including a PKI infrastructure, which we will talk about later in this chapter.

Beyond integration and compatibility with existing infrastructure components, one of the most important features for an AAA server may be support for information attributes, which are parameters that may be used as a method of assigning network privileges to users or devices. For example, RADIUS supports something called RADIUS attributes or attribute-value pairs (AVPs), which can be used for many purposes, including client assignment of user groups, VLANs, IP addresses, throughput limitations, as well as many other functions. If this type of granular control is desired, RADIUS is usually the best AAA server implementation because it is well supported by WLAN infrastructure vendors and is a flexible protocol. We’ll discuss RADIUS more in the next section.

However, not all network configurations will provide this type of granular user authorization from the AAA server. More to the point, some enterprises assign network permissions by providing multiple SSIDs at each AP and configuring each SSID with the relevant privileges for that group of users. This allows for the network service level to be defined within a WLAN profile—sets of parameters that apply to the service set. When users are authenticated to a specific WLAN profile, they are automatically subject to the restrictions or privileges of that service set. The AAA server’s role is simply to ensure that they are permitted to be a part of that service set.

Using SSIDs as a method of differentiating user groups is an inefficient use of the wireless medium, thus posing scalability problems when multiple different levels of service are desired. Unless specific 802.11 operational parameters, such as authentication or encryption methods, need to be different for each client device set, we highly recommend that you merge services to fewer SSIDs and assign client device authorization using the authentication identity of the supplicant.

Of course, the method of applying user-specific privileges depends on many factors. Some WLAN vendor equipment does not have robust support for return attributes from the AAA server, so policies are assigned by the WLAN profile within the WLAN infrastructure. Most enterprise vendors support the full gamut of AAA server authorization parameters as well as many proprietary ones, which allows for more flexibility in the assignment of user permissions as well as better integration with an array of preexisting user databases and group policies. In most enterprise deployments, the WLAN profile provides the primary policy and performance set for users, while the AAA server provides additional user-specific authorization criteria.

Another important selection criterion for AAA servers and user databases is support of EAP, and more important, the specific EAP type that will be used for authentication. As we will discuss later in this chapter, some EAP methods have received more widespread acceptance than others. If a specific EAP type is required, ensure that your AAA server supports it and that the user database can return the required credential to the AAA server.

It is possible to replace an external AAA server altogether by enabling the authenticator to query the user database directly. For example, an AP or WLAN controller can authenticate directly to Windows Active Directory’s LDAP implementation. Some vendors are beginning to build Windows Active Directory support into their WLAN infrastructure products. Because of Active Directory’s popularity and the fact that it is built on a framework that can include a great deal of information about users and devices, the equivalent of AVPs can be achieved through this method. For smaller and simpler WLAN designs, this might be a valuable option to explore if your equipment vendor supports it. The primary problem with using a direct LDAP query model is that it may limit the EAP type support and communication protocols used for authentication; for that reason, few enterprises currently use this model.

RADIUS is by far the most common and best supported AAA server in use today, and most of this book is based on RADIUS as the AAA server. Before we do that, let’s clear up some basic terminology.

Authentication Roles and Terminology Within 802.1X terminology, the wireless client station is called the supplicant, the AP or WLAN controller is referred to as the authenticator, and the RADIUS server is called the authentication server (AS). A bit confusingly, with RADIUS terminology, the AP or WLAN controller may be called the network access server (NAS) or even the RADIUS client. The wireless client station is called the user. To add just a tad more complication, with generic AAA terminology the AP or WLAN controller is the AAA client. Table 12.1 shows this terminology in a more organized fashion.

TABLE 12.1 802.1X, RADIUS, and AAA terms

RADIUS

Most EAP types used with WLANs rely on RADIUS to perform the AAA functions of the AS. The 802.11 and 802.1X standards don’t require this, but in practice, RADIUS is the method of choice.

RADIUS is an application-layer protocol that provides User Datagram Protocol (UDP)-based client/server AAA services across an IP network. RADIUS servers come in many different form factors, and are commonly deployed as a service running on a server cluster, as a dedicated RADIUS appliance, or even as a service within an 802.11 access point or WLAN controller.

There are also many different ways to implement RADIUS within a network architecture, including:

• Local RADIUS with internal user database(s)
• Local RADIUS proxying to external user database(s)
• Distributed RADIUS with internal user database(s)
• Distributed RADIUS proxying to external database(s)
• RADIUS proxying to other RADIUS servers
• RADIUS integrated into the WLAN infrastructure

The most common method in the enterprise is to provide local RADIUS services that proxy to a local user database. However, distributed RADIUS with an internal or external user database is also common for some networks that span many campuses and remote offices. Distributed RADIUS architectures will help lighten the processing demands on a single, centralized RADIUS server and will increase availability.

Deciding on a RADIUS Architecture

The location of the RADIUS server(s) within the network architecture can have a massive impact on network performance, especially when there is significant latency and many network hops between the RADIUS server and WLAN infrastructure devices. This delay will also be increased if even more latency is added between the RADIUS server and the user database(s).

Each time a client station authenticates (during initial association or reassociation) to the WLAN, it will have to communicate many authentication messages (depending on EAP type and roaming enhancements) to the RADIUS server. If the RADIUS server is separated from the local LAN over a WAN link, you will often see severe latency and performance degradation for roaming users for some applications. Applications such as video and voice over Wi-Fi are the most notable, but any real-time application will suffer the same results. Further, since RADIUS is a critical component in allowing new users onto the network, remote RADIUS can be a major problem if the WAN link is prone to outages, or if the link is commonly saturated with traffic. Similar drawbacks exist if the RADIUS server—even a local one—is querying a remote user database for client authentication.

Providing Redundant RADIUS Servers

Regardless of the way in which RADIUS is deployed, providing redundant RADIUS servers is a strongly recommended practice to protect against a single point of failure. Redundancy is often accomplished via replication strategies. One RADIUS server may be designated as the primary server, and the primary RADIUS server’s configuration may be replicated to other RADIUS servers to maintain consistency of configuration. If the primary RADIUS server fails, the same configuration is present on all of the slave or secondary RADIUS servers, providing the same authentication experience as the primary server.

Similarly, in the interest of providing maximum network uptime, RADIUS failover configurations within the WLAN infrastructure should also be provided. For example, if your primary RADIUS server is in your local office, what happens if that RADIUS server fails? Or, if your primary RADIUS server is across a WAN link, what happens when the WLAN can’t reach that RADIUS server? In highly available designs, a failover RADIUS server will be designated in the WLAN configuration so that a single RADIUS failure or even a WAN link failure will not cripple network access. Most WLAN vendors provide an option for at least a primary, secondary, and tertiary RADIUS server.

Understanding Attributes

One of the major strengths of RADIUS is that it has been very widely accepted and implemented. This allows for pervasive and extensive support of RADIUS attributes, also known as AVPs. RADIUS attributes are parameters within RADIUS frames that contain specific data elements for communication between the authenticator and RADIUS server. Each specified attribute has a specific function, and there are more than 100 attributes.

For example, the RADIUS EAP-Message attribute carries the EAP-specific data from the authenticator to the AS, and vice versa. So, this attribute would be used to carry EAP-Success or EAP-Failure messages. Many of the attributes are used for normal RADIUS services, such as the User-Name attribute, the User-Password attribute, and the NAS-IP-Address (authenticator’s IP address) attribute. These three refer to the client username, the client password, and the authenticator’s IP address, respectively. However, RADIUS attributes can also be used for other purposes, such as dynamic VLAN assignment, QoS settings, bandwidth constraints, or WLAN group assignment.

Due to its widespread use and applicability to many different network services, RADIUS also supports something known as vendor-specific attributes (VSAs). As you might guess, these are vendor-proprietary attributes that serve a special function to the vendor that defines it. An example of a VSA used for a particular equipment vendor’s product might be to enable or disable a proprietary feature based on individual user/machine authentications.

Configuring RADIUS

There are some basic configuration processes with RADIUS that we would like to mention. Each version of RADIUS will differ in features and configuration options, but there are many similarities across platforms. Generally speaking, RADIUS must be configured with RADIUS clients (AAA clients), user databases, and specific EAP and RADIUS authentication parameters.

Configurations of RADIUS servers for each AAA client are generally fairly minimal. The AAA client (AP or WLAN controller) must be added to a list on the RADIUS server. Configuration of each AAA client includes the IP address, RADIUS shared secret, authentication protocol, communication ports (usually UDP 1812/1813 or 1645/1646), and a handful of other parameters. In some instances where multiple AAA clients are being added—as with clusters of WLAN controllers, or when large populations of APs are the AAA clients—entire subnets may be added to the RADIUS configuration profile to ease the management overhead of manually entering tens or hundreds of IP addresses. The RADIUS shared secret is used for authentication of the AAA client to the RADIUS server. It is also used in some RADIUS frames as an input to a hash function to convert elements of the RADIUS message into a hashed message digest.

In addition to configuring AAA clients, RADIUS must also be configured with a user database. When a local/native RADIUS user database is implemented, users and groups can be created and configured with very detailed access policies that are assigned to users as a part of the authorization process. When external databases are used, configuration varies in accordance with the type of database in use and the retrieval protocol. As an example, when LDAP compatible databases are used, the RADIUS configuration includes the LDAP hostname, port number, protocol version, security parameters, directory-specific details, server timeout values, and many more parameters. Figure 12.4 shows Cisco’s ACS RADIUS configuration menu for querying an external LDAP database.

In addition to more traditional centralized user databases such as Windows AD or Novell eDirectory, RADIUS may also proxy authentication requests as a client to other types of user databases, such as token servers. We will discuss token authentication in a later section, “Authentication Form Factors,” where we look at specific EAP types. In brief, token servers are user databases that are synchronized with the RADIUS server. The token server maintains a continually incrementing token value (e.g., it may increment every 60 seconds) that stays synchronized with the hardware token possessed by a user. In order for the client to be authenticated to the network, it must demonstrate possession of the hardware token by referencing the current value that is displayed on the hardware token, which should match the value calculated in the token server. This type of authentication adds a layer of security in the form of a hardware token (something the user must possess).

Finally, there are many other parameters that are configured on the RADIUS server. These include RADIUS authentication protocols (PAP, CHAP, etc.) for AAA client authentication, management of certificates, administration management, activity logging and accounting, replication, enabling of specific EAP types and configuration of relevant parameters, and much more.

There are many popular versions of RADIUS on the market today, including Microsoft’s Internet Authentication Service (IAS) and Network Access Protection (NAP), Cisco’s ACS, Juniper’s Steel-Belted RADIUS, FreeRADIUS, Open System Consultants’ Radiator, and Periodik Labs’ Elektron, to name a few. In addition, APs and WLAN controllers often have limited-feature RADIUS servers built into them.

Server Selection

In the section discussing AAA servers, we mentioned that you should consider the EAP type desired for use when selecting a AAA server. To take that point a little further here, you will find that some RADIUS servers are highly limited in their EAP support. Some organizations may want to deploy multiple EAP types; sometimes even multiple EAP types on the same SSID. Perhaps those different EAP types require separate user databases or authentication backends. You will find that, unfortunately, not all RADIUS servers allow this type of implementation. Some RADIUS servers are more flexible than others, whereas some RADIUS servers are easier to use than others. You should define your WLAN security needs before selecting a RADIUS server when at all possible.

User Databases

We’ve already discussed a few of the topics related to user databases in WLANs. In many cases, WLAN designers won’t have any influence in the selection or configuration of a user database, but this doesn’t mean that user databases are an irrelevant topic.

Predominantly, RADIUS servers will proxy to existing centralized user databases. In some smaller businesses, user databases are not centralized and remain local to the server providing services. For example, a network access storage (NAS) server may have an internal database with groups and users. Similarly, FTP or VPN servers may have their own user databases that are used to control access to FTP and VPN services. As you might imagine, in this type of network with distributed user databases for each service, wireless network access will rely on a dedicated user database within the WLAN infrastructure itself or possibly within the RADIUS server.

Local RADIUS or WLAN databases are scalable to a certain limit within small and medium businesses, but at some point, centralizing the user database for network privileges in enterprise networks makes far more sense. The point at which these native databases become problematic is not really clear-cut. It will vary for each network, and will depend on the types of services provided on the network, the capabilities of the native RADIUS or WLAN infrastructure database, and the management burdens that come from multiple disparate user databases.

All of the most popular RADIUS on the market include local user databases. RADIUS servers that are designed for the enterprise include configuration options to apply authorization parameters to the user. Basic user authorization parameters include IP address assignment, ACLs, group assignment, and more. Of course, most configurations also employ group policy settings that might include IP address pools, ACLs, RADIUS return attributes, time of day restrictions, and more.

Similarly, enterprise-class WLAN infrastructure vendors have also incorporated native user databases into their products as a standard feature. In some cases, user-based management within the WLAN infrastructure provides a robust enough feature set that there may not be much need to depend on a centralized user database for WLAN authorization in smaller environments. The caveat is that most of these integrated RADIUS offerings are limited in options and what EAP types are supported. However, if a simple authentication is all that is desired, then it may suffice for some.

Some WLAN infrastructure products with built-in firewalls and granular user policy engines provide additional filtering and access restriction capabilities. In this model, you may authenticate users against a centralized user database, and configure a RADIUS return attribute to assign a WLAN user to these groups defined within the WLAN infrastructure configuration. In other words, you configure the WLAN infrastructure with the authorization parameters for a user and/or group. When many of the performance- and security-related parameters are already defined by an SSID, this may be a nice option for some design scenarios.

Extensible Authentication Protocol

The Extensible Authentication Protocol (EAP) is used with all WPA/WPA2-Enterprise deployments. EAP is the authentication protocol used between the supplicant and authenticator, and is defined in RFC 3748. EAP is also encapsulated in RADIUS messages between the authenticator and RADIUS server.

As of this writing, the Wi-Fi Alliance certifies devices for support of up to seven EAP types:

• PEAPv0/EAP-MSCHAPv2
• PEAPv1/EAP-GTC
• EAP-TTLS/MSCHAPv2
• EAP-TLS
• EAP-FAST
• EAP-SIM
• EAP-AKA

Of these, there are several popular EAP types available, each with their own strengths and weaknesses. Some are very secure at the expense of high management overhead or high cost, whereas others are easy and cost effective to implement but may not provide the preferred level of protection or the desired authentication form factor. These and other trade-offs must be factored into the selection and configuration of a specific EAP type.

In fact, one of the primary advantages of EAP is choice. By definition, it is extensible, so designers have a wide range of options to meet their deployment needs. If broad client support is important, there’s an EAP type for that. If simple client configuration is important, there’s an EAP type for that. If utmost security is important, there’s an EAP type for that.

Thankfully, some EAP types provide a suitable balance between these variables, which makes their use much more prolific. Before selecting a specific EAP type, let’s discuss a few more considerations that are relevant to this decision.

Choosing an EAP Type

As just discussed, there are various EAP types and your needs will determine which one is best for you. Here’s a list of the main topics to consider:

Determining Authentication Strength Authentication strength is probably a priority for most companies. Some EAP types are stronger than others, but with only a few exceptions—EAP-MD5 and EAP-LEAP—most EAP types are sufficiently strong to be unequivocally recommended for the enterprise—perhaps excepting government-level security. Mutual authentication is an important piece to the security puzzle, and nearly all of the modern EAP types support it.

Understanding Tunneling Another important factor related to authentication strength is that of tunneling. With most secure EAP methods, a Transport Layer Security (TLS) tunnel is created using the server’s X.509 certificate. This is much like a web-based e-commerce transaction where your web browser uses the web server’s SSL certificate to send your credit card securely in an encrypted tunnel. For EAP, within the TLS tunnel, the client’s authentication credentials are passed across the wireless medium and then across the wired network within this secure tunnel to the authentication server. This is a strong way to protect client credentials from exploitation. In fact, this is the very reason that relatively weak client authentication protocols—such as MSCHAPv2—can be securely used. EAP-TLS does not require tunneling because both client and server certificates are used for authentication. Since certificates are inherently resilient to compromise, there’s no need to build a TLS tunnel, though there is an option for it.

In the original EAP specification, there is a requirement for the client’s username to be passed at the beginning of the EAP exchange. Legacy EAP types, such as LEAP, send the client’s actual username in clear text at the beginning of the authentication exchange. This information exposure is a major contributor to LEAP’s weaknesses. For tunneled EAP types, there is a provision for the client to provide a bogus username in this initial “outer identity.” Then, inside the TLS tunnel, the real username is transferred. For that reason, the most secure EAP types—with the exception of EAP-TLS—require tunneling.

Considering Ease of Use and Management Overhead Ease of use and management overhead are two additional considerations when choosing an EAP type that are also very important for most companies. These two qualities are often dependent on the method for client authentication that is specified by an EAP type. For example, simple username/password pairs are fairly easy to implement and control. On the other hand, client-side certificates and client smart cards, while secure, often add a significant amount of complexity to the deployment.

Evaluating Cost Cost is another important factor. As in the previous discussion about simplicity, usernames and passwords are easy to implement and don’t require additional infrastructure, so they’re inexpensive. However, client smart cards and one-time password (OTP) tokens require additional infrastructure components, such as card readers, token servers, and the like. This adds cost in the form of hardware, service contracts, electrical power, and additional possibly staff resources. Some models require client-side certificates, which may require the purchase of client-side certificates for each client device. Even if a private PKI is used, it also comes at a significant cost.

Accommodating Your Current Infrastructure Another important consideration is that of existing infrastructure. What is required to implement a specific EAP type? If a PKI is required, is one already in place? If not, that may eliminate it from contention. What about requiring smart cards or security tokens? Are these infrastructure components already in place for other network technologies? If so, adding Wi-Fi authentication will be much easier. If not, perhaps other solutions with lower cost, lower management overhead, and quicker deployment cycles would be a better fit.

Similarly, your existing RADIUS server may not support all flavors of EAP. Some RADIUS servers are very limited in this realm, so you should evaluate the existing services before deciding on an EAP type—or multiple EAP types—that may ultimately require new servers.

Determining Client Support Finally, everything else aside, one of the largest considerations for EAP selection is client support. Some EAP types are proprietary and are limited to a small subset of client devices. Other EAP types have not been widely embraced by the industry; thus the EAP types are not supported in many client supplicants. Some client devices support only a few EAP types.

Thankfully, many of the most useful EAP types have received widespread support—or maybe they’re useful because they’ve received widespread support—and are available across a broad range of client supplicants and operating systems. In any case, this requirement is very important. Designers must understand the EAP types that are supported by the client devices within the network. PEAP is one of the most popular EAP types for this reason. It is almost ubiquitously supported.

Interestingly enough, EAP selection has very little to do with the WLAN infrastructure in use. In essence, EAP is passed from the supplicant to the authentication server through the authenticator, so the WLAN infrastructure is typically an irrelevant variable in the selection of a specific EAP implementation—that is, unless the WLAN infrastructure is not the RADIUS server as mentioned earlier. For the sake of this discussion, we are considering the traditional design of 802.1X authentication.

Frankly put, there is no perfect EAP solution that fits every scenario. However, there are popular, secure, cost-effective, and relatively easy-to-implement EAP methods. With a focus on the previous list of design considerations, we will explore specific EAP types in the following sections. For reference, Table 12.2 provides an organized overview of the most common EAP types and their features.

TABLE 12.2 EAP Types and Features

EAP-LEAP

EAP-LEAP is a popular, proprietary EAP type that was created by Cisco and is used primarily in Cisco implementations. Because of LEAP’s previous market success, it was licensed by several other vendors. Due to Cisco’s market influence, many customers deployed LEAP in the early stages of their autonomous WLAN deployments. For that reason, LEAP is still fairly common in the enterprise. However, a well-known vulnerability exists for LEAP whereby attackers can recover the client username and hashed password of LEAP supplicants using brute-force dictionary attacks—made popular with a tool called ASLEAP. For that reason, LEAP has been deprecated by Cisco and is no longer recommended for use. It has also been deprecated by the Wi-Fi Alliance.

LEAP performs no validation of the authentication server. The supplicant provides the client-side username/password in a modified version of the MS-CHAPv2 protocol to authenticate the client. Other EAP types use similar credentials in a secure way.

Because of LEAP’s vulnerability, it is recommended that users of LEAP migrate to a more secure solution as soon as possible.

Protected EAP

The most popular EAP type in use today is a version of Protected EAP (PEAP). PEAP is often referred to as “EAP-in-EAP” because it prescribes the creation of a TLS tunnel—which is made possible by requiring server-side X.509 certificates—and then uses variant EAP types (such as EAP-MSCHAPv2, EAP-TLS, and EAP-GTC) to authenticate the client within the tunnel. These two steps are often referred to as phases:

Phase 1 This includes the client authenticating the server (by validating its certificate) and the construction of the TLS tunnel.

Phase 2 This is the EAP-in-EAP client authentication within the TLS tunnel. Phase 2 is different for each version of PEAP.

There are two primary types of PEAP, referred to as PEAPv0 and PEAPv1. Unlike most protocol versions within the information technology security industry, these version numbers have no bearing on their relevancy or security merits.

PEAPv0

There are two common subtypes of PEAPv0. PEAPv0/EAP-MSCHAPv2 is the most widely implemented EAP type in use today. PEAPv0/EAP-TLS is a very strong EAP type but has not received widespread use. In fact, you will find it rare to encounter in the real world. This is largely due to the fact that it requires client-side TLS certificates and is not widely supported by RADIUS servers.

PEAPv0/EAP-MSCHAPv2

PEAPv0/EAP-MSCHAPv2 uses an MS-CHAPv2 challenge/response within the TLS tunnel, providing client authentication via a username and password pair. As with all versions of PEAP, the server is authenticated with an X.509 certificate, assuming the client is configured to do so. Validating the reliability of the server’s certificate is an optional step and at the full discretion of the supplicant.

PEAPv0/EAP-MSCHAPv2 has been very well adopted within the industry, and is supported by almost every client device and operating system on the market. Similarly, all RADIUS servers support it. It is easy to configure because the client only requires a username/password pair, and it is highly secure. As with any EAP implementation requiring a server-side certificate, the biggest challenge is configuration and generation of the server certificate as well as distribution and installation of the server certificate on the client device. We will discuss certificates in a later section, but in the meantime, it is important to know that X.509 certificates are very secure and are pretty much a way of life within 802.1X/EAP.

Due to all of these factors, PEAPv0/EAP-MSCHAPv2 is a highly recommended and very popular EAP type. Because of its advantages and relative lack of weaknesses, it is the go-to EAP method in most deployments. The only way PEAP lacks strength is how it is implemented. Poor password policy is one method and the supplicant failing to validate the authentication server’s certificate is the other.

PEAPv0/EAP-TLS

PEAPv0/EAP-TLS has not seen anywhere near the same widespread use as PEAPv0/EAP-MSCHAPv2. This is largely due to the use of EAP-TLS for client authentication. Furthermore, it offers little benefit to what EAP-TLS already offers by itself, though it does hide the client ID in the TLS tunnel. As you already know, the server requires a certificate with PEAP; however, with PEAPv0/EAP-TLS, client authentication is also performed with a client-side certificate. This means that every client device using the network must have its very own certificate. For that reason, this EAP type requires a PKI for certificate creation, management, distribution, and storage. Otherwise, a very large budget would be necessary to purchase client certificates from a third-party PKI vendor. That aside, distribution and installation of these certificates on client devices is a burden in itself. In other words, complexity and overhead increase significantly.

Despite the management drawback of PEAPv0/EAP-TLS, this EAP type is very secure. In fact, along with EAP-TLS (non PEAP), PEAPv0/EAP-TLS is thought to be the most secure EAP type in common use. However, EAP-TLS (non-PEAP) has many of the same advantages and drawbacks as PEAPv0/EAP-TLS, which is why PEAPv0/EAP-TLS has not been widely used in the marketplace. EAP-TLS is already well supported, but PEAPv0/EAP-TLS is only sparsely supported. Thus, companies tend to adopt EAP-TLS before PEAPv0/EAP-TLS.

To avoid confusion, we should also point out that EAP-TLS in PEAP has recently been submitted as PEAPv2. So, you may see that nomenclature instead of PEAPv0/EAP-TLS.

PEAPv1/EAP-GTC

PEAPv1/EAP-GTC follows the same basic constraints of PEAPv0 mentioned previously, but uses an inner-EAP type following the Generic Token Card (GTC) method prescribed in the original EAP RFC (RFC 3748). In this mode, again PEAP uses a server-side certificate to establish the tunnel. Within the tunnel, the authentication server sends an authentication message to the client and the client responds with virtually any generic token that may be a username and password. It also may generate a response based on a hardware token. In this case, the user manually enters the information shown on the hardware token. With EAP-GTC, the authentication server acts as a client to a backend token server that maintains synchronization with the end user’s token hardware.

PEAPv1 had a divisive beginning, as Cisco was attempting to slow the use of PEAPv0 (created in part by Microsoft) in favor of its own method. PEAPv1 has received pretty widespread use in the marketplace, largely since it actualizes the advantages of multifactor authentication, but multifactor authentication is possible via other EAP methods as well. Specifically, users must both know something (a pin) and possess something (a hardware token) in order to be authenticated. One of the drawbacks of this method is that it does require additional infrastructure and end user hardware as well as additional configuration and maintenance.

EAP-TTLS

EAP-TTLS (Tunneled Transport Layer Security) represents another secure tunneled EAP type that is fairly common. EAP-TTLS shares many qualities with PEAPv0/EAP-MSCHAPv2, but has not been adopted quite as widely. However, it has gained some popularity and is supported by all major third-party supplicants.

One of the unique characteristics of EAP-TTLS is that it supports many inner authentication protocols. Some of these include legacy authentication modes. Inner authentication options include PAP, CHAP, TLS, MS-CHAP, and MS-CHAPv2, within the TLS tunnel. For that reason, you will often see EAP-TTLS notated as EAP-TTLS/MSCHAPv2, which is the most common implementation, and is the only EAP-TTLS method certified by the Wi-Fi Alliance.

Similar to PEAP, EAP-TTLS uses a server-side certificate for server authentication and TLS tunnel creation. It also uses simple username/password pairs for client authentication. EAP-TTLS is relatively easy to configure, cost effective, and highly secure. Assuming all clients within the network support it, EAP-TTLS is a good option and is a recommended EAP choice.

EAP-TLS

Sharing many of the strengths and weaknesses already mentioned with PEAPv0/EAP-TLS, EAP-TLS is a very secure EAP type that is well supported by infrastructure and client manufacturers. Due to the added complexity of a PKI, many companies opt not to use EAP-TLS, instead favoring more user-friendly methods.

Despite this, many companies and government organizations desiring maximum security will use EAP-TLS. As we’ve seen in the previous set of EAP types, tunneling is pretty common. However, EAP-TLS supports both non-tunneled and tunneled modes. Most implementations opt for non-tunneled mode because tunneling is simply unnecessary. Since the client uses a certificate just like the server, there’s no need to transport it within a TLS tunnel. The only value tunneled mode provides for the client certificate is obfuscation of the clear-text owner of the client in the client certificate response. That being said, PKI is already inherently secure, based on the fundamental principles of certificate trust and asymmetric cryptology (we will discuss these later).

To add an element of security, parts of the US government use Common Access Cards (CAC), which are a specific type of smart card. Essentially, the CAC card contains user-specific data and an embedded client certificate, which is read by a card reader and can be used for client authentication. As with EAP-GTC, this method add an authentication form factors, providing more dimensions to the security process. It requires the user to know something and possess something. A sample CAC card is shown in Figure 12.5.

When a PKI is already in place or high security is a primary concern, EAP-TLS is a good choice. For most enterprises, the additional security is unwarranted, given the additional management overhead and cost.

EAP-FAST

EAP-FAST represents another Cisco-proprietary EAP type. EAP-FAST was marketed and positioned as the successor to LEAP. It was released around the same time that the LEAP vulnerabilities were made public, providing a recommended transition for existing LEAP users. Instead of using certificates for tunneling, EAP-FAST uses something called protected access credentials (PACs). We could extend this section by looking at the many details of a PAC card, but we’ll defer that topic to other texts, such as the CWSP study guide.

For this text, it is important to know that a PAC shares elements of both digital certificates and shared secrets. The PAC must be generated and installed on the server side and then each client must also receive an individual PAC, which adds a bit of management overhead. Depending on the method for provisioning PACs to clients, security vulnerabilities may be present. Specifically, EAP-FAST supports either automatic or manual PAC provisioning. The automatic method is much easier from an administrative perspective, but it introduces the possibility, though minimal, of attacks. This is because automatic PAC provisioning can be anonymous (meaning the provisioning agent is not authenticated or otherwise validated), which enables exploitation of clients while they are “open” to automatic PAC provisioning.

An EAP-FAST client can also be vulnerable to man-in-the-middle attacks unless it is configured to speak only to a specific authentication server. For example, an EAP-FAST client that is configured for anonymous PAC provisioning may erroneously trust an attacker’s device, provision a PAC, and subsequently use that PAC to transmit its credentials to the attacker.

EAP-FAST is gaining in popularity, though it is not extremely common. Assuming manual PAC provisioning is used, EAP-FAST is highly secure, but, in the management overhead realm, it starts to look a bit like EAP-TLS at that point and therefore exhibits the same drawbacks. EAP-FAST may be less recommended than other EAP types, but can be quite easy to deploy.

Other EAP Types

Of the seven EAP types, we’ve already discussed five. As Wi-Fi and cellular technologies continue to converge, we are beginning to see broader use of EAP types that are used in the cellular space. EAP-SIM and EAP-AKA represent these options. Though they are not currently deployed as primary Wi-Fi EAP types, EAP-AKA will likely begin to see more use along with better fixed mobile convergence (FMC) adoption.

Authentication Form Factors

As you may have noticed in our previous discussions, there are several different authentication form factors to choose from. From username/password pairs and X.509 certificates to OTP tokens and PACs, there are many different choices with varying strengths and weaknesses. In some networks, multiple form factors may be layered to provide additional security. This is often known as multifactor authentication. Authentication factors are often broken down into three components:

• Something you are
• Something you know
• Something you have

Most Wi-Fi networks are not currently using biometrics (something you are) for authentication, but this is certainly a potential option. Similarly, some authentication methods require users to log into a computer, then enter a pin number to launch network authentication (something you know). Following that, the user may be prompted for a smart card (something you have). This type of layering, as usual, adds overhead and complexity, but it also adds security. In the next section we will focus on machine authentication.

Machine Authentication

Machine authentication is a way of authenticating the device through which a user will connect to the network. It is used for two primary use cases.

First, machine authentication facilitates an active network connection for devices that require a user login before the user desktop environment is loaded, such as the case with Windows-based computers. A machine authentication will provide a network connection to validate the username and password entered at the operating system login prompt, behaving much like the machine is wired to an Ethernet network. More to the point, many networks provide services to computers by virtue of domain connectivity via the network. With Wi-Fi connectivity, these services are very difficult to provide without the use of machine authentication. These services include remote desktop access, software upgrades, roaming user profiles, noncached user profiles, OS patches, or the like. Upgrades, patches, and other remote administration tasks can be accomplished by authenticating a machine to the network even when a user is not directly authenticated to the WLAN.

The other use case is related to ensuring people only use the network from enterprise assets. In other words, a user authentication might be forbidden unless a machine authentication has been performed first. For user-driven network use, user-specific authentication (what we’ve been describing thus far in this chapter) usually follows machine authentication but is not necessary.

There are a handful of design considerations that are relevant to machine authentication, but the first requirement is that your client supplicant support it. Furthermore, it is only relevant for computers that require login to a centralized user database prior to allowing users to access the desktop environment. For more information on machine authentication, see the CWSP study guide.

PKI and Certificates

In the previous section, we looked at authentication form factors for the 802.1X/EAP supplicant. We also noted that the most popular EAP types employ X.509 certificates for secure server authentication and TLS tunnel creation. In addition, EAP-TLS, PEAPv0/EAP-TLS, and a mode of EAP-TTLS use client-side certificates. For secure environments, certificate selection, management, assignment, and installation is important; we will look at this topic in greater detail in this section.

Public Key Infrastructure

With most of the popular EAP types, the EAP protocol requires a trusted X.509 digital certificate to be assigned to the authentication server. Digital certificates can come from many places, and the source of a digital certificate will often impact the cost, the distribution method (getting it to the proper device), the management overhead, as well as the certificate installation method. Digital certificates may be purchased from a trusted, third-party certificate authority (CA), such as VeriSign, Thawte, or Entrust, or they may be issued by an organization’s internal CA.

Digital certificates (X.509) are a component of a PKI. In a PKI, digital documents are created and securely assigned to an owner. Using highly sophisticated hashing algorithms, digital signatures are created that are extremely difficult to duplicate or change without detection. This digital document is then prescribed as authentic by the issuing agent (i.e., the CA). Inherent in the reliability of a PKI system is trust in the CA. In other words, we will be taking the word of the CA that a certain digital certificate is valid, was securely distributed, and is possessed only by the proper device; it is critical that we be able to trust the reputation of the CA.

All modern computer operating systems have the ability to use PKI, which was made quite popular to allow safe e-commerce transactions. They do this by providing a preinstalled list of CAs called the certificate trust list (CTL). A CTL is queried by Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols during security transactions. The CTL contains a listing of all trusted root certificates known to that PC. The entries on the CTL point to validations (root digital certificates) for the globally trusted CAs. When a digital certificate is received as part of an authentication exchange (such as with the 802.1X/EAP authentication), the SSL/TLS protocol consults the CTL to verify that the issuer of the current certificate is trusted by the CTL. In the case of e-commerce with a web browser, if the issuer of the certificate is not listed on the CTL, then the security protocol will issue a warning to the end user stating that this is an invalid certificate and that it should not be trusted.

For our purposes with WLAN authentication, a nontrusted certificate will cause an 802.1X/EAP authentication to fail. If the certificate is trusted, the client station may reliably use the public key that was provided to it, and this key will facilitate encryption. We will discuss the technical mechanics of this process in a following section.

X.509 Certificates

In most cases, it is easier to implement a PKI by using publicly trusted, third-party CAs because their trustworthiness has been established and confirmed by virtue of being listed on the CTL. For e-commerce and other secure HTTPS login requirements, this is the only recommended method for establishing PKI. But, when using a PKI to perform 802.1X/EAP authentication for a private group of users that are known by the organization, it may not be necessary to purchase the needed digital certificates from a third-party CA. If an organization has a need to create and manage their own digital certificates, they can set up their own certificate-issuing agency by running a private CA application.

CA applications may be included as part of a server operating system, purchased separately as a stand-alone third-party application, integrated with AAA services, or downloaded for free as an open source offering. The certificates created by a private CA are called self-signed certificates, and are perfectly serviceable in every way, for many types of private use. Since you will be the issuer and user of the certificates, you should know whether or not you can trust yourself. In this case, not using a third-part PKI can be considered more secure.

The problem comes when you try to use the certificate. Since your private CA will not be recognized by end user devices because it does not yet have the self-signed certificate in its CTL, your self-signed user certificates will fail the trust test. To address this you will need to distribute this self-signed certificate and install it onto the CTL on every device that will require trust of that certificate. Once that has been done, your self-signed user or AS certificates will perform exactly like the ones purchased from globally trusted CAs.

Selection

Now that we’ve provided some technical background regarding the use of X.509 certificates, let’s look some of the selection criteria for self-signed versus third-party certificates.

Ease of Use First on the list of selection criteria is ease of use. Maintaining self-signed certificates and an internal PKI requires a lot of effort, time, and cost. Many enterprises don’t have a specific need for an internal CA; thus it is much easier to purchase third-party CAs. Internal PKIs can be complex and resource intensive to manage. When a PKI is already in place within an organization, its adoption for use with WLAN authentication may be a bit easier. However, if one is not already in place, most companies will opt for third-party CAs if only server-side certificates are required. The other side benefit of third-party CAs is that once a certificate is purchased, the issuer of the certificate or the root authority of the issuer is already in each client’s CTL. This usually eliminates the need for adding the certificate to each client as would be required with a self-signed method.

EAP Security Requirements Part of the ease-of-use requirement must be weighed against security requirements. As we discussed in the prior EAP section, some EAP types use server-side certificates and client-side certificates. If your organization has many thousands of client devices requiring certificates, it becomes unrealistic to use third-party certificates because there are so many certificates to manage and the cost of purchasing third-party certificates will become exorbitant. In this case, an internal CA and PKI would be recommended. However, enterprises requiring this added security often already have a PKI in place, so the only challenge is adopting the technology for WLAN clients.

Cost and Quantity If a PKI is not in place but is desirable for the WLAN, it can be an expensive proposition. In addition to the cost of infrastructure equipment required to perform the functions, companies must also hire or train staff resources to manage it. Granted, thousands of third-party certificates can become extremely expensive as well, so the cost/benefit analysis must weigh the number of devices requiring certificates. Generally, for fewer certificates, third-party CAs are more appropriate.

Client Installation and Configuration Finally, installation of certificates and client trust configurations are important considerations. For enterprises with managed end user stations, it can be a chore to update certificate trust lists for self-signed certificates (server-side certificates) on each client device. Of course, there are several ways to automate this process so that a domain-wide Group Policy configuration update also updates certificate trust lists. Alternatively, some security companies offer specialized software designed to provide an installation file that configures client devices appropriately. However, this step requires extra time and resources. With third-party CAs, client operating systems receive certificate trust updates via regular OS updates. Assuming that organization’s operating systems are already up-to-date or regularly do OS updates, this is a slightly easier way to manage trust lists. In some environments, such as universities, this may be the preferred way to manage certificate trust since the IT staff does not manage end user devices.

There are many variables in this process, but the important thing is that when designing the network, the client population is considered as a part of certificate administration.

Public and Private Key Cryptography

We’ve already discussed certificate signing, but let’s take a step back to see why this is important. Certificate signing is the process where a CA binds a public key to an organization (DNS name, email address, etc.). This binding process relates to the public key, which is part of a public/private key set. When the public key is signed, the certificate is created, then distributed. This is an important process because the two keys are used for asymmetric key encryption during the PKI session. Most of the confidentiality types we have discussed to this point (WEP, TKIP, and CCMP) use a form of computer security known as symmetric key encryption, which uses the same digital key for encryption and decryption. Management and distribution of symmetric keying material (e.g. PSKs) is left to the IT staff. With asymmetric key encryption, which is shown in Figure 12.6, one key is used for encryption and a different key is used for decryption.

If using an EAP type that uses digital certificates at the AS, the AS will transfer its digital certificate, containing its public key, to the supplicant through the authenticator. This step occurs over an unsecured wireless connection. Since this link is unencrypted, it is quite possible that an unauthorized intruder may intercept the plain-text transmission and recover both the digital certificate and the public key. That’s OK. In fact, that’s how the entire PKI system works.

The supplicant, after validating the server’s digital certificate, will then encode all subsequent responses to the authenticator using the server certificate’s public key to perform the encryption. The encrypted data is then transmitted back to the AS. This is referred to as tunneling.

Since the public key was used to encrypt the supplicant’s traffic, only the private key can be used to decrypt those messages. Public keys can’t be used to decode messages encrypted with public keys—only the private key. If the intruder tries to intercept and decrypt the encrypted transmissions from the supplicant to the authenticator, the intruder will fail. Therefore, it is safe to send the public key out over an unprotected network since it can only be used to encrypt messages intended for viewing by the holder of the private key. Likewise, the digital certificate verifies the identity of the sender and is meant to be publicly transferred, so it is of little use to an intruder. However, it is important that the private key be safe and secret.

Asymmetric key encryption is a safe and well-supported security platform, but because the computations used during these procedures are somewhat intensive, with standardized WLAN security, asymmetric keys are only used temporarily to establish a symmetric key. Once the entities have been authenticated and keying material has been exchanged, the asymmetric key encryption techniques are suspended in favor of faster, less processor intensive symmetric key cryptography.

For WLANs, the 4-way handshake takes the keying material that was exported from the 802.1X/EAP authentication and creates symmetric encryption keys on both the authenticator and the supplicant used for data communications with CCMP/AES and TKIP/RC4.

Segmentation and Filtering

Most of the security methods we’ve talked about thus far have focused on WLAN-specific security. However, it is important to consider that Wi-Fi traffic is just a part of an entire network ecosystem. Certain rules must apply to WLAN traffic, and for this reason, enterprise networks segment and filter WLAN traffic according to its use within the network. Both segmentation and filtering are interrelated, and the goals are generally the same. That is, by applying specific policies and access privileges to WLAN users and devices, you can limit vulnerabilities from the wireless medium, wireless users, and traffic originating from the wireless network. The reverse of that is also true in order to protect wireless devices from network traffic.

The following sections will address specific types of and best practices for segmentation and filtering.

VLANs

Virtual LANs (VLANs) are a popular wired network segmentation method that allows a single hardware network domain (e.g., a switch or a switch port) to be divided into multiple broadcast domains. More simply, VLANs create Layer 2 segments that operate independently from each other. This allows network administrators to keep broadcast traffic on one network segment from interfering with another. Traffic from different VLANs can flow across the same network medium, but it will be handled differently based on the VLAN to which it belongs. There are many technical documents on the Web discussing VLANs. Aside from this brief introduction, we are assuming that our readers already possess a modest technical understanding of VLANs. Otherwise, this information is sufficient preparation for the CWDP exam.

In wired networking, VLANs serve many purposes, such as:

• Minimizing the size of broadcast domains
• Creating segmented network boundaries for security
• Maximizing the flexibility of existing hardware
• Differentiating the services provided to users via a shared medium

Wireless VLANs are used for many of the same purposes, and simply extend the VLANs from the wired network into the wireless medium. However, we should point out some VLAN principles that are unique to the wireless network:

Managing Broadcast Domains One of the primary differences between wired and wireless networks is related to broadcast and collision domains. While traffic from different VLANs can traverse the same network medium on the wire, the same holds true for the wireless medium. The major difference is that in the wired domain the switch is able to selectively forward broadcast traffic to endpoints based on the VLAN assignment of each switch port. In the wireless domain, the AP can do something similar by only forwarding broadcast traffic from applicable BSSIDs, but it is important to differentiate that wireless users share the same collision domain so bandwidth cannot be protected by VLAN segmentation. Also, wireless clients check the BSSID of transmitted broadcast traffic to see if they should process those frames, though this is only effective if there is a one-to-one relationship with BSS and VLAN, which is not always the case.

An important note to consider is that just as multiple VLANs may share a common network medium like a trunk link from one switch to another on the wire, all of the VLANs sharing that link will impact performance of other VLANs. In other words, the medium has a certain, limited capacity and is shared among the VLANs. Broadcast traffic for one VLAN, while destined only for members of that one VLAN (and possibly SSID), will still impact wireless performance equally for all wireless clients.

Maximizing the Usefulness of a Single Infrastructure The use of VLANs in wireless networking does allow for some helpful capabilities within the wireless domain. For example, VLANs provide a way for the users of the wireless domain to be divided into different virtual domains on the wired network. Since the wireless network is shared and APs can’t isolate RF transmissions for a specific VLAN, the AP or WLAN controller acts as the VLAN traffic cop and will translate a VLAN assignment so that a client device’s traffic is placed in the appropriate VLAN on the wired network.

In other words, a single wireless radio can advertise and provide services for multiple WLANs simultaneously by monitoring the traffic. As with Ethernet switching equipment, the use of VLANs with WLAN infrastructure devices greatly increases its flexibility and usefulness in the enterprise.

Limiting Services and Creating Layer 3 Boundaries In the enterprise, each wired network VLAN will provide certain resources, such as Internet access, printers, and databases, in accordance with ACLs and other filtering that may be placed with the network serving those VLANs. With WLANs, segmentation is often provided by mapping VLANs directly to an SSID. When the wireless client successfully associates to that SSID, they inherently become part of the VLAN. For greater flexibility, VLANs can be assigned to users or groups dynamically via RADIUS attributes or WLAN user/group policies.

VLAN Encapsulation

Although there are still examples of earlier, proprietary, VLAN encapsulation protocols in use (e.g., Cisco Inter Switch Link [ISL]), most current VLANs make use of IEEE 802.1Q encapsulation. 802.1Q inserts a 32-bit VLAN tag, of which 12 bits are used as the VLAN ID, on the Ethernet header to map individual VLANs to and from the wired side of the network. The VLAN tag identifies the Ethernet frame’s VLAN membership to the switch, which then sorts it onto the correct VLAN. Once a frame arrives at its destination or is directed to a nontrunked port, the VLAN tag is stripped away from the Ethernet header.

Wireless VLANs in Practice

By using 802.1Q tagging, we can construct logical segmentation in our wireless network to provide discriminating services to wireless users (again, this does not segment contention in the wireless domain). In the enterprise, most VLAN rules will already be provided by virtue of an existing Ethernet infrastructure. Many wireless users will already have specific network privileges based on their role in the company. In these cases, the WLAN must make sure that users are provided with correct VLAN assignments and filtered onto the wired network accordingly.

To be clear, VLANs are not normally transmitted as a part of 802.11 frames. Instead, the WLAN infrastructure is responsible for determining the VLAN to which a specific user’s data applies and keep them there. Once the WLAN places the wireless traffic onto the wired medium with appropriate VLAN tags, existing wired policies will take care of the rest.

It is quite possible to restrict network access to certain locations by removing support for certain SSIDs/VLANs from certain APs. For example, if a public access SSID/VLAN is offered to guests for simple Internet access, it is fairly easy to remove this SSID from APs outside of the desired service area. Perhaps you only want to serve guests in a lobby or conference areas, but not in areas where you don’t expect guests to be. The benefit is that all of this can be done without having to add additional hardware to the network. In some ways, this is more a function of SSID broadcasting, but it is a way of segmenting service.

When designing a network for VLANs, it is important to consider the network architecture and forwarding model as well as whether the Ethernet access layer switch to which an AP is attached is a trunked port or an access port. With these considerations in mind, the following section discusses VLAN design principles for different data forwarding architectures.

Centralized Forwarding

When WLAN controller-based architectures are used with centralized forwarding, the AP may be connected via an Ethernet access or trunked port, and the WLAN controller is always connected via trunked ports.

When an AP processes a data frame destined to the wired network, the actual 802.11 frame is encapsulated inside an IP packet (assuming L3 connectivity between the AP and WLAN controller) and transmitted on the wire to the WLAN controller; thus, the original frame is preserved between the AP and the WLAN controller.

When the WLAN controller receives the packet and views the original 802.11 frame to determine how to process it, the VLAN assignment is made, and the outgoing frame (from the WLAN controller) is tagged appropriately for wired network transport.

This is fairly standard, assuming the WLAN controller is trunked. If the WLAN controller is not trunked, all traffic will be placed on the default VLAN of the access port and all traffic must be assigned to the same VLAN.

Distributed Forwarding

When distributed forwarding is implemented in any WLAN architecture, it is important that the switch ports to which APs are connected are trunked with support for all VLANs necessary for the clients associated to that AP. If the switch port to which the AP is connected isn’t trunked, the AP will not be able to deliver traffic to the appropriate destination for multiple VLANs—unless a tunneling protocol is used on a VLAN that is shared by the two APs. Access switch ports will limit the AP to the single default VLAN that is provided by that switch. In other words, distributed forwarding may demand that access layer switches support trunk ports to APs. This is sometimes necessary to support QoS requirements at the edge anyway, but current infrastructure configurations may not support it. This will add some configuration steps, and possibly a re-architecting of the switching infrastructure.

Role-Based Access Control

In enterprise networks, authorization to network resources is typically controlled on a per-user or per-group basis by assigning permissions (security policies composed of access rules) to user or group entities. As we discussed earlier, this functionality is provided by means of user-based 802.1X/EAP authentication (or PPSKs), and typically, RADIUS return attributes. It is fairly common for the WLAN infrastructure to maintain group, or role, permissions and rules. This allows the WLAN infrastructure to receive a group assignment for a user from RADIUS and then apply policies and filters accordingly.

When the WLAN infrastructure has limited support for user or group access policies, filtering is usually provided by a combination of WLAN profile parameters, RADIUS return attributes, VLANs, and authorization applied by the wired infrastructure.

In any case, role-based access control (RBAC) follows a basic logical flow:

• You create users with specific parameters.
• Users are assigned to groups that contain certain parameters.
• Security policies (VLANs, ACLs, time restrictions, etc.) are applied to groups.

In this way, users inherit policies by virtue of being a member of a certain group. When maximum granularity is desired, policies can be applied directly to users, though this is often unnecessary and creates significantly more management overhead.

Wireless Firewalls

While the use of VLANs allows us to control the subnet on which the WLAN is accessed, they cannot control the types of traffic that are allowed on the network. To do that, firewall rules are used and are assigned along with other permissions in the 802.1X authorization process. Firewalls filter traffic based on policies composed of rules. Simple firewall rules consist of a few basic elements:

Source The origin of the traffic determined by an IP address or MAC address

Destination The delivery point of the traffic determined by an IP address or MAC address

Service The type of traffic, determined by TCP or UDP protocols and port assignment, or by application-layer protocols or behaviors

Action Reject, Drop, or Permit

The combination of source, destination, and service determine which action is to be taken. For a secure approach to policy design, any services that do not have a specific reason to be used should be blocked. This can be done easily by following the same element order above (source – destination – service – action): a single “any – any – any – drop” rule located as the final rule in the policy list. This rule means that by default, the firewall will drop all packets from any source to any destination. Since firewalls read and act upon rules in top-to-bottom order, this rule must be placed as the last one in the list. After this default rule has been inserted, you can define additional rules inserted above the “drop all” rule to specifically allow the types of traffic that are to be allowed.

Additionally, some WLAN infrastructure vendors offer application-layer firewalls. These firewalls tend to require significantly more processing cycles, but they also add another element of security for network protection.

Captive Portals

Open authentication is very common with guest networks. However, most WLAN hosts do not want to simply open up their network to any user that may want to use it. The primary way to control access to the wireless network in this case is to provide a captive web portal that requires users to first identify themselves with preassigned credentials, by filling out a form or simply accepting a usage agreement before assigning them to a user/group profile and granting them network access. The captive portal acts as a containment area for unregistered users while granting registered users varying levels of network privileges. In this way, anonymous users can be allowed network access on demand without the need for a network administrator to become involved.

Guest access was discussed in Chapter 3, “Designing for Applications,” where the concept of a captive web portal was introduced. However, in this case the base technology of a captive portal is leveraged for a larger context, as mentioned earlier.

To configure a captive web portal, a VLAN with limited privileges such as Internet-only access is created and assigned to a unique SSID such as “Guest.” As users attempt to join the network, they follow a number of typical steps, as follows:

The registration process can be used to force a user to perform a complete registration, including a requirement of personal identification or financial information. In addition, you may enforce a requirement for end users to accept a network use policy before being allowed on the network. This can be a good choice if it is not known who will be using the WLAN. An appropriately designed acceptable use policy may also limit your liability as the network service provider. For known users, a simpler authentication screening may require only a username and password to gain access through the captive portal. Another option might be to only require acceptance of the network use policy before proceeding to full access privileges.

From a security viewpoint it should be remembered that the gathering of personal or financial information over an unsecured web interface (HTTP) can be vulnerable to eavesdropping by unauthorized intruders. Only a protocol analyzer is needed to capture and view the unprotected user information unless a secure web connection (HTTPS) has been provided.

Similarly, most captive portals by themselves are only for basic authentication. They do not provide encryption and should be used cautiously. In most cases, captive portals are employed for public access networks and hotspots. Vendor implementations are fairly divergent, and your specific use will dictate how to configure the captive portal features, such as user screening and authentication requirements, security roles, firewall rules, bandwidth limits, usage limits, billing information, and activity logging.

Endpoint Security

Thus far, we’ve looked predominantly at infrastructure-side security. While client feature support is important when planning infrastructure features, there are several client-specific security requirements. These are just as important as infrastructure security. Here’s a list of some common client-side security considerations to make before putting your devices on a wireless network:

Personal Firewalls It almost seems silly to mention personal firewalls as a client security mechanism. Most client operating systems have personal firewalls enabled by default, and when they’re not enabled, the OS persistently nags you about it. This is a good thing for end users who accidentally turn their firewall off. Firewalls are especially important when users are on unsecured public networks, which are networking environments that represent low-hanging fruit for potential attackers. It’s simple really. Unless an application needs permission through the firewall, the personal firewall should block inbound traffic. Firewalls should be updated as new OS patches and updates are made available. Firewalls should always be on.

Antivirus Software Similar to personal firewalls, the need for antivirus software is pretty much ubiquitously understood in today’s IT landscape. Except with home users and small offices, most companies maintain security policies for antivirus use and updates. Again, it’s simple. Update antivirus software with the latest threat signatures as often as possible. This is especially important when using public access networks where the infrastructure security solution—or lack thereof—provides little protection against probing attackers.

Endpoint Agents If, like most companies, you don’t trust your end users to always know and uphold wireless security policies with their computer, endpoint agents can be invaluable. The purpose of an endpoint agent is to monitor and manage client network connectivity and ensure that the conditions for WLAN connectivity meet the defined policy requirements. Endpoint agent software is installed on the client device and IT staff configures the wireless connectivity policy that should be maintained.

As an example, imagine that your network policy forbids the end user from connecting to networks that are unencrypted. Or perhaps you want to restrict the device even further by allowing only corporate SSIDs. If the user takes the laptop home, perhaps they have a remote AP that broadcasts the corporate SSID and tunnels the traffic back to the company via a VPN. This is all well and good. But let’s say the user violates company policy (due to ignorance or disobedience to a known policy) and goes to the local coffee shop and attempts to check their email there. If configured correctly, the endpoint agent will prevent the client supplicant from connecting. In cases where administrative rights are granted to end users, endpoint agents can add a layer of protection by simply restricting the networks to which users can connect.

VPN Software One of the most common IT challenges for companies with traveling users is enforcing the use of VPNs. Because VPN technology may be confusing and cumbersome for typical end users, there must be a policy that enforces their use. For traveling users, connectivity to a corporate network resource should be done through a secure VPN, such as one created using IPSec tunneling. In deployments requiring maximum security for traveling users at unencrypted networks, VPNs that tunnel to the corporate network and then back out to the Internet may be the only way to provide secure services.

Depending on the assets stored on traveling users’ computers and the security staff’s tolerance for risk, split tunneling may be used to provide access to corporate resources while preventing unnecessary traffic bottlenecks at the VPN concentrator. Many companies disallow split tunneling because the secondary network can become an attack vector or entry point to gain access down the established tunnel of the client device.

Network Access Control (NAC) In addition to all of the policies we’ve discussed so far, network access control (NAC) can be a great way to maintain client security posture. In fact, that is its purpose. NAC solutions are designed so that after a client authenticates to the network, the client must be screened to ensure compliance to a minimum set of security or even software patch-level requirements. A NAC server queries and isolates the end user device (facilitated by a client NAC application) to ensure that it is compliant with the company IT policies, which usually includes up-to-date antivirus software, enabled personal firewall, operating system patches, and other similar security checks. If a device connects that is not compliant with the NAC’s policy, devices can be quarantined for a short period of time with limited access so they can complete the requisite upgrades or configuration changes to conform to policy. NAC ensures that client devices are consistently maintaining the appropriate security posture. NAC implementations have not really received standardization within the industry, but as a general concept, NAC can be a helpful way of enforcing yet another layer of security for client access.

NAC has traditionally fallen short when it comes to application-specific devices with proprietary or closed operating systems. If a NAC agent cannot run on a host device, it cannot determine these critical factors for network admission. Administrators typically opt to have devices such as these placed on a separate, locked-down VLAN only for these devices. Therefore, if a virus outbreak or other compromising event occurred with these devices, the impact would be minimal.

The challenge is determining which VLAN to place them in if there are multiple device classes. Determination might be required to be based on the MAC address of the client radio (or Ethernet port if NAC is used on wired devices). Some forms of NAC might even base a policy decision on the MAC address of the client and then wait for certain types of network activity in order to make a VLAN assignment decision.

When devices simply do not comply, they are typically placed on a quarantined VLAN where their network communication might be suppressed until the required remediation activity occurs.

OS Permissions Control One of the best ways to enforce security policy on client devices is via OS user account control. When a company standardizes with specific client devices or client device operating systems, it is fairly common to deploy computers with limited user account permissions. By doing so, you can effectively prevent the end user from making changes that will create security vulnerabilities. This often includes restrictions in the ability to install software. Malicious software that is installed on one computer can quickly make its way throughout a network, especially if it is installed on the computer of a user with high levels of authorization to other machines or file shares.

Some OS permission control can prevent users from changing wireless network supplicant settings. Usually this is only made possible using the built-in wireless utility/supplicant included with the operating system. This feature restricts users from inadvertently disabling security features and also allows administrators to enforce consistency across the entire network.

Virtual Private Networking

The use of virtual private networking (VPN) protocols in a wireless network was once a very popular security tactic. This was mostly due to the inadequacies of the legacy 802.11 security methods such as WEP. Today, it is still possible to use VPN applications for WLAN security, but it is not a common practice and is typically not an ideal implementation.

In most modern networks, VPNs may be useful to wireless networking for a handful of reasons, including:

• Remote APs that tunnel to a corporate WLAN controller or other VPN concentrator
• Connectivity of branch offices to corporate datacenters for centralized WLAN management, authentication servers, user databases, or other related services
• AP or other WLAN device connectivity to cloud-based management solutions
• Secure client connectivity to corporate resources across unsecured networks, often provided via public access Wi-Fi hotspots
• Proprietary point-to-point or point-to-multipoint bridging

For any of these uses, a few salient considerations should be made. Of course, the VPN protocol should be evaluated for proper security. Of the commonly used protocols, IPSec is highly secure and is well supported in most environments. SSL-based VPNs have taken over a lot of IPSec’s domain and are also a commonly used method for VPN. On the other hand, PPTP is widely supported but is subject to brute-force dictionary attacks.

In addition to security strength, VPNs should be evaluated for performance-related criteria. Some VPNs introduce a fair amount of cryptographic processing overhead, which can decrease throughput and increase latency, both of which may cause a noticeable impact on the application. Further, VPNs should be evaluated for ease of use, support within the industry (especially if clients must support a specific protocol or implementation), compatibility with existing hardware/software, and cost.

WIDS/WIPS

By virtue of the “visible to all” nature of the wireless medium, even the most secure WLAN deployments may need an additional layer of protection in the form of wireless monitoring and intrusion protection. Wireless intrusion detection systems (WIDSs) and wireless intrusion prevention systems (WIPSs) are gaining in popularity and are intended to provide that extra layer of protection for monitoring the airwaves against network threats.

The typical architecture of a WIPS implementation includes a WIPS server, WIPS sensors, and a WIPS management console. WIPS sensors are deployed much like access points (though not as densely) and are the wireless data collection points. The sensors scan the air and gather the data, then forward the collected data to the WIPS server for aggregation. The WIPS server utilizes the network-wide data and compiles it for monitoring, auditing, and forensics. A WIPS management console is then used to retrieve the data from the WIPS server, usually via a graphical interface with a web browser.

There are several functions of a WIPS, including:

• Identification, classification, and prevention of WLAN security threats
• Security posture evaluation, auditing, and reporting
• Regulatory compliance auditing and reporting
• Performance monitoring, assessment, and reporting
• Network configuration continuity monitoring
• Forensic data analysis
• Distributed protocol analysis
• Distributed spectrum analysis
• Rogue device location services

This is a somewhat high-level list, but it should serve to demonstrate that a WIPS is designed to monitor the air for any network events that could adversely impact the WLAN. Monitoring is not relegated to security; it includes performance, regulatory compliance, location-based services, and more.

Many WIDS/WIPS products have troubleshooting features that also double as protocol analyzers that can cost-effectively assist IT support desks, especially in remote locations.

The first step in designing a WIPS deployment is to identify the goals of the WIPS. You may want casual monitoring to identify rogue APs and to attempt to identify other network attacks. Or you may want some basic security audits to ensure that your network complies with regulatory requirements, such as PCI-DSS v2.0. More secure network environments may want full-time monitoring and threat prevention, rogue device triangulation, and daily, customized vulnerability reports. Each of these three use cases represents a different approach to WIPS deployment. For that reason, it is difficult to prescribe all the ins and outs of how to deploy a WIPS. There are many consistencies that we can explore to help provide the big picture regarding how to deploy a system in your environment. First, let’s look at the basic differences in WIPSs.

Integrated vs. Overlay

There are two primary ways to deploy a WIPS:

Integrated In integrated systems, the WIPS functionality is integrated with the hardware of the access points.

Overlay With overlay systems, dedicated WIPS sensors are overlaid onto the existing WLAN infrastructure.

Many WLAN vendors are now integrating WIPS functionality into the AP, so it is becoming a common practice to deploy additional APs in a sensor-only mode for scanning. Third-party vendors also make dedicated overlay sensors that can perform the same functionality.

When comparing a third-party solution to an integrated option, one significant difference is the purpose-built nature of third-party overlay systems. Because WIPS vendors specialize exclusively in intrusion prevention and security threats, they are usually at the forefront in terms of in-depth wireless intrusion detection, automated intruder mitigation, threat assessment, and auditing/reporting functions related to legislated compliance.

On the other hand, integrated WIPS functionality (even when deployed as dedicated sensors) is handy because these sensors integrate with the existing WLAN management hardware—as a caveat, some WLAN infrastructure vendors may require additional hardware or feature licenses for WIPS services. Overlay systems require additional hardware and added learning curves that typically come along with new vendor solutions. This comparison comes down to the customer’s needs and the functionality offered by third-party WIPS products as compared with the WLAN infrastructure’s offering.

Dedicated vs. Part-time

With integrated WIPS sensors, there are two basic operating modes:

Dedicated Dedicated WIPS sensors are full-time radios dedicated exclusively to WIPS functionality.

Part-time Part-time scanners are AP radios that also serve clients. At regular intervals, the AP radio will stop serving clients for a short time in order to scan surrounding channels for security threats.

Neither of these options is necessarily right or wrong, but there are obvious trade-offs between the two.

With dedicated radios, the commitment to threat detection is much better. Remember that APs typically transmit beacons every 100 ms, or ten times per second. In order for a WIPS sensor to scan through all 14 of the channels in the 2.4 GHz band (depending on regulatory requirements), dwelling on each channel for at least one beacon interval, it would take over a full second. This assumes that it scans a channel for 100 ms and then hops to the next. Now, add into this equation all twenty-four 20 MHz channels (again, depending on regulatory domain) in 5 GHz, and you’ve exacerbated the problem even more. This doesn’t even consider that you must now also scan 40 MHz channels, at least in 5 GHz. This doubles the list of channels, at a minimum (remember, 40 MHz channels are 20 MHz channels with 20 MHz extension channels above or below). Long story short, there are a lot of channels to scan, and it will take a lot of time.

Dedicated sensors will not be able to catch every frame on every channel, but they will tend to catch a greater percentage of network threats than part-time sensors because they are scanning each channel for longer periods of time, more frequently, or possibly both.

Now, consider that part-time sensors must serve clients on a specific channel, and at regular intervals, scan all of these channels for threats. How long would it take to scan each of these channels in the list, and what is the penalty to WLAN client performance when this happens? In most cases, when latency-sensitive traffic (like VoWiFi) is supported, part-time sensors can’t abandon the client traffic flow to scan off-channel. What if a voice call lasts 20 minutes? That’s 20 minutes of time in which no off-channel scanning is taking place, no rogues are detected, and no threats are intercepted.

As we discuss the efficiency of dedicated versus part-time sensors, we should also discuss what a WIPS sensor does when it discovers a threat. Dedicated sensors can remain on a specific channel, preventing the offending device from exploiting the network (in many cases). Part-time sensors are torn between an obligation to serve clients and an obligation to prevent threats. Client service may take priority here, leaving manual threat mitigation by IT staff as the only option. Alternatively, nearby sensors might also be able to hear the activity and be able to help mitigate the threat.

Configuring Policies

When you are designing and deploying a WIPS solution, the wireless security policy is an important tool. In effect, the WIPS should be configured to maintain compliance to the security policy and attempt to prevent behaviors that interfere with compliance. To that end, configuration of an acceptable wireless policy is typically a first step in preparing a WIPS. This includes parameters such as authentication, encryption, SSID usage, and other related criteria. These criteria are a configuration baseline for the WIPS to enforce.

After WIPS sensors are online and have populated a list of visible APs and clients, administrators will assign classifications to those devices. Usually, there are a handful of device classification categories. Known, unknown, friendly, neighbor, and rogue are all common classifications. This is an important step, especially if automated threat mitigation will be enabled. For example, if you configure the WIPS to automatically contain threats from rogue devices, it is critical to ensure that your “rogue” devices are actually offending rogues. You may inadvertently label your neighbor’s AP as rogue, and your WIPS would proceed to cause a denial of service (DoS) to your neighbor’s network. This represents a legal liability, so great care needs to be taken.

WIPS products generally come preconfigured with numerous alarm and threat signatures that can be used to automatically detect suspicious activities and compare them to a database of attack sequences. When the WIPS finds a match between the detected activities and an attack scenario, it will generate an alarm or other automated response. Once an intrusion has been identified and the threat level determined, the WIPS can trigger notification (e.g., email, SMS, hardcopy reports, or detailed forensics logging) and responses. You may choose to have the WIPS perform automated mitigation on the wireless medium (often called rogue containment), or you may wish to block the wired port to which the rogue device is attached (often called port suppression). Either of these actions can be launched as an automated procedure or can be configured to wait for final approval from an administrator before beginning the mitigation actions.

In addition to alarms, responses, and notifications, WIPS policies are often paired with risk assessments, vulnerability reports, logging, and forensics. Modern WIPS products are becoming more sophisticated, allowing for automation of most of these functions. For example, you can configure the WIPS to generate a monthly report showing all alarm activities as well as a prolific subset of information relevant to each alarm. Similarly, you can configure the WIPS to generate a monthly report showing your network’s compliance with an industry regulatory policy, such as PCI, HIPAA, or other similar requirements. This provides verifiable and traceable evidence in the event that a network audit is performed.

WIPS policy configuration could easily represent an entire chapter in this study guide, but we will defer to the CWSP study guide and WIPS product user guides on this topic. In short, your configuration will depend on the goals you are trying to achieve with the WIPS platform. If you are looking to maximize automated response, even at the risk of false positives, you should set aggressive WIPS policies. However, if you want to prevent all false positives, you may want to use alarm and reporting functions more heavily and rely on manual investigation and verification to contain potential threats.

Advanced Performance Monitoring and Reporting

A WIPS is generally purchased with the intention of providing a perimeter security envelope around the WLAN. But, in addition to providing constant 24x7x365 monitoring of the security metrics of a WLAN, most WIPSs are also able to track key performance indicators, such as misconfiguration, saturated channels, or heavily utilized APs. As with security events, alarms, notifications, and reporting actions, performance criteria can also be acted upon.

As new types of communication services such as voice and video applications grow more popular on the WLAN, additional expectations for quality of service become more common. As this happens, it will become increasingly important for the network administrator to be able to proactively determine when and where service disruptions are occurring in order to correct those problems in advance of a service level agreement (SLA) violation. Full-time monitoring and enforcement of expected service levels is a capability of the WIPS that may prove to be invaluable.

WIPS Sensor Placement

The WIPS system is a critical piece of the WLAN deployment. It provides the final ongoing monitoring and enforcement of perimeter security and performance. For best results, the placement and number of WIPS sensors should be carefully considered during the design phase of the WLAN. Although it may be tempting to “eyeball” the locations and numbers of WIPS sensors, just as with trying to guess the number of APs needed to meet customer expectations this method seldom results in a well-designed sensor network.

All WIPS vendors have recommendations on how to design the sensor network, and this documentation should be consulted for optimum performance. However, in order to determine the optimal placement of sensors in your network design, you should consider the type of monitoring services that will be required and plan accordingly. Beginning with the vendor’s recommended AP-to-sensor ratio, look at some of the selection criteria we have mentioned previously, such as:

• Will you be scanning all channels, or just the primary channels within a band (e.g. 1, 6, 11)?
• Do you intend to provide full-time, automated threat mitigation if the need arises?
• Will you be attempting to locate rogue APs or clients with triangulation, RF fingerprinting, or time difference of arrival (TDoA) techniques?

These services all impact the number and placement of sensors. Specifically, as you desire better scanning coverage, higher resolution in rogue location tracking, or better dedicated threat prevention, more sensors are usually warranted.

To provide the best sensor platform for these additional applications, it is usually necessary to configure the WIPS sensor deployment with greater attention than would be needed for basic security monitoring. Some WIPS vendors also offer a site survey mode in which the sensor begins actively transmitting data, facilitating a manual site survey. With this method, network designers can collect actual data to gauge the sensor’s effective range, which ultimately helps determine proper placement.

Do You Need a WIPS?

There’s no hard and fast rule to indicate whether you should or shouldn’t have a WIPS in place for your wireless network. As with most security-related decisions, this assessment results from a comparison of security importance, cost, and complexity. Generally speaking, WIPS are the only real way to discover some of the potential vulnerabilities in a WLAN. Often times, it is not enough to support robust authentication and encryption mechanisms. You must also monitor the airwaves around you for potential threats.

In fact, some companies for whom a WIPS may be most useful are those companies with a “no Wi-Fi” policy. When network-wide security visibility is important, WIPSs are quite helpful and highly recommended. If your only goal is to identify and manually remove potential rogue APs, part-time WIPSs usually work just fine. If you want the best of the best, dedicated overlay WIPSs add a significant final layer of security to the network. There are many options to meet the various security needs of companies.

Fast Secure Roaming

As we’ve already discussed throughout this chapter, the strongest security solutions may come with trade-offs to cost, ease of use, management overhead, and possibly performance. One of the major performance-related drawbacks that may come along with robust security is high latency during roaming due to long 802.1X/EAP authentications. As you might expect, simple authentication protocols, such as 802.11 authentication (a.k.a. open authentication) and WPA/WPA2-Personal require a minimal number of frame exchanges to complete authentication and begin passing data traffic. More complex and stout authentication mechanisms, such as 802.1X/EAP, require much more time to complete, thus delaying the application’s data flow during this time.

During a reassociation in an open network (no security), roaming times are very short—usually less than 15 ms. This amount of delay will not have a noticeable impact on modern applications. WPA/WPA2-Personal authentication with a PSK or passphrase takes slightly longer than open authentication—usually around 25 ms or less—but this is also a fairly nominal amount of delay. Assuming channel utilization is not causing excessive retransmissions, roaming in open networks or WPA/WPA2-Personal networks will be transparent to the end user.

However, when we compare these simple authentication solutions to 802.1X/EAP authentication, the problem becomes clear. During normal 802.1X/EAP reassociations, assuming no fast secure roaming (FSR) mechanisms are in place, all of the following events are required:

• Open authentication
• 802.11 association
• 802.1X/EAP authentication
• 4-way handshake

With WPA/WPA2-Personal, all of these steps are required except the 802.1X/EAP authentication component. As we think about what is required during an 802.1X/EAP authentication, it is easy to see why this phase of the roaming process becomes problematic. Each EAP implementation varies, but in most cases in the enterprise, there are many reasons for delay at this stage. First, the AP proxies authentication requests to an AAA server. Then the AAA server must query a separate user database for user credentials. This process goes back and forth for the duration of the 802.1X/EAP authentication exchange and can take a significant amount of time with a great deal of frame exchanges to complete. Add to this equation the delay that occurs at each hop in the network from the client to the AP to the AAA server to the user database, then back from the user database to the AAA server, back to the AP, and then back to client. This multihop, multidestination exchange process happens many times during the authentication. Figure 12.7 provides a simplified visual reference for this process. Note that Figure 12.7 shows the simplest arrangement of 802.1X/EAP infrastructure. In real-world deployments, these devices may cross many L2 or L3 hops, including remotely hosted AAA servers or user databases. Also, to demonstrate the amount of frames traversing and processes occurring across the wireless and wired medium at this stage, Figure 12.8 shows only the exchanges that are performed between the supplicant, authenticator, and AS for the most common EAP type, PEAPv0/EAP-MSCHAPv2.

You also need to factor in the amount of time it takes the client to validate a server certificate, the time it takes the AAA server to validate client credentials, and the time it takes the AAA server and client devices to export keys. Then add to this mix 802.11 frame contention on a busy wireless medium, frame retries, and any other variables that create additional delay. Finally, AAA servers and user databases may also be serving other authentication requests at the same time, so an additional delay may occur when the authentication infrastructure is heavily utilized. Needless to say, 802.1X/EAP authentication can take a long time to complete. Depending on the network configuration, this process can take more than a full second to complete for the first authentication—though, in simple networks, it can take less than 150 ms. In an ideal world, reassociations would take approximately 150 ms or less to complete, depending on the EAP type.

Many of today’s applications are highly sensitive to long delays like this. Large amounts of delay can take a noticeable toll on voice, video, and other sensitive session-based applications. In many cases, the application’s session will actually terminate, requiring end user intervention to reinitiate the flow of data. If we apply this information to a real-world scenario, it’s easy to see why this is problematic. Imagine a nurse who is walking through the hospital hallway, being briefed on her way to assist a patient in need. The phone’s supplicant initiates a roam, and the voice call abruptly ends. With this and other frustrating scenarios, it’s important to realize that businesses are increasingly relying on their WLAN for mission-critical business goals. This can be a very painful problem for businesses.

In some cases, the solution to long roaming delays is simply to use less complex authentication mechanisms. This is an example where PPSKs can be very useful. However, there are many times in which 802.1X/EAP is the only acceptable authentication mechanism, and roaming times must be decreased. Enter fast secure roaming.

There are many different types of FSR, including a few proprietary solutions. Unfortunately, FSR has not been perceived as a high priority by some industry organizations or vendors, and protocol development and certification adoption has been slow and sporadically embraced. The two early standardized FSR methods (PMK caching and preauthentication) both have notable limitations. IEEE 802.11r also introduced a complete solution to Fast BSS Transitions (FT), but industry adoption of FT has been delayed because the Wi-Fi Alliance and participating vendors have not prioritized their Voice Enterprise certification program. Other FSR methods like opportunistic key caching (OKC) are available, but OKC is not defined by any central, authoritative standards body, which means that implementations vary from one vendor to the next. In addition, OKC has been limited by slow and inconsistent client vendor adoption.

In short, 802.1X/EAP authentication is robust and is highly recommended, but is not always practical. It is possible to make 802.1X/EAP perform well, but it usually takes tuning client devices and enabling certain features. In Chapter 10, “MAC Layer Design,” we discuss configuration and support for FSR mechanisms in greater detail.

As it pertains to security, it is important to understand that, as of this writing, industry support for FSR is still not terribly mature. The ratification of 802.11r is frankly a game changer and it will soon change. It is coming along, albeit slowly. The best current estimates indicate that the Voice Enterprise certification will be available in mid-2011.

The possibility of performance degradation should be factored into a security design in which robust authentication is desired along with high-performing, session-based, sensitive applications. Testing and tuning your client devices and infrastructure settings will have a significant payoff.

Summary

In this chapter, we looked at several critical components to securing a WLAN in the enterprise. As you explore these various elements of a holistic security posture, it becomes clear that there are many layers to proper security planning.

While we have not covered all the technical nuances and options related to WLAN security, we have discussed many of the most important issues. There are always limitations when a vendor-neutral approach to security planning is taken, but this information will provide the necessary framework for Certified Wireless Design Professionals to pass the exam and to make informed and educated decisions as you evaluate the many security options that are available.

For more detailed information on WLAN security, please refer to the CWSP Certified Wireless Security Professional Official Study Guide: Exam PW0-204.

Exam Essentials

Recommend appropriate authentication solutions and explain design concepts related to their use. Understand the appropriate deployment scenarios and best practices for WPA/WPA2-Personal, WPA/WPA2-Enterprise, captive portal, and proprietary authentication solutions.

Understand the 802.1X and EAP protocols and their use in WLANs. Demonstrate an intimate knowledge of how the 802.1X protocol works, what makes it secure, and how it is used in WLAN security. Understand the common EAP types in use today, their advantages and disadvantages, and best practices for EAP selection and deployment.

Illustrate common deployment and design strategies for AAA and RADIUS servers. Be able to show a thorough understanding of the use of RADIUS in network deployments, including RADIUS deployment models. Understand the components of the AAA framework.

Understand design strategies for integration of client authentication with directory services. Demonstrate how to integrate authentication services with existing user databases for client authentication. Understand common deployment practices and recommended best practices for user databases.

Explain best practice security design concepts for guest and public access Wi-Fi networks. Understand how to deploy a guest network using common features like captive portals, network segmentation, content filtering, and access control.

Describe deployment and design strategies for wireless intrusion prevention systems. Demonstrate the purpose and features of a WIPS and explain proper design techniques for WIPS deployments. Be familiar with WIPS architectures, WIPS selection criteria, and common configuration tasks.

Demonstrate the importance of, and design considerations related to, fast secure roaming. Understand why FSR protocols are necessary and what security factors impact their use.

Identify the role and limitations of client capabilities in security planning. Know how client devices impact and limit security implementations.

Describe the methods of designing a secure network with segmentation and filtering. Understand common segmentation and filtering protocols, approaches, and best practices.

Review Questions

1. What differences exist between VLANs in wireless and wired domains?

A. Wireless VLANs do not always segment traffic into separate broadcast domains on the wireless medium. Wired VLANs do segment broadcast domains on the wired network.

B. Wireless VLANs are not effective for segmenting the available services and network permissions available to clients. Wired VLANs are effective for this purpose.

C. Wireless VLANs are not an effective way to utilize a single set of infrastructure equipment to provide different services to different client groups. Wired VLANs are effective for this purpose.

D. Wireless VLANs are never carried in 802.11 frames that cross the wireless medium. VLAN identifiers are always carried in Ethernet frames to indicate the proper VLAN.

2. You have been asked to select a secure EAP type for your organization’s upcoming WLAN deployment. In addition to a requirement for robust security, you were given three requirements for the EAP type:

• Must support server X.509 certificates
• Must support usernames/passphrases for client authentication
• Must support TLS tunneling

What EAP type could you recommend that would meet these criteria?

A. PEAPv1/EAP-MSCHAPv2

B. PEAPv1/EAP-GTC

C. EAP-LEAP

D. EAP-TLS

E. EAP-TTLS/MSCHAPv2

3. For what purposes are VPNs typically used in modern WLANs? (Choose all that apply.)

A. Remote AP tunneling to a corporate WLAN controller or VPN concentrator

B. Client device connectivity to corporate resources from unsecured public networks

C. Initial 802.11 authentication with the AP and subsequent data encryption

D. Tunneling APs and WLAN controllers to cloud-based management platforms

E. Tunneling APs and WLAN controllers to RADIUS and token servers

F. Bridging client connectivity in ad hoc networks

4. What are some significant drawbacks that are present with WPA/WPA2-Enterprise that are not present with WPA/WPA2-Personal? (Choose all that apply.)

A. WPA/WPA2-Enterprise often requires more administrative overhead for configuration than WPA/WPA2-Personal.

B. WPA/WPA2-Enterprise does not provide a way to perform per-user authorization and access control.

C. WPA/WPA2-Enterprise does not support the use of usernames/passwords for client authentication.

D. WPA/WPA2-Enterprise always requires X.509 certificates for server authentication.

E. WPA/WPA2-Enterprise often requires additional backend infrastructure components that are not required with WPA/WPA2-Personal.

5. What design architectures are commonly available for wireless intrusion prevention systems (WIPSs)? (Choose all that apply.)

A. Dedicated overlay

B. Part-time overlay

C. Dedicated integrated

D. Part-time integrated

6. What WIPS deployment model represents the lowest-cost option with the lowest added security for enterprise networks with an existing WLAN deployment?

A. Dedicated overlay

B. Part-time overlay

C. Dedicated integrated

D. Part-time integrated

7. What are some of the common ways by which WLAN users receive network permissions? (Choose all that apply.)

A. RADIUS return attributes

B. WLAN profile settings

C. WLAN infrastructure group profiles

D. LDAP database WLAN plug-ins

8. What functions may be performed by a WIPS? (Choose all that apply.)

A. Automated threat mitigation

B. Data forensics and analysis

C. Distributed protocol analysis

D. Performance monitoring and response

E. Client access to the distribution system

9. When are self-signed X.509 certificates and an internal PKI generally recommended?

A. When the selected EAP type requires X.509 certificates

B. When the client population on the network is not owned or managed by IT staff

C. When there is a requirement for a large number of X.509 certificates for client devices

D. When e-commerce is an important business function and many X.509 certificates are required for web servers

10. What is another name for an AAA client?

A. Supplicant

B. Network access server (NAS)

C. RADIUS server

D. Authentication server

E. User database

11. What are the two ports specified by 802.1X-2004 port-based access control? (Choose all that apply.)

A. Supplicant port

B. Controlled port

C. Uncontrolled port

D. Authenticator port

E. RADIUS port

F. LDAP port

12. What statements are true of PEAPv0/EAP-MSCHAPv2? (Choose all that apply.)

A. Allows X.509 client certificates

B. Is widely supported by client supplicants

C. Has relatively high management overhead compared with other EAP types

D. Has a tunneled and an untunneled mode

E. Protects the supplicants actual username inside a TLS tunnel

F. Specifies three EAP phases: Phase 1, Phase 2, and Phase 3

13. In a network supporting WPA/WPA2-Enterprise, what authentication protocol is used for communication between the supplicant and authenticator?

A. EAP

B. LDAP

C. RADIUS

D. 802.1X

14. In an RSN requiring low-latency reassociations and no fast secure roaming protocols, what security solutions are ideal for protecting VoWiFi communication? (Choose all that apply.)

A. WPA2-Personal

B. WEP

C. 802.1X/EAP

D. WPA2-Enterprise

E. WPA-Personal

15. What is the purpose of role-based access control?

A. To control network permissions by managing multiple WLAN profiles (SSIDs)

B. To ensure that all users within a WLAN have equal authorization privileges

C. To offload traffic from RADIUS servers and user databases by incorporating user and group policies within the AP

D. To provide unique network access privileges to users in accordance with group or policy assignments

16. Why is RADIUS ubiquitously used as an AAA server for WLANs? (Choose all that apply.)

A. It is a flexible protocol that can serve many purposes.

B. It is pervasively supported by user databases and AAA clients.

C. Native RADIUS services are always provided within WLAN infrastructure devices.

D. RADIUS adds encryption strength to the 802.1X/EAP protocol.

17. What solutions are important endpoint security practices to maintain a wireless security policy? (Choose all that apply.)

A. Endpoint software agents

B. Network admission control

C. Virtual private networking

D. PMK caching

E. Captive portals

F. Walled gardens

18. What term refers to a RADIUS attribute that is specified by a specific vendor for the vendor’s own use?

A. Vendor-specific attributes (VSA)

B. Virtual RADIUS attributes

C. Proprietary return attributes

D. Vendor attribute-value pairs (AVPs)

19. What is a primary difference between VLANs used on the wireless and wired domains?

A. VLANs on the wired network segment users into different IP subnets, whereas VLANs on the wireless network do not.

B. VLANs on the wired network allow IP-level ACLs to be applied to data traffic, but VLANs on the wireless network do not.

C. VLANs in the wired domain segment collision domains and broadcast traffic, but VLANs in the wireless domain do not segment collision domains and broadcast traffic.

D. VLANs are an effective way to provide secure network segmentation in the wired domain, but VLANs do not provide secure segmentation in the wireless domain.

20. What is the highest amount of delay that is typically acceptable for a roaming event in an 802.1X/EAP network supporting VoWiFi?

A. 15 ms

B. 50 ms

C. 150 ms

D. 500 ms

E. 1 second

Answers to Review Questions

1. A. VLANs have many similarities and differences on wireless and wired domains. The primary difference is that VLANs do not always segment broadcast traffic into different contention domains on the wireless medium. All devices on all VLANs (for a given AP radio) share the same contention domain.

2. E. Of the five EAP types listed, only EAP-TTLS/MSCHAPv2 would meet the criteria provided. PEAPv0/EAP-MSCHAPv2 would be a common EAP type to use in this scenario, but the answer options didn’t include this EAP type. PEAPv1 always uses EAP-GTC, which employs token cards for client authentication. EAP-LEAP has known security weaknesses and is not recommended for modern networks, and EAP-TLS requires X.509 certificates for the server and clients.

3. A, B, D. VPNs are used for many purposes in modern WLANs. Tunneling remote APs back to a corporate VPN concentrator is becoming more common as workforces become more mobile. Similarly, end users are taking advantage of working in remote locations and often require secure VPN technologies to access corporate resources across unsecure connections. In some cases, VPNs are also used to tunnel APs or WLAN controllers to cloud-based management appliances. In the past, VPNs were used as the primary authentication and encryption mechanism for WLANs, but with modern security, this is no longer required or recommended.

4. A, E. WPA/WPA2-Enterprise is generally the recommended solution for client authentication in enterprise WLANs. However, this does not mean that WPA/WPA2-Enterprise is not without its drawbacks. Added security with WPA/WPA2-Enterprise usually comes with the compromise of added management overhead and configuration complexity. It also typically costs more to implement and requires additional backend infrastructure components, such as an AAA server and user database.

5. A, C, D. There are two primary architectures for WIPS deployments: overlay and integrated. With overlay deployments, WIPS sensors are always dedicated to full-time scanning and are not deployed as part-time scanners. With integrated WIPS deployments, the sensor radio can be deployed as a dedicated, full-time sensor or a part-time sensor.

6. D. Part-time integrated WIPS deployments take advantage of WIPS functionality built into an existing WLAN architecture. WLAN radios are configured as part-time scanners, which means they serve clients on a channel part of the time and they scan off-channel part of the time. Because the radio has two distinct responsibilities, the security benefits are limited. However, this represents a low-cost option if the currently deployed WLAN infrastructure supports integrated WIPS functionality.

7. A, B, C. There are several ways to apply network permissions to WLAN users. In most cases, enterprises use a combination of WLAN profile settings and user database parameters that are specified during 802.1X/EAP authentication. Also, many WLAN infrastructure vendors provide local user groups with specific network privileges. LDAP databases are often queried during authentication, but they do not use WLAN plug-ins.

8. A, B, C, D. WIPSs serve many different purposes, mostly related to security and performance monitoring and response. While they may be configured to actively transmit to mitigate a wireless threat or for site surveying processes, they do not service client access to the network.

9. C. For most EAP types where the server requires X.509 certificates but the client does not, third-party certificate authorities are generally very useful. This offloads some complexity, infrastructure equipment, and management overhead from the company implementing EAP. With some of the most secure EAP types, such as EAP-TLS, clients also require certificates. For these EAP solutions, a PKI and self-signed certificates are required. In these cases, certificates must be installed on each individual client device, so it is preferable that the IT staff have control of client devices. In other words, this type of solution would not be good for a university with student-owned and controlled laptops.

10. B. In the 802.1X/EAP authentication framework, there are many different terms used to reference the same entities. RADIUS is a form of AAA, so a RADIUS server and an AAA server are the same thing. Within the AAA framework, an AAA client is often referred to as a network access server (NAS) since it is providing access to a network service that requires authentication.

11. B, C. The 802.1X-2004 standard specifies three roles for authentication: supplicant (the client), authenticator (the AP or WLAN controller), and the authentication server (usually a RADIUS server). The authenticator controls the flow of authenticated and unauthenticated traffic by means of controlled and uncontrolled ports. The uncontrolled port is blocked until the client successfully authenticates using the controlled port.

12. B, E. PEAPv0/EAP-MSCHAPv2 is the most common EAP type in use today because it has many strengths and very few, if any, weaknesses. PEAPv0/EAP-MSCHAPv2 is widely supported by client supplicants, requires server certificates, uses client username/password credentials, is relatively easy to implement, requires TLS tunneling, protects the supplicant’s actual username inside the TLS tunnel, and has two phases.

13. A. When WPA/WPA2-Enterprise is the chosen security solution, the EAP protocol is used between the supplicant and authenticator.

14. A, E. An RSN requires either TKIP or CCMP encryption. For reliably fast reassociations, WPA/WPA2-Personal is generally the best option. WPA/WPA2-Enterprise can also be used to meet the requirements of FSR, given that FSR protocols (like preauthentication, OKC, or proprietary methods) are used.

15. D. Role-based access control (RBAC) is a general concept by which each user receives specific network authorization in accordance with the user’s group or policy assignment. RBAC can be performed in many different ways, such as user/group configurations native to the WLAN infrastructure, RADIUS return attributes, and other methods.

16. A, B. RADIUS is by far the most common AAA protocol in use today. RADIUS is popular because it is ubiquitously supported by user databases and AAA clients and because it is a flexible protocol that can adequately serve the needs of many enterprises. In some cases, WLAN infrastructure devices have native RADIUS services, but this is not necessarily a part of all WLANs. Similarly, the strength of 802.1X/EAP is not dependent on RADIUS and is not innately improved with RADIUS.

17. A, B, C. Endpoint security is an important step in maintaining a corporate security policy. Endpoint security generally includes personal firewalls, antivirus software, endpoint agents, network admission control (NAC), VPN software, and OS permission control.

18. A. In some cases, vendors create their own vendor-specific RADIUS attributes to perform a specific function. These are called vendor-specific attributes (VSAs).

19. C. VLAN operation is largely the same on wired and wireless networks, but the primary difference is that VLANs do not segment the collision and broadcast domain in wireless networks. Broadcast traffic in one VLAN will create contention for all devices in a service area on the wireless network.

20. C. Option D, 150 ms, is typically thought of as the highest amount of acceptable delay for a roaming event in an 802.1X/EAP network. It is not uncommon to see roaming times above 1 second, which will cause noticeable problems for latency-sensitive applications like VoWiFi.