802.11n, Security, and MCS RatesBy CWNP On 02/09/2011 - 27 Comments
I had an interesting experience a while back. As I’ve said before, I work primarily from my home office and a local office in West Michigan. I went upstairs for one reason or another (too much coffee), and when I came back down to my office, I caught a whiff of something that surprised me. You ever have that? Perhaps you’ll smell pumpkin pie and it’ll remind you of high school homecoming or the smell of aloe (or moth balls) will remind you of Grandma’s. Well, I walked into my office, smelled this delightful smell, and at first, couldn’t identify it. It took me a few seconds, as I looked up at my open office window, to realize that this captivating aroma in which I partook was none other than fresh air. I’ve been inside too much lately.
As usual, I can’t start a blog without rambling in the first paragraph, but at least my ramblings always lead to my point. My point today has to do with 802.11n security and the things that you learn when you’re trudging through the spec instead of sitting outside soaking up the rays. Specifically, I want to address the relationship between 802.11n, MCS rates, and security.
I read this sentence from the 802.11n-2009 amendment a while back and am often asked what the spec says about this, so it seemed good to share.
8.1.5 RSNA assumptions and constraints
“An HT STA shall not use either of the pairwise cipher suite selectors: “Use group cipher suite” or TKIP to communicate with another HT STA.”
“What’s that mean?”
First, let’s talk about some terminology:
1. An “HT STA” is any 802.11n AP or client.
2. A robust security network (RSN) is a BSS in which only CCMP (default) and TKIP (optional) may be supported.
3. When a BSS supports CCMP and TKIP along with WEP, the BSS becomes a transitional security network (TSN).
Needless reminder: WEP rots.
When a network is configured as an RSN, the parameters of the RSN are advertised in Beacons and Probe Responses (as well as the client’s (re)association requests). These parameters include details like the supported pairwise (unicast) cipher count and types, the group (multicast and broadcast) cipher, preauthentication support, and more.
There are different sets of encryption keys for unicast and group addressed frames. Unicast traffic is encrypted with a set of keys collectively known as the pairwise transient key (PTK) and group addressed traffic is encrypted with the group temporal key (GTK). The PTK is unique per user, but the GTK is shared by all members of a BSS.
It is important to remember that when a single SSID supports multiple cipher suites (such as CCMP and TKIP or TKIP and WEP), group addressed traffic must be encrypted using the lowest common denominator, which is the weakest encryption method available. So, if CCMP and TKIP are supported by an SSID, group addressed traffic is encrypted using TKIP. If TKIP and WEP are supported, group addressed traffic is encrypted using WEP. Unicast traffic is encrypted using the best cipher suite configured for each client station.
So, what is this part of the 802.11n amendment stating? It is stating that in a network that supports CCMP and TKIP (an RSN), 802.11n stations must use CCMP to communicate with one another. The logic here seems pretty simple. Since all 802.11n stations support CCMP (at least, all Wi-Fi certified 11n stations do), there’s no reason not to use the best encryption available for a BSS when communicating from one HT STA to another.
[Edited due to some helpful comments from friends.] The Wi-Fi Alliance and enterprise vendors support this approach and push it a step further. Most, if not all, vendors disable support for 802.11n MCS rates whenever WEP or TKIP encryption are used exclusively. What this means for your WLAN design is that if you want to support 802.11n and get the most from it, use either CCMP, or, when the occasion is right, open networks (such as in guest scenarios).Tagged with: 802.11n, security, wi-fi alliance, TKIP, WEP, IEEE, CCMP, MCS, data rate, draft
Blog Disclaimer: The opinions expressed within these blog posts are solely the author’s and do not reflect the opinions and beliefs of the Certitrek, CWNP or its affiliates.