| Bug ID |
13149
|
| Summary |
Feature request: highlight 802.11 FT AKM suite errors
|
| Product |
Wireshark
|
| Version |
2.2.2
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Enhancement
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 15074 [details]
"FT" 802.11 association request frame with "non-FT" AKM suite
Build Information:
Version 2.2.2 (v2.2.2-0-g775fb08)
Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.3.2, with libpcap, without POSIX capabilities, with
GLib 2.36.0, with zlib 1.2.5, with SMI 0.4.8, with c-ares 1.12.0, with Lua
5.2.4, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP,
with QtMultimedia, without AirPcap.
Running on Mac OS X 10.11.6, build 15G1004 (Darwin 15.6.0), with locale C, with
libpcap version 1.5.3 - Apple version 54, with GnuTLS 2.12.19, with Gcrypt
1.5.0, with zlib 1.2.5.
Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz (with SSE4.2)
Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.9.00).
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
802.11r brought Fast Transitions (FT), among other things adding Authentication
and Key Management (AKM) suites specifically for FT. These AKM suites are to be
used with 802.11r FT [Re-]Association Requests. It is an error to send an FT
association request using a non-FT AKM suite, and vice versa.
I have spent far too much time investigating an issue caused by this error and
arguing about it with two different vendors. All this could have been resolved
much more quickly or perhaps even prevented if this issue were made visible by
the Wireshark dissector, hence this feature request.
IEEE Std 802.11-2012 § 12.4.2 states that a station indicates support for FT
procedures by including a Mobility Domain Element in its (Re)Association
Request frame. Therefore, we can classify an Association Request as "FT" if it
includes a Mobility Domain Element (tag number 54), and "non-FT" if it does
not.
Association requests can also include information about what type of crypto the
station intends to use. This is carried in the Robust Security Network element
(tag number 48). The various crypto mechanisms are described in terms of AKM
suites, which are identified by an {OUI, suite type} tuple.
IEEE Std 802.11-2012 § 8.4.2.27.3 lists the various AKM suites. AKM suites
00-0F-AC:3, 00-0F-AC:4, and 00-0F-AC:9 should be considered "FT". Other AKM
suites should be considered "non-FT" since they are not defined for use with
FT.
IEEE Std 802.11-2012 § 12.4.2 states that an access point shall reject an
association frame that include a MDE (i.e. an "FT" association request) while
having a RSNE that indicates any AKM suite besides those three (i.e. a "non-FT"
AKM suite). This is what I would like the dissector to know: an "FT"
association request with a "non-FT" AKM suite is wrong -- as is a "non-FT"
association request with an "FT" AKM suite -- and it should draw attention to
the fact that the AKM suite is incorrect.
Ideally Wireshark would highlight the entire packet (like a bad checksum),
pointing out the frame as something that's broken, and specifically indicating
on closer examination that the {FT, non-FT} AKM suite is incorrect in the
context of a {FT, non-FT} association request.
A capture of one such association request is attached.
You are receiving this mail because:
- You are watching all bug changes.