At this year’s Wireless LAN Professionals Conference (WLPC) in Prague, I again presented a 10Talk. This time, it was about the different versions of IEEE 802.1X:
You can download the presentation slides here:
In this blog post, I have some additions to this presentation.
My initial animation was not captured. But burning 802.11X to the ground is this presentation’s second most crucial part!
x or X?
Am I confident that the capital X is the only way to write about this? Yes, I’m dead serious! Writing 802.1x shows a form of “I don’t care about details or accuracy”!
My example of different versions on Supplicant and Authenticator
When discussing the .1X exchange between my iPhone and the Cisco Catalyst WLC, I mention that the WLC uses Version 2010 of .1X for a good reason. But I didn’t make the reason clear.
The Catalyst 9800 uses IOS-XE, Cisco’s primary operating system for campus switching. As this platform supports MACsec, it also supports IEEE 802.1X-2010. There would likely be no need for EAP to announce this on the wireless side, but there is also no need to differentiate between .1X for LAN and WLAN.
On the other hand, I was wondering about the iPhone using version 2001 for EAP and version 2004 for the 4-way handshake. iOS differentiates which operation is done instead of just using version 2004 everywhere.
The RSN Key Descriptor Type
When talking about 802.1X-2004, I also talked about the RSN Key descriptor type we use for the 4-way handshake.
For that, I want to show a capture that I didn’t include in my talk, mainly because I have no explanation of the “why”:
I took this capture two years ago and don’t remember the client device. And with the device using MAC address randomization, I’ll likely never find out.
This device uses IEEE 802.1X version 2001 with a key descriptor type of “2” for RSN, which is not defined in the 2001 version of the standard. And the 2001 standard states in 7.6.1, “All other possible values of Descriptor Type are reserved for future standardization.”
My authenticator, the Meraki MR access point, processes this frame. However, the standard (IEEE 802.1X-2004, 7.5.7 e) states that an incoming PDU of a lower version should be interpreted as that lower version and all undefined parameters in that version should be ignored.
I would expect that other authenticators will behave the same. We all know that clients often don’t behave well.
I also mentioned that version 2010 of 802.1X addresses the two most relevant Security Considerations. These are (IMO):
– Session highjacking
When the client is authorized in a wired 802.1X session, an attacker could remove the original client and take over the session by reusing the client’s MAC address. This will only work until the next reauthentication, but that timeframe is too long, regardless of the timeout. The solution to this problem is to implement MACsec. If there is a cryptographic session between the Supplicant and the Authenticator, the attacker won’t know the session keys to take over the session. Sadly, there is no native support for MACsec in Windows.
802.1X and SNMP
When talking about 802.1X-2010, I ignored the last paragraph because I feared running out of time.
In the past, also around 2010, I often implemented SNMP for my customers. Whenever there was SNMP already running, it was always SNMPv2. And I often wondered why they didn’t implement SNMPv3. In the early times, there was a lack of support on the management servers, but most of the time, it was based on vendor statements that SNMPv3 was more CPU-intensive. I typically answered, “There are enough fast and insecure systems; we should not add another one. ” I don’t remember the exact wording and who said this (Bruce Schneier?), but it nails it.
I was astonished that access to MIBs is not allowed with SNMP versions lower than v3.
What are your thoughts on this? Do you also have captures with version 2001 doing the 4-Way handshake, and do you know which devices these are? Am I overreacting with my 802.1x vs. 802.1X opinion? Please leave a comment!