Chapter 11

Basic WLAN Security Design

THE FOLLOWING CWDP EXAM TOPICS ARE COVERED IN THIS CHAPTER:

• Identify weak security solutions and protocols, and provide acceptable alternatives.
• Recommend appropriate authentication solutions and explain design concepts related to their use.
• Recommend appropriate data encryption solutions and explain design concepts related to their use.
• Identify the role and limitations of client capabilities in security planning.

Wi-Fi networks are becoming increasingly important to a broad range of users. For home users and the smallest companies who want simple Internet access to the largest corporations and governments with stringent network demands, every wireless network requires some level of security. Yet the impressive growth of the Wi-Fi industry and the amazing demand for mobile technologies have been consistently met with a barrage of bad press and confusing marketing proclaiming that Wi-Fi networks are inherently insecure. This, as you’ll see, can be an unfair assessment. In an exploration of security technologies and best practices for security design, this chapter will introduce some of the basic, common elements of WLAN security that are relevant for networks of all sizes. Along with Chapter 12, “Advanced Enterprise WLAN Security Design,” we will demonstrate that security can be a fun topic, and WLANs can be secure if proper design techniques are followed. Technologies and protocols are in place for end users to establish secure networks, but education is a necessary first step to help drive adoption of these technologies. Many enterprises are deploying more secure WLAN security technologies, but many also remain unaware of the risks of outdated solutions.

In this chapter, we will take a look at some of the best and worst security strategies for WLANs. 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. We will also note the common missteps of many network security designers.

A General Overview of WLAN Security

As a blanket statement, wireless networks of all kinds require security. The tools we use to help protect our networks from intrusion fall under several broad elements. Here are some of the most important elements of network security:

• Authentication, or proof of identity
• Confidentiality, or encryption; also called privacy, ciphering, obfuscation, or cryptography
• Integrity, or protection from tampering
• Authorization, or what a user is allowed to do
• Accounting, or usage tracking
• Availability, or protection from service disruption
• Nonrepudiation, or auditable proof of activity or inactivity

As a quick overview, let’s look at some basic examples of what is at stake with a wireless network:

Data Privacy and Integrity Assurance User data is traversing the wireless medium. If important and private information is being transmitted across the shared wireless medium, the data must be protected in some way by preventing unauthorized eavesdropping and providing assurance of the data’s source. Privacy and data integrity are necessary.

Controlling Access to Network Services Wireless devices connect to a network that provides services and maintains resources. Each network has its own important information, which could include passwords, user databases, sensitive files, trade secrets, services, and devices that are important for network functionality. For this reason, it is important that access to the network and its resources is controlled. These tasks of validating users and assigning permissions are often known as authentication and authorization.

In addition to the valuable resources that are stored within the network, each network is typically a portal to other networks, including the Internet. Even if no services or resources are provided directly by the local network, there may be a liability in providing an open portal for wireless users to perpetrate IT crimes against other networks or users.

Maintaining Service Availability The wireless network exists to provide some business service to its owner. It costs money to operate and usually provides an important business function that keeps the company operational. The cessation of wireless services is never desired, so part of the goal of security is to prevent disruption. This task is often referred to as maintaining availability.

Monitoring and Auditing Even the best security—whether wired or wireless—may be subject to a breach. In the unfortunate event that security is compromised, it is important that the network owner can account for the damages done, identify the perpetrator, and hopefully defend this information legally. These processes are a part of accounting and nonrepudiation.

There are several ways—and reasons—to implement security within an 802.11 WLAN. The strengths and weaknesses of the various 802.11 security methods have received widespread attention in numerous books, articles, and discussions, but for this book we will focus on simplifying the details and providing concise directives that help users make decisions in accordance with best practices. Each network environment is unique, but there are many consistencies within the selection and deployment of security models that, with a little logic, can be applied to the enterprise.

We understand that it is one thing to prescribe the best and most secure security model for all situations, but it is quite another to select a security solution when you have a limited budget, limited staff, specific hardware requirements, inflexible applications and infrastructures, and many other limitations. With those constraints in mind, we will attempt to stay balanced and offer insight for these limitations while promoting the most secure solutions.

Basic WLAN Security

Many sources claim that Wi-Fi networks are inherently insecure. They have a point—sort of. Of course, we all know that the wireless medium is unbounded and can be seen (received) by anyone within listening range with some basic WLAN hardware. Radio waves propagate outside of building walls, which makes the fundamental access principles of Wi-Fi different from wired networks. Five years ago, we don’t think anyone could argue that Wi-Fi was inherently insecure because the security protocols designed to protect the network were weak. However, the demands of secure end-user mobility in the enterprise have reached the ears of standards and interoperability organizations as well as vendors, making current Wi-Fi security very robust. In fact, you could easily argue that many Wi-Fi networks are more secure than wired networks by simple virtue of the fact that the vulnerability of wireless has been highly publicized and network designers have responded by battening down the hatches. In other words, attention en masse has heightened awareness and improved security stances on the WLAN.

Weak legacy security protocols and highly publicized security breaches have also played a big part in the perception that wireless is insecure. Yet these breaches and vulnerabilities largely boil down to design flaws that could have been prevented. So now that you know what not to do, let’s review some basics about 802.11 operations and then discuss legacy security protocols and design philosophies.

Review of 802.11 Association Procedures

Before discussing the actual security mechanisms for WLANs, let’s take a minute to review the fundamental connectivity mechanisms of the 802.11 protocol. The 802.11 connectivity paradigm includes three basic procedures that are part of a wireless connection—properly called association:

Unless additional security procedures such as 802.1X have been enabled, once the client station has achieved an association it can begin to transmit and receive data frames. At this point, the confidentiality and integrity security elements become an important factor. For modern WLAN security solutions, the actual user/device authentication (validating that users are who they say they are) occurs after 802.11 association. In that sense, discovery, 802.11 authentication, and 802.11 association are intended to create an operational framework on which robust security solutions are built.

You can think about these three steps as a means by which a client and AP establish a communication link where an enterprise security authentication (802.1X/EAP) can then take place. Without this step, the mobile device and infrastructure would not be able to communicate authentication information. We will elaborate on this topic as we explore reliable security mechanisms.

Weak Security Methods

