802.11ac Encryption Upgrade

encryption

The security features provided by the IEEE 802.11 standard haven’t changed much since the 802.11i amendment was ratified in 2004, which is more commonly known by its Wi-Fi Alliance certification name WPA2. 802.11w protected management frames were introduced in 2009, but it is only recently that Wi-Fi chipsets for client devices have included support for it. WPA2 introduced the robust CCMP encryption protocol as a replacement for the compromised WEP-based encryption schemes of the past. CCMP utilizes stronger 128 bit AES encryption keys. As a general rule of thumb, if you aren’t using CCMP on a Wi-Fi network designed for security, you’re doing it wrong. It’s been out for a long time and older protocols have well-established weaknesses.

11acHowever, there are some new encryption changes in the 802.11ac amendment which have mostly flown under the radar. Besides 256 QAM, wider channels, and MU-MIMO, 802.11ac now includes support for 256 bit AES keys and the GCMP encryption protocol. Galois Counter Mode Protocol is a more efficient and performance-friendly encryption protocol than CCMP.

A few interesting nuggets from section 11.4 of the 802.11ac amendment:

The AES algorithm is defined in FIPS PUB 197-2001. All AES processing used within CCMP uses AES with either a 128-bit key (CCMP-128) or a 256-bit key (CCMP-256).

And…

CCMP-128 processing expands the original MPDU size by 16 octets, 8 octets for the CCMP Header field and 8 octets for the MIC field. CCMP-256 processing expands the original MPDU size by 24 octets, 8 octets for the CCMP Header field, and 16 octets for the MIC field.

By the way, you can download the 802.11ac amendment or the entire 802.11-2012 standard from the IEEE here for free. For more on these security changes read sections 8.4.2.27 and 11.4 of the 802.11ac amendment.

It seems odd that these changes were included in the 802.11ac amendment, and not in a separate security-focussed amendment like 802.11w and 802.11i. Nothing wrong with it, just unexpected. I’m curious to see if the 802.11ax amendment includes security changes as well.

Why the addition of 256 bit AES keys? It could have something to do with a few chinks in the armor of 128 bit AES keys. The current attacks appear to be impractical, but future attacks that take advantage of quantum computing may put 128 bit AES keys at risk. NIST thinks that larger key sizes are needed to defend symmetric AES keys like those used in WPA2 against quantum computer attacks, which they say will be operational within the next 20 years. I’ll take their word for it.

Because the amendment only specifies CCMP-128 as mandatory for RSN compliance, it’s very unlikely that we’ll see CCMP-256/GCMP-256 in use anytime soon. Further, enabling 256 bit cipher suites effectively disables support for all non-802.11ac clients as well as 802.11ac clients that only support the mandatory cipher suites (most of them?). That’s because CCMP-256 and GCMP-256 pairwise keys are only compatible with 256 bit group keys, breaking backwards compatibility with legacy clients. There are also a lot of 802.11n clients out there that aren’t going away anytime soon, so actually deploying CCMP-256/GCMP-256 will require a separate CCMP-256/GCMP-256-only SSID. Excited yet?

Further, I can’t find any documentation that suggests that infrastructure vendors have implemented CCMP-256/GCMP-256 at all, just a few slide decks here and there with an overview of the changes. These cipher suites appear to be optional, so I wonder if any VHT clients or AP’s actually support them today, and when they will in the future. The Linux Wi-Fi configuration API cfg80211 and driver framework mac80211 have added software support for it. That’s about all the implementation I have found. Perhaps PCS compliance or Wi-Fi Alliance certification will eventually force the issue, or perhaps it will go the way of 802.11n Tx beamforming and never be implemented. There are a lot obstacles to overcome before 256 bit keys become practical.

However, a VHT client can negotiate a GCMP-128 RSNA within a BSS that uses a backwards-compatible CCMP-128 group key, and the 802.11 standard does support multiple pairwise cipher suites within a BSS (remember TSN’s?). That allows the GCMP-128 pairwise cipher suite to be used alongside everyday CCMP-128 pairwise and group keys on real, production networks.

To tell if a BSS is using one of the new cipher suites in a packet capture, look at a beacon frame’s RSN information element. The cipher suite selector is always 00-0F-AC for the CCMP/GCMP encryption protocols, it’s the cipher suite type that distinguishes between the specific cipher suites. For example, 00-0F-AC:4 is the default CCMP-128, 00-0F-AC:9 indicates GCMP-256 and 00-0F-AC:10 indicates CCMP-256. Group keys for a BSS with protected management frames have their own suite type numbers. Look for multiple pairwise cipher suites to find support for the new stuff. Here’s the table of the new cipher suites. I’m on the lookout for 00-0F-AC:8 (GCMP-128), but I’ve yet to find a beacon frame with it advertised.