Several aspects of the 802.11 protocol are considered legacy from a security design perspective. However, there are various instances when weak security might be acceptable. For instance, you may use open authentication with a guest access network because the priority of simplicity and ease of use outweighs the necessity for security—although usually a web-based captive portal mechanism, segmentation and filtering, and other security fail-safes are also implemented in that scenario. Similarly, some companies still use WEP encryption for legacy VoWiFi phones because the phones are incapable of being upgraded to a better security solution and the data crossing the wireless medium (voice calls) is not thought to need strict protection. In that scenario, the trade-off is financial savings, ease of use, and even fast handoffs in exchange for weak security. Again, layered security like segmentation and filtering would also be used. With these layered mechanisms in place, end users are able to minimize the risk of weak security solutions. The use of legacy security is somewhat common in many network environments because the benefit of simplicity and cost savings seems to outweigh the risks presented by weak security.

As we look at legacy security, let’s start at the beginning with the early years of 802.11. Two basic authentication modes were built into the original 802.11 standard: open authentication (a.k.a. 802.11 authentication) and shared key authentication.

Open Authentication

As we discussed earlier in this chapter, open authentication consists of a simple two-way handshake and is normally successful. It does not actually “authenticate” the user or client device aside from ensuring that the client station has the ability to transmit a properly formed authentication frame. Open authentication, by itself, does not provide any security, and it was not designed to do so. Rather, open authentication was designed as an introductory framework as an alternative to shared key authentication. Now that robust security mechanisms are mature and pervasively supported, open authentication is used in almost every WLAN in existence to provide a gateway for more sophisticated security solutions, such as 802.1X/EAP, which we will discuss in Chapter 12.

Shared Key Authentication

The alternative to open authentication is a primitive authentication mechanism called shared key authentication. The IEEE has officially deprecated this authentication mechanism, and it is not recommend for use. In fact, it is difficult to find support for it in client supplicants anymore, and it is infrequently used in network deployments.

Pursuing RF Obscurity

It is common to see industry articles and press in which the unbounded RF medium is blamed for Wi-Fi’s security woes. As we discussed earlier, an unbounded medium does change the fundamental access principles of the network, but it does not mean that the responsive security solution should be to attempt to hide the network. This is often referred to as security through obscurity. The technique here is essentially to limit the transmit power, choose low-gain and perhaps directional antennas, and strategically place access points so that the RF waves are not transmitted outside the building (to be exact, RF waves will always travel outside the building, but the idea is to minimize the signal strength at the building’s perimeter so that the signals are unusable), and thus, not available to attackers for exploitation.

Some highly secretive and ultra-security-conscious facilities may employ special means of RF protection, such as an EMF (electromagnet field) barrier around the perimeter of a building or room, but this is very rare. In most cases, organizations desiring this much security should not employ Wi-Fi technologies in the first place. For most Wi-Fi networks, controlling the RF medium like this is impractical and ultimately not a good security solution. If you are attempting to provide reliable Wi-Fi connectivity throughout your building, Wi-Fi signals will inevitably “bleed” outside the building. Even if you are able to limit the RF propagation outside your building’s perimeter, potential attackers can use high-gain antennas to amplify their reception. Thus, if you measure low signal amplitude at the building’s edge with standard Wi-Fi client devices with internal antennas, high-gain antennas can still pick them up. Instead of attempting to hide the network, robust security, such as WPA2 with AES-CCMP, should be implemented.

Other than for those few highly secretive deployments, we do not recommend RF obscurity because it is cost prohibitive to do effectively and it does not provide security against inside attacks. In addition to these reasons, better security is available. At the same time, we encourage that RF signal coverage and proper contention planning be the primary determinants of AP location, transmit power settings, and antenna selection.

SSID Hiding

As we mentioned previously, two types of scanning techniques may be used to discover a WLAN. Both of these methods are used by clients to discover basic parameters of the BSS, including the SSID—the network name. The SSID is a requisite parameter that is necessary for a client association to an AP. For this reason, some have surmised that SSID hiding would be a practical method of securing the WLAN. This is another type of security through obscurity, which is a weak solution, but this method may hold slightly more design value than hiding the WLAN via RF control.

For security purposes, SSID hiding may prevent some basic client utilities from discovering the network name. However, any protocol analysis tool can easily identify the SSID by capturing a frame that mandatorily contains the SSID field, such as an association request frame, which is shown in Figure 11.1. The SSID cannot be removed from these frames, which is why SSID hiding has limited effectiveness. For security purposes, hiding the SSID is not recommended.

Despite this fundamental limitation in the effectiveness of SSID hiding as a security mechanism, SSID hiding may be valuable for other purposes. Specifically, it is common for enterprise companies to broadcast multiple SSIDs from each AP. This setup allows differentiated services for each ESS and may be used to segment specific applications, network uses, or security requirements.

For example, one SSID may be for corporate data usage, another SSID may be for VoWiFi, and a third SSID may be for guest users. Of course, you want your guests to be able to identify the network that is designed for them, so you might label it with an SSID like “FreeGuestWiFi.” When guests are visiting your facility and attempting to connect to your guest network, you want them to be able to clearly identify the intended SSID for connection, and you do not want them to attempt to connect to your corporate SSID. You may facilitate this design approach by “hiding” the SSID of your corporate networks so that your guests are not attempting to connect to, and failing authentication on, your corporate network and then contacting your help desk because they cannot connect to the network. Of course, hiding your corporate SSID may provide help desk–related problems for your legitimate corporate users as well, but for those environments where user devices are controlled by the IT department, SSID hiding may be a worthwhile configuration option.

The decision to broadcast the SSID depends entirely on the end users and client devices that are used with the network. If there is a clear administrative and support advantage to hiding the SSID, then by all means, hide it. But remember that for security purposes, this solution is easily defeated.

MAC Filters

Another legacy security mechanism that is still found in the market today is MAC filtering. As with other weak security techniques, MAC filtering was an attempt at security before the IEEE and Wi-Fi Alliance introduced legitimate, robust security protocols to market. We should all remember from our network fundamentals education that each network interface card (NIC) is hard-coded with a supposed-to-be-unique MAC address. The manufacturing and MAC address assignment process is designed to prevent more than one NIC from having the same MAC address. Thus, the uniqueness of a MAC address was supposed to be an opportunity to provide or restrict network access based on this address.

Despite the intention for each device to possess a unique MAC address, there are several utilities and command-line tools that allow users to easily modify the MAC address of a NIC. For wireless networks with MAC filtering, users can simply observe the frames that are successfully transmitted and received on the wireless medium, copy the plain-text MAC address of the legitimate client, and modify their client device with the same MAC address. This is a simple workaround that easily defeats MAC addresses.

So, our instinct would be to prescribe total abandonment of MAC address filtering, right? Well, it’s not quite so cut and dry. On the one hand, MAC filtering is not a robust security solution. Additionally, the administrative overhead of collecting user MAC addresses, maintaining a list of allowed or denied devices, and managing filters—also called whitelists or blacklists—on the infrastructure can be imposing. However, not all networks or client devices are capable of supporting robust security, so MAC filtering can be an alternate plan.

For example, consider the overwhelming task of managing client connectivity at a large university. Students come to school with a large array of Wi-Fi devices, from computers and phones to printers and gaming consoles. Now, for universities that are proactive about protecting student connectivity, 802.1X/EAP with PEAPv0/EAP-MSCHAPv2 is a common user-based authentication mechanism for most student connectivity. Unfortunately, many Wi-Fi devices are not capable of using 802.1X/EAP, and—although rare—some may not even support PSK-based authentication such as WPA-Personal or WPA2-Personal. So, instead of implementing WEP, which requires static keys and adds configuration steps, the networking department at the university will often provide a separate SSID for student connectivity to serve devices with limited security capabilities. Then, they’ll require that students register the MAC address of their device (usually gaming consoles), and a simple MAC filter (along with appropriate segmentation and filtering) will serve as basic network security. It’s a fairly primitive solution, but even a weak MAC filter is better than no security at all. If nothing else, it keeps most illegitimate devices off the network.

To turn this example around, blacklisting certain devices can have its merit. If a WPA-Personal PSK was configured into a VoWiFi handset device, for example, and it was stolen, one method that can provide some value is to blacklist that device. Ideally, this approach is coupled with a monitoring tool that will alert administrators in the event that the device showed up, but you will at least be able to prevent it from joining the network.

In addition to blacklisting or whitelisting for simple access control, MAC filters can be used to assign some basic security policies. MAC addresses for large universities and enterprise organizations are usually stored as a part of a large user database. Upon authentication, the access controller can also use the MAC address to assign basic user privileges. Again, you wouldn’t want to rely on MAC addresses in a user database to provide robust access control for important network resources, but for simple Internet access, rate limiting, or other tasks, it may be useful.

Wired Equivalent Privacy

Wired Equivalent Privacy (WEP) is a legacy encryption protocol that was originally introduced by the IEEE to provide wired-like data privacy against casual eavesdropping on the wireless medium. WEP has been at the forefront of much of the industry discussions about Wi-Fi security, and by now, everyone knows that WEP is a deprecated security protocol. At its inception, WEP was a valuable protocol for data privacy because it is a fairly simple encryption process and does not have much processing overhead. Of course, this simplicity is also an indicator of WEP’s strength. Due to several published weaknesses, WEP is not suitable in the enterprise. Even so, it is still very common to see WEP deployed in homes, small businesses, and, unfortunately, the enterprise.

Due to its relatively low processing overhead, many legacy devices that had minimal processing capabilities were capable of performing the WEP computations. In fact, most 802.11 radio implementations included an on-board chip designed to offload all of WEP’s processing. Because legacy devices were manufactured before AES-CCMP became standardized, this is why these devices cannot be upgraded to support AES.

When the 802.11 designers wanted to move to AES-CCMP, backward compatibility was critically important. This is why TKIP was introduced (as a part of WPA-Personal and WPA-Enterprise) as a temporary cipher protocol that improved upon the weaknesses of WEP. TKIP, in most cases, allowed for legacy devices to be software upgraded because like WEP, TKIP also incorporates the RC4 encryption cipher. TKIP does so in a much more secure manner. Therefore, most legacy WEP-only devices were capable of being upgraded to TKIP with a simple firmware upgrade. Even today, there is a massive difference in the security afforded by TKIP, as compared with WEP.

CWNP’s Certified Wireless Security Professional (CWSP) certification addresses the many weaknesses of WEP in greater detail, but for the purposes of network design and the CWDP exam, it is sufficiently important to understand that WEP is not typically recommended for use in enterprise networks. It still only affords protection against “casual eavesdropping.”

Similar to many passphrase-based security solutions, WEP has the drawback of high management overhead and static keys. When WEP is used, all clients and APs within an ESS share the same static WEP key. If the key is compromised, all data and network access is compromised. If you desire to change the static WEP key, all keys on all devices must be changed. This is a management problem.

As you research WEP implementation options, you will find that there are several variations on WEP, such as WEP-40 (also known as WEP-64), WEP-104 (also known as WEP-128), dynamic WEP, and other proprietary versions. In most cases (such as with WEP-40 and WEP-104), static keys are used as inputs to the RC4 (the encryption algorithm used with WEP) function. However, in some early instances of 802.1X/EAP implementations, dynamic keys that were exported from 802.1X/EAP authentication were used as inputs to the WEP protocol. While dynamically rotating keys may be helpful for minimizing the likelihood of exploitation of WEP, the same weaknesses—short and plain-text IV, weak ICV, etc.—are still found in dynamic WEP. All versions of WEP should be avoided in favor of new, reliable security protocols.

Similar to the qualifications we made with MAC filtering, we would also like to include a few provisions about WEP’s use. Let’s reiterate that we strongly recommend that all efforts be made to avoid using WEP when any amount of wireless security is desired; however, we understand that there are always extenuating circumstances and other technical hurdles that prevent forward progress. In these cases, we concede that WEP is better than no security at all. Some applications may not require data privacy. Similarly, some network segments may not contain any important network resources. In these cases, WEP should only be used as a worst-case scenario, and additional layers of security—such as MAC filtering, ACLs, and VLAN segmentation—for these networks are highly recommended.

EAP-MD5

In Chapter 12, we’ll address Extensible Authentication Protocol (EAP) types in some detail, but we want to briefly mention that EAP-MD5 is one EAP type that certainly falls under the category of legacy security. EAP-MD5 was initially designed for wired networks and to test basic connectivity between the supplicant, authenticator, and authentication server in wireless networks, but EAP-MD5 was never intended as a robust authentication protocol for wireless networks. More pointedly, EAP-MD5 has the following limitations:

• It does not support mutual authentication.
• It does not export dynamic keys.
• Its authentication exchange is subject to dictionary attacks.
• It does not support any modern, secure encryption protocols.