Table 8-99—Cipher suite selectors

OUI

Suite type  Meaning
00-0F-AC  4 CCMP-128 – default pairwise cipher suite and default group cipher suite for data frames in an RSNA
 00-0F-AC  6  BIP-CMAC-128—default group management cipher suite in an RSNA with management frame protection enabled
 00-0F-AC  8  GCMP-128 – default for a DMG STA
 00-0F-AC  9  GCMP-256
 00-0F-AC  10  CCMP-256
 00-0F-AC  11  BIP-GMAC-128
 00-0F-AC  12  BIP-GMAC-256
 00-0F-AC  13  BIP-CMAC-256

Interesting note that GCMP-128 is the default for a DMG STA, which is a directional multi-gigabit station defined in the 802.11ad amendment for operation in the 60 GHz band.

The standard limits the mixing of cipher suites so that the key sizes of the pairwise and group keys must match, and GCMP group keys can only be used with GCMP pairwise keys.

 

 

WLAN Vendors: The NBASE-T Ball is in Your Court

I’m going to echo the position of Marcus BurtonLee Badman, and Andrew von Nagy. Despite the marketing push, there really is no need for > 1 Gbps link to a 802.11ac Wave 2 AP. Not at the access layer at least.

This Wi-Fi gauge goes up to 6.8 Gbps, so that means we need a 10 gig port for every AP, right?

Back to reality: 802.11ac Wave 2 is roughly 7 Gbps max with 8 spatial streams and 160 Mhz channel bandwidth, but most will use 4 spatial streams at max, cutting that in half. If you’re lucky you’ll will use 40 Mhz wide channels, cutting that four-fold. Then take off another 40% for layer 2 overhead and you get roughly 500 Mbps at half duplex on the wire. Maybe a gigabit with 80 Mhz channel width and absolutely ideal conditions that don’t exist outside of the lab.

Even if you have room for 160 Mhz wide channels, which might be possible if the FCC expands 5 Ghz unlicensed spectrum and then client adapters are updated to support those new channels, what is it that clients are using that calls > 1 Gbps of throughput? Remember that Wi-Fi is access layer technology. What applications are you supporting today or anytime in the foreseeable future that call for > 1 Gbps to a small group of clients?

Probably nothing coming over a WAN link. That leaves LAN applications. The list of potential applications provided by the NBASE-T Alliance doesn’t establish the need very well. Security cameras and signage systems?

It’s hard to think of many scenarios where it will be necessary to provide > 1 Gbps of throughput at the access layer. I can’t think of any of those that wouldn’t be better served by a wired solution.

Point to point Wi-Fi links in the distribution layer could benefit from NBASE-T, but how short must those links be to support 256 QAM, and is 8 spatial streams really possible outdoors with limited multipath? I don’t know the answers to those questions, but I don’t imagine that many locations exist that need > 1 Gbps of throughput that haven’t already provided that with fiber. We’re talking serious edge cases here, not typical enterprise Wi-Fi.

In any event, despite the hype, it will be a long time before the need for > 1 Gbps switchports extends outside of the network core and distribution layers.

WLAN vendors have an important decision to make here. Because 802.11ac appears to be the major justification for NBASE-T switches, I imagine they are under a lot of pressure right now. To get real interest in these new NBASE-T switches,  AP’s will have to be built with NBASE-T interfaces that use the faster speeds. I assume that those interfaces will be more expensive than standard gigabit interfaces. Given that NBASE-T supports 10 Gbps I bet they will be a whole lot more expensive than the gigabit interfaces used today. Just a guess though. Time will tell what this stuff really costs.

Will WLAN vendors become accessories to this marketing crime and include these potentially expensive interfaces in their Wave 2 AP’s? Aruba and Ruckus recently joined Cisco in the NBASE-T Alliance. We’ll have to wait and see their plans for the technology.

I hope that 802.11ac Wave 2 enterprise AP’s are still made with standard gigabit interfaces. Speciality AP’s like those used in point to point links could benefit from multigigabit interfaces, but the AP’s that are sold by the dozens for typical enterprise purposes do not. The added cost of an underutilized NBASE-T interface is not justified by real world needs.

Perhaps the usual product cycle will repeat itself. The first Wave 2 AP’s will have the highest end hardware and NBASE-T interfaces. Then the mid- and low-range AP’s that follow and actually get sold will have gigabit interfaces.

Whatever the case, it’s going to be interesting to see how the marketing hype about 802.11ac Wave 2 evolves as more people get clued in to its real world performance.