For this reason, we do not recommend the use of EAP-MD5 for wireless networks in any case. What’s more, you will find extremely limited support for EAP-MD5 in most client and infrastructure products.

VPN

While VPN security is not necessarily a legacy security method, it should be noted that many legacy Wi-Fi networks depended on VPN security for data privacy. Generally speaking, VPNs were effective in securing WLANs; however, the IEEE 802.11 specification was never intended to be secured primarily by a VPN. For that reason, VPNs introduced additional network overhead and connectivity requirements that were only tolerable when robust standardized 802.11 security was not available.

In today’s networks, VPNs are useful for remote connectivity across unsecured networks as well as for proprietary solutions, such as bridging. They may also be used as an added layer of security in addition to standardized WPA/WPA2 methods, but this additional layer of security adds overhead and is rarely necessary. In today’s networks, VPNs are rarely used as the exclusive method of Wi-Fi security, and when WPA/WPA2 can be used, VPNs are almost never recommended unless it pertains to the data path the traffic will use, such as on a wired or WAN connection. Even then, those connections are better secured by infrastructure network devices.

Recommendations and Best Practices when Using Legacy Methods

Before we move on and begin discussing robust security mechanisms, it is important that we rehash some of the basics of weak security approaches. Most important, we want to reinforce that legacy security mechanisms are never recommended when better security can be used. When a security solution is suspected of vulnerabilities, seek out a migration path to more secure mechanisms as soon as possible. If your hardware does not currently support acceptable security protocols, check with the hardware manufacturer for firmware or driver upgrades that may provide better security options. Of course, in the best-case scenario, legacy hardware would be replaced with new, better-performing equipment that supports all the best in modern WLAN security. When in doubt, seek input from the equipment manufacturer, and always double-check for Wi-Fi Alliance certifications to ensure that your equipment is certified.

When legacy security solutions must be used, we recommend the use of security layering to maximize protection. For example, if you must use WEP, consider also using MAC filtering and VLAN segmentation along with firewalls. The wireless segment of the network may not necessarily be “secure,” but every additional element of protection may help. In all cases where legacy security is used, it is paramount that appropriate firewalls, ACLs, and segmentation be used to minimize the risk of an unsecured network.

Also, always consider the traffic traversing your wireless network, the devices that are accessible via the wireless network, and the network resources that are behind a poorly secured wireless network. Performing a proper risk assessment, asset inventory, and impact analysis is incredibly important in this phase of a design. This step cannot be understated. Risk assessments, asset inventories, and impact analyses are always important factors in selecting security solutions, but they are especially critical when legacy mechanisms are knowingly used.

WPA-Personal and WPA2-Personal

As the Wi-Fi industry continues to move away from legacy security protocols, it is moving toward Wi-Fi certified security solutions based on 802.11i, such as WPA-Personal and WPA2-Personal. As you likely remember from your CWNA studies, the 802.11i task group (TGi) had two primary purposes:

• Bridge the gap of weak security by addressing the weaknesses of WEP and shared key authentication.
• Introduce a new, more robust security solution that would be future proof for many years to come.

While the Wi-Fi Alliance awaited the 802.11i amendment from the IEEE, the Wi-Fi Alliance released the Wi-Fi Protected Access (WPA) certification as a stop-gap solution to address the weaknesses of WEP with TKIP. This provided a secure alternative to WEP and shared key authentication while the IEEE was completing work on AES-CCMP, which was the foundation for Wi-Fi Protected Access 2 (WPA2).

TGi also defined the idea of a robust security network (RSN) and made allowances for the continued use of pre-802.11i security methods in conjunction with TKIP or AES through the use of a transition security network (TSN). At first, AES-CCMP capable equipment was rare and expensive, but all new Wi-Fi certified equipment is capable of supporting CCMP. In fact, 802.11n requires that AES-CCMP be used for encryption between 802.11n stations in an RSN supporting 802.11n MCS rates, and the Wi-Fi Alliance now mandates that all new devices be WPA2-certified.

Of course, 802.11n devices can still use open or WEP security modes, but in an RSN, AES-CCMP is required. If you find that this is confusing, you are in good company. In fact, 802.11n Draft 2.0 had more strict guidelines on encryption between 802.11n devices. Since many of today’s products were released when Draft 2.0 was the latest version of 802.11n, you will find that some 802.11n devices will not support 802.11n MCS rates unless AES-CCMP is used. In other words, if you attempt to use open authentication or WEP the AP will default to only 802.11a/g data rates. This is a significant, though common, software problem that should have been updated with the final release of 802.11n. Check your vendor’s implementation to be sure.

As security certifications, WPA-Personal and WPA2-Personal include both authentication and encryption requirements. The authentication portion of WPA-Personal and WPA2-Personal operates exactly the same way. However, the encryption specifications differ.

PSK Authentication

The authentication portion of WPA-Personal and WPA2-Personal relies on a preshared key (PSK) or passphrase that is entered on both the client and infrastructure devices. After the 802.11 association that we discussed earlier, the PSK is converted into a PMK, which is used as an input to the encryption key generation process during the four-way handshake. We will not go into details about the four-way handshake (for more information on these details, see CWSP Certified Wireless Security Professional Official Study Guide by Coleman et al., published 2010 by Sybex), but you should know that this four-frame exchange verifies mutual possession of the shared key. There are several important design elements to consider as a part of WPA/WPA2-Personal security implementation. First among these considerations is a determination of proper use cases for PSK-based security. WPA/WPA2-Personal can be a secure solution, but it is not well suited to all network needs. Along these lines, we will also discuss some of the benefits and limitations of an ESS-wide static PSK. Also, selection, management, and secrecy of the PSK are important factors to consider.

Ideal Use Cases

There are several network uses and benefits for WPA/WPA2-Personal, and we will discuss them here.

Simplicity in Small Offices One of the great benefits of WPA/WPA2-Personal is that it is simple. You select a passphrase, enter it on your infrastructure, and enter it on your client. That’s it. This makes the solution great for home networks or small companies in which a single passphrase and network access mechanism is required. Everyone shares the simple passphrase, everyone respects the privacy of the network, and everyone is happy with relatively simple, though effective, security.

Clients Lacking 802.1X/EAP Support There are many devices that still do not support 802.1X/EAP. Many new consumer devices are being built with Wi-Fi enabled radios, and some of these devices, like printers, smart phones, gaming consoles, and more, do not yet support 802.1X/EAP. For these device types, WPA/WPA2-Personal is the next best thing.

In addition, many legacy devices are not capable of supporting 802.1X/EAP, but many of them can support WPA-Personal with TKIP. This paves the way for short-term security until these devices can be upgraded or a new solution can be implemented. Either way, the enterprise is often handcuffed to PSK-based security due to the requirements of legacy hardware, although many of these legacy devices are being phased out of the enterprise.

Centrally Provisioned Client Devices Some enterprise devices support 802.1X/EAP but are still provisioned centrally in a way that favors PSK. For example, Vocera voice badges are configured with SSID and security parameters by means of a centralized provisioning utility. When deploying the network, you configure the badge configuration utility (BCU) with a single PSK once, and you don’t have to worry about it again. All devices share the same PSK, but end users can’t recover the PSK (because they can’t access that part of the device’s configuration), and a single network profile can be applied to all phones within the network. It’s secure, simple, and effective for that purpose. Vocera does support 802.1X, but all voice badges share a user profile for 802.1X/EAP, which minimizes some of the security advantages provided by 802.1X.

Application Performance Requirements Some other situations that may call for WPA/WPA2-Personal include support for devices (like voice phones) with sensitive applications that require low-latency roaming times. The short authentication exchange used with WPA/WPA2-Personal is usually more than adequate to maintain sessions for sensitive applications while roaming from one AP to another. In cases where adequate fast secure roaming (FSR) features are not available with 802.1X/EAP, a PSK-based security method may be the only option to maintain acceptable application performance along with security. This is common for handheld barcode scanners, VoWiFi phones, mobile client-server applications (as with electronic medical records on tablet computers), and other applications.

Limitations

WPA/WPA2-Personal also has some limitations in many applications. For starters, standardized WPA/WPA2-Personal uses an ESS-wide security parameter, meaning that every user shares the same passphrase. If any end users are aware of the passphrase, you must trust that they will not share this access credential with users who are not supposed to have it. Further, by sharing a passphrase across an entire ESS, it becomes more difficult to provide user-level or group-level access control, authorization, and accounting. Each user authenticates with the same password (no username); thus, it is more difficult for the system to assign custom privileges to each user.

Similarly, WPA/WPA2-Personal may introduce a moderate, if not excessive, amount of management overhead for IT staff. If end users are not trusted with the passphrase, then IT staff must manually configure the passphrase for each client device. Sometimes this is not a problem, but in other cases, the task is overwhelming. This may be a significant limiting factor when it comes to large-scale networks.

In addition to the management overhead of initial device configuration, the shared PSK poses a risk of requiring network-wide reconfiguration. For example, let’s say that a disgruntled employee who knew the passphrase was fired and vowed harm to the company. What now? Well, you now have to change the passphrase on every device in the network. Several months later you then find out that a member of the IT staff leaked this information to a user who was not supposed to know the passphrase. What now? Well, you change the passphrase on every device in the network again.

It is also generally recommended that static passphrases be changed at consistent intervals (such as biannually or quarterly), which requires device reconfiguration. All of requirements should make it fairly clear that shared passphrases can be problematic.

Finally, as we’ll discuss briefly in the next section, passphrases are not impervious to network attack. For a passphrase to be memorable, it must be short and simple, which means it runs the risk of being too short or simple to stand up to brute-force dictionary attacks. Difficult-to-remember passphrases may mitigate some of the advantages related to the simplicity of WPA/WPA2-Personal networks.

Creating a Passphrase or PSK for WPA/WPA2-Personal

As we previously discussed, there are different ways of implementing the PSK/passphrase. We don’t want to dwell on this topic, but it bears stating that the use of passphrases may introduce security risks. The purpose of a passphrase is almost always ease of use. We want to remember it, right? Unfortunately, the problem is that short, simple passphrases, while tempting to use, are subject to exploitation. While WPA-Personal and WPA2-Personal are generally perceived as modern, reliable security solutions, the authentication process may be subject to brute-force dictionary attacks if the selected passphrase is not long or complex enough.

WPA/WPA2 passphrase policies should dictate that passphrases contain 13 or more (some suggest using no less than 20) characters that incorporate mixed alphanumeric and special characters. The passphrase is case sensitive; thus, a long, complex passphrase such as Je&83Keios)jd23*(& would be acceptably secure in most networks. Of course, most people couldn’t remember that passphrase without a lot of mental anguish, so passphrases may end up being something long and memorable that wouldn’t be in a dictionary file, such as CWNProcksthehouseallthetime. It is even more common, unfortunately, to have long, complex passphrases pasted on user desktops for easy reference. The selected password may be robust and effective, but the method for managing, storing, and referencing the passphrase may introduce vulnerabilities.

Regardless of the password policy in effect, WPA/WPA2-Personal solutions often require a delicate balance between simplicity and security. Passphrase or PSK selection and management is a major part of that formula.

When in doubt, select a long and ugly passphrase with highly random mixed character strings; or better yet, use utilities such as Password Amplifier from Funk (now Juniper) Software. This tool converts an easy-to-remember phrase (with optional “salt” for additional mixing) into a fairly long and complex password that can be repeated. Figure 11.2 shows the Password Amplifier utility.

For single-use PSKs or complex ASCII passwords, other tools are available, such as Gibson Research Corporation’s Perfect Password feature, which can be found on their website at https://www.grc.com/passwords.htm. If your AP or client devices require the use of a PSK, you can convert a passphrase into a PSK using a helpful tool provided by Wireshark that is available at www.wireshark.org/tools/wpa-psk.html.

IT staff should ensure that the supported client devices support both passphrase and/or PSK entry before settling on a solution. All devices support passphrases, but not all devices support entry of a 64-character (256 bits) hexadecimal PSK.

Per-User Preshared Keys

To date, two wireless vendors (Aerohive Networks and Ruckus Wireless) have introduced proprietary WPA/WPA2-Personal solutions to address some of the inherent drawbacks of ESS-wide PSKs. As we’ve already established, some of the problems related to PSK usage are that a single access credential is shared by all devices/users across the entire ESS. However, both of these vendors offer per-user preshared keys (PPSKs), which is a novel way of providing each user or device with a distinct access credential that is not shared by others. This is accomplished within the framework of standardized, certified WPA/WPA2-Personal.

There are several benefits to this approach. First, by providing a unique passphrase to each user, authorization to network resources can be controlled more granularly. The unique passphrase identifies the user, and the user can be assigned permissions in accordance with their policy or their group’s policy. Individually assigned PSKs also allow for quick and easy deletion or addition of a single user. As in the example we used earlier in this chapter, if an employee leaves the company and the knowledge of the PSK goes with them, IT staff would not be forced to reconfigure each and every device. They could simply delete (or disable) that user along with that user’s PSK. Nothing else needs to be done. Figure 11.3 shows the configuration GUI for Aerohive’s Private PSK™.

In summary, PPSK solutions simplify management, reduce security risks, and provide individualized access control and authorization while maintaining simplicity. PPSK represents many of the advantages of 802.1X/EAP, without many of the drawbacks. Of course, neither Aerohive nor Ruckus would recommend that PPSK be perceived as a sufficient replacement to 802.1X/EAP, but rather as an improvement to WPA/WPA2-Personal. This feature may work quite well in some industry verticals like higher education.

Encryption

When any WPA or WPA2 (Personal or Enterprise) solution is to be used, the encryption strength is an important consideration. Modern 802.11 encryption methods provide assurance of data privacy, integrity, and data authentication. Since we’ve already established that WEP is deprecated and not recommended, we’ll focus only on TKIP and CCMP in this section.

As for Wi-Fi Alliance certifications and encryption, WPA (Personal and Enterprise) supports TKIP and TKIP only. WPA2 requires support for CCMP, but it also includes a provision for simultaneous support of TKIP. Some proprietary implementations allow for the use of CCMP with WPA, but this is nonstandard and, technically speaking, does not differ from using WPA2 with CCMP. In the following sections, we’ll elaborate on these security mechanisms and discuss recommendations for their use.

TKIP

Since WPA was introduced as a temporary solution to replace WEP, even from its inception, TKIP was known to have limitations that could be exploited. As an update to WEP, TKIP was designed with certain constraints in mind, such as the use of the same RC4 encryption algorithm that is used with WEP. In other words, TKIP was never meant to be a long-term solution—it was intended to serve as a patch for the leaking dam of WEP.

As of this writing, TKIP has stood up fairly well to the scrutiny of security researchers, and no severe exploits are currently publicized. However, since TKIP was designed to operate within a limited computing budget (for backward compatibility with legacy hardware), TKIP’s message integrity check (MIC) function (a.k.a. Michael) has only 20 bits of effective security and is subject to vulnerability. For that reason, TKIP was also introduced with “countermeasures.” When two MIC failures are detected within 60 seconds of one another, TKIP-enabled STAs cease receiving frames for 60 seconds. As a denial-of-service attack, TKIP countermeasures are somewhat difficult to produce, and other easier attacks are more likely.

In the latter half of 2009, much was made of new attacks to exploit the MIC integrity function of TKIP. None of the attacks have exposed TKIP encryption keys or encrypted data, but these attacks are indicators that the timeline for TKIP as a recommended solution is coming to a close. In fact, both the IEEE and Wi-Fi Alliance are in the beginning stages of designating TKIP as a legacy encryption mechanism. In the future (beginning with changes in January 2011), the Wi-Fi Alliance will stop certifying clients and APs that support TKIP at all. In the meantime, TKIP is still an acceptable encryption solution, but CCMP is superior by far.

CCMP

Back in 2004, the IEEE completed the task of replacing WEP with TKIP as well as specifying a robust, long-term encryption solution that would stand up to security scrutiny for many years to come. AES-CCMP was introduced with the 802.11i amendment as the long-term solution, and thus far, it has lived up to its billing.

Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) is quite a mouthful, which is why we use the CCMP acronym. CCMP is a block cipher protocol that is paired with the AES encryption method specified by the National Institute of Standards & Technology (NIST) in 2001. The IEEE specified that for 802.11 WLAN encryption, CCMP shall only be used with AES with a 128-bit key and a 128-bit block size. This security implementation is very secure and is thought by security researchers to remain secure for many years to come.

The Wi-Fi organizations that are primarily responsible for forward momentum of the technology are all beginning to take a stronger stance in support of AES-CCMP and against TKIP. Specifically, all modern Wi-Fi equipment that is Wi-Fi Alliance certified must support AES-CCMP. Further, the IEEE specified (in 802.11n-2009) that in order to use 802.11n MCS rates for communication in an RSN, AES-CCMP encryption is required. These are pretty strong messages coming from the Wi-Fi Alliance and IEEE. The point is becoming clear that all modern networks desiring robust privacy, integrity, and data authentication should use AES-CCMP.

The IEEE’s implementation of AES-CCMP has few, very minor published security weaknesses. Of course, selection of a security method is always a trade-off between convenience, cost, industry availability, performance impact, and actual security. For that reason, AES-CCMP may not always be an option, especially with legacy hardware. As we’ve already touched on many times in this chapter, one of the biggest hurdles with the adoption of robust encryption is the additional processing requirements. Many legacy devices can be software-upgraded to support TKIP, but the additional processing overhead of AES-CCMP without hardware acceleration is too much of a performance impact. For new devices, support for AES-CCMP is assumed, so hardware provisions accommodate this processing requirement without a noticeable difference in cost or performance.

To drive home the point, let’s be clear in stating that in all possible cases, AES-CCMP is the recommended encryption solution for Wi-Fi. If you are using TKIP with 802.11n in an RSN, MCS rates are not allowed, and you will not be able to gain any speed advantages over the legacy protocols; CCMP is required for 802.11n MCS rates in this situation. It is the best solution for Wi-Fi encryption for the foreseeable future.

Supporting Multiple Ciphers

In some cases, it may be advantageous to support multiple encryption algorithms within an ESS to accommodate devices with different capabilities. It is important to understand that when multiple ciphers are used within the same ESS, only unicast data traffic is encrypted with each client’s negotiated encryption mechanism.

If you have a CCMP-capable device, it will use CCMP to encrypt unicast traffic if it is supported in the BSS. Similarly, a TKIP-capable device will use TKIP to encrypt unicast traffic. However, encrypted group (broadcast or multicast) traffic is encrypted using the weakest encryption mechanism that is supported in the BSS. In other words, if both CCMP and TKIP are supported, group traffic will be encrypted with TKIP. Therefore, it is important to consider the potential impact of supporting multiple ciphers.

Summary

In this chapter, we looked at several critical components related to the deployment of a network security solution. As we look at these different elements of a holistic security posture, it becomes clear that there are many layers to proper security planning. It is important to consider authentication (proof of identity), confidentiality (encryption), integrity (protection from tampering), accounting (usage tracking), availability (protection from service disruption), and nonrepudiation (auditable proof of activity or inactivity) as a part of security planning.

We looked at legacy security mechanisms that are not generally recommended for use. We also investigated security solutions that may be relevant in the enterprise as well as the SOHO market. Finally, we discussed encryption selection, which is relevant for networks of all types. In the next chapter, we will look at many more advanced topics that are specific to enterprise WLAN security.

Exam Essentials

Identify weak security solutions and protocols. Recognize weak security protocols and deployment models and be able to recommend acceptable alternatives.

Recommend appropriate data encryption solutions and explain design concepts related to their use. Understand the strengths, weaknesses, and design best practices for WLAN encryption protocols, including WEP, TKIP, CCMP, and proprietary solutions.

Review Questions

1. You are tasked with selection and configuration of a security credential for your organization’s WPA/WPA2-Personal WLAN. By what methods can the WPA/WPA2-Personal client credentials be configured on client devices and APs?

A. As a 256-bit ASCII passphrase

B. As a 64 hexadecimal character PSK

C. As an ASCII passphrase at least six characters long

D. As a 256-bit PMK

2. In the enterprise, when is WPA/WPA2-Personal generally a recommended solution? (Choose all that apply.)

A. When client devices do not support 802.1X/EAP

B. When mobile device applications require high-latency roaming times between APs

C. When client devices are provisioned in bulk and would otherwise share 802.1X credentials

D. When the network security policy demands that each user have unique access credentials

3. What are some common problems with short (12 or fewer characters) ASCII passphrases in WPA/WPA2-Personal networks?

A. They are more susceptible to dictionary attacks than longer passphrases.

B. They lead to weak group keys in a BSS.

C. They only produce a 64-bit PMK instead of a 256-bit PMK.

D. Very few AP and client vendors support entry of an ASCII-based passphrase.

4. What term refers to the security practice of obfuscating actual data from unintended receivers as the data crosses the transmission medium?

A. Authentication

B. Confidentiality

C. Integrity

D. Accounting

E. Nonrepudiation

5. What security function falls under the classification of availability?

A. Protection from data tampering

B. Usage tracking and monitoring

C. Protection from service disruption

D. Proof of an entity’s identity

E. Determining a user’s permission

6. The 802.11 connectivity paradigm includes three basic procedures that are part of a wireless connection. In the order in which they occur for an initial 802.11 connection, what are those three basic procedures?

A. Active Discovery, Passive Discovery, Association

B. Discovery, Association, Authentication

C. Authentication, Authorization, Association

D. Discovery, Authentication, Association

E. Identification, Authorization, and Association

7. When a client successfully associates to an AP, the AP assigns the client with a unique parameter so that the client can identify when it has frames buffered at the AP during power save operations. What is this unique client-specific parameter called?

A. Attribute Value Pair

B. BSSID

C. PPSK

D. Association ID

E. Identity MIC

8. Which of the following security solutions provides the most robust protection against network attacks?

A. WEP

B. Shared key authentication

C. MAC filtering

D. SSID hiding

E. WPA-Personal

9. What two authentication types were specified in the original 802.11 specification? (Choose all that apply.)

A. 802.1X/EAP

B. WPA/WPA2-Personal

C. Open authentication

D. WEP authentication

E. Shared key authentication

10. What is the best encryption method specified for use with 802.11 Wi-Fi networks?

A. WEP

B. TKIP

C. RC4

D. RC5

E. CCMP

11. What security-related certification programs are offered by the Wi-Fi Alliance for an AP or client device certificate? (Choose all that apply.)

A. WMM

B. WPS

C. EAP types

D. WPA-Personal

E. WPA2-Enterprise

12. SSID hiding is not generally recommended because some frames require inclusion of the SSID. In what frames is the SSID always included?

A. Beacon

B. Association request

C. Probe response

D. Probe request

E. Authentication response

13. For what reasons is “security by obscurity” not generally recommended? (Choose all that apply.)

A. Even if the signal strength at the edge of a building is fairly low, attackers could use high-gain antennas to pick up a weak signal from a significant distance.

B. Many network applications have stringent RF requirements for proper functionality. By planning power settings, antenna selection, and AP locations for the purpose of “obscurity,” some applications may not work properly in parts of the building.

C. Obscuring the network via RF propagation control is both practically difficult and cost prohibitive. Other security solutions are generally more effective and less expensive.

D. This deployment practice is only achievable with a few select vendors with unique antenna technologies. While this solution is acceptable for those vendors, it does not work well with other vendors.

14. Why is EAP-MD5 not used as an acceptable EAP type? (Choose all that apply.)

A. It does not support mutual authentication.

B. It does not export dynamic keys.

C. Its authentication exchange is subject to dictionary attacks.

D. It does not support secure encryption protocols.

E. It requires use of the weak RC5 encryption algorithm.

15. What are some of the limitations that exist with WPA/WPA2-Personal? (Choose all that apply.)

A. Secure passphrases or PSKs can be difficult to remember.

B. Network-wide passphrase/PSK change management procedures can be cumbersome.

C. Encryption ciphers are less robust than with WPA/WPA2-Enterprise.

D. User-specific policies are more difficult to apply when shared access credentials are used.

16. What EAP types are certified by the Wi-Fi Alliance? (Choose all that apply.)

A. EAP-PSK

B. EAP-MD5

C. EAP-TLS

D. EAP-FAST

E. PEAPv2

17. Due to budget limitations, the network manager has decided that some WEP-only devices will not be replaced this year. For that reason, you have to deploy a BSS that supports WEP. What are some practical security-related fail-safes that should be implemented for the WEP BSS? (Choose all that apply.)

A. Apply ACLs to the traffic on this BSS so that it is limited to the necessary network services only.

B. Segment this BSS with VLANs so that it is logically separated from important network resources.

C. If available, layer the wireless security solution with MAC filters and other pseudo-security methods.

D. Implement a 512 kbps rate limit policy for users of this BSS to mitigate the speed in which a network attack can be conducted.

18. What are the two types of WLAN discovery/scanning?

A. Manual

B. Automatic

C. Passive

D. Active

E. Probe

F. Hidden

19. What encryption method is required when shared key authentication is implemented?

A. None

B. Static WEP

C. Dynamic WEP

D. TKIP

E. AES

F. CCMP

20. What advantages are provided by per-user PSKs when compared with ESS-wide PSKs? (Choose all that apply.)

A. Per-user PSKs allow easier user-based access control with WPA/WPA2-Personal security.

B. Per-user PSKs are easier to manage if a PSK is compromised or an employee leaves a company.

C. Per-user PSKs are standardized and certified by the Wi-Fi Alliance.

D. Per-user PSKs are more secure than ESS-wide PSKs because they support mutual authentication.

Answers to Review Questions

1. B. WPA/WPA2-Personal supports authentication credentials in the form of passphrases or PSKs. A passphrase must be 8–63 ASCII characters long, and the passphrase must undergo a conversion process before it becomes a PSK. This process is called passphrase-to-PSK mapping. Alternatively, you can select a PSK directly by using a string of 64 hexadecimal characters.

2. A, C. WPA/WPA2-Personal can be an effective security selection for the enterprise in the right situations. Some client devices do not support 802.1X at all, which leaves WPA/WPA2-Personal as the next best solution. Also, due to the relatively short authentication and key derivation process for WPA/WPA2-Personal, this solution provides fast roaming times between APs. This is good for applications that are sensitive to high latency. In addition, some clients are configured and deployed in bulk and would share 802.1X/EAP authentication credentials. For these devices, 802.1X may be more work than it is worth.

3. A. When a security policy allows ASCII passphrases instead of 64-bit hexadecimal PSKs, the ASCII should be sufficiently long to prevent dictionary attacks. Most experts agree that 20-character ASCII passphrases are sufficiently strong to prevent dictionary attacks.

4. B. Confidentiality is also known as encryption, privacy, ciphering, obfuscation, or cryptography. This is the practice of changing the plain-text data so that it is not perceptible to unintended receivers. This is an especially important aspect of security for wireless networks since the wireless medium is unbounded and accessible to all.

5. C. Availability is the practice of maintaining the functionality of network service. While availability is a design goal that permeates many areas of network design, the security aspect of availability is related to the task of preventing (or at least detecting) denial-of-service attacks and other security-related issues that could cause service outages.

6. D. Prior to a client device’s attempt to join a network, the client must “discover” the network. Discovery is the first stage in the 802.11 connectivity process. The 802.11 protocol specifies an association state machine that has three states: unauthenticated, unassociated; authenticated, unassociated; and authenticated, associated. So, 802.11 authentication occurs after discovery; then association occurs after authentication.

7. D. When a client associates to an AP, the AP assigns the client a unique identifier known as an association ID (AID). During the power save operation, the AID is used by the client station to determine if the AP has frames buffered for it. If so, that client’s AID will be set to 1 in beacon frames.

8. E. There are many cases where legacy security mechanisms are the only option for WLAN security. Of the options listed, WPA-Personal is still an acceptable security solution for many applications for the near future, but it is on its way to becoming a deprecated solution. WEP, shared key authentication, MAC filtering, and SSID hiding are all weak security solutions that are highly vulnerable to exploitation by attackers.

9. C, E. In the original 802.11 specification, 802.11 authentication (a.k.a. open authentication) and shared key authentication were defined. This is prior to 802.11i, which introduced the use of passphrase/PSK-based authentication as well as 802.1X/EAP authentication. WEP is an encryption method and is not an authentication method.

10. E. AES-CCMP is currently the strongest encryption suite specified for use with 802.11 WLANs. The IEEE specifies that CCMP be used with AES using a 128-bit block size and 128-bit keys. This solution is thought to be secure for many years to come.

11. B, C, D, E. The Wi-Fi Alliance certifies APs and client devices in several areas of Wi-Fi security. WPS is a SOHO solution designed to make security setup easier for most consumers. Additionally, the Wi-Fi Alliance maintains certification programs for both WPA and WPA2 in Personal and Enterprise modes. Finally, they also certify seven different specific EAP types.

12. B. The association request frame always carries the actual SSID. Some vendor implementations allow administrators to remove the SSID from beacons and probe response frames, but this is not an effective security tactic for hiding the network.

13. A, B, C. Security by obscurity refers to the practice of attempting to hide a wireless network by means of RF control. In most cases, the cost and effort required to achieve actual RF obscurity outweighs the actual benefits achieved. Network designers are better off selecting robust security protocols.

14. A, B, C, D. EAP-MD5 was not designed for use in enterprise WLANs and has several flaws. In reality, EAP-MD5 was designed for wired networks and to test basic connectivity between 802.1X participants. It should never be used for wireless networks.

15. A, B, D. Due to its simplicity and intended design, WPA/WPA2-Personal security poses some drawbacks for use in the enterprise. First, secure passphrases must be sufficiently long to prevent dictionary attacks, but then they become difficult to remember. Also, since the passphrase or PSK is generally shared among all users in a BSS, change management can be a problem when the passphrase is compromised.

16. C, D. The Wi-Fi Alliance certifies APs and client devices for seven different EAP types, including EAP-TLS and EAP-FAST. In addition, they certify PEAPv0/MSCHAPv2, EAP-TTLS/MSCHAPv2, PEAPv1/EAP-GTC, EAP-SIM, and EAP-AKA. The latter two are used primarily in cellular networks.

17. A, B, C. Some legacy security mechanisms, like WEP, are still used in many network environments due to budget or hardware limitations. In those situations, WEP is better than nothing and should be deployed along with other layered solutions. WEP-protected networks should be deployed with access only to the network services required for that application, such as a voice server (when used with WEP VoWiFi phones). Rate limiting would not likely prevent or mitigate an effective network attack.

18. C, D. Both active and passive scanning are specified by the 802.11 specification for discovery of service sets. With passive scanning, stations listen for AP beacons, which are transmitted at regular intervals by the AP. With active scanning, stations send broadcast probe requests and receive directed probe responses from the AP.

19. B. Shared key authentication was specified in the original 802.11 specification, but it is now deprecated. Shared key authentication requires static WEP encryption, and makes WEP’s flaws more pronounced and more readily exploitable. For that reason, it should never be used.

20. A, B. Per-user PSKs (PPSK) are a unique feature offered by a few WLAN vendors. PPSK solutions have many advantages over classic ESS-wide, shared PSKs. Namely, PPSKs provide more secure user-based access control, and they are more friendly to management staff when keys must be reconfigured or changed. There are other benefits provided by PPSKs as well.