Re: IEEE 802.11 WPA3 decryption support

[Alexis La Goutte <alexis.lagoutte () gmail com>]

Hi Mikael,

Good idea !
(if remember dot11crypt coming from time where it is AirPcap stuff... with
offloading decryption...)



On Mon, Mar 25, 2019 at 10:33 AM Kanstrup, Mikael <Mikael.Kanstrup () sony com>
wrote:

> Hi,
>
> I started working on WPA3 decryption support. Some parts of it has already
> been merged. While working on it I've noticed a couple of things that I'd
> like to bring up here before spending too much time.
>
> For WPA3 enterprise support keys and mic are no longer a fixed size. This
> will have quite big impact on the dot11crypt code as there are plenty of
> decisions taken based on fixed offsets into data frames. This now must be
> dynamically calculated based on AKM (authentication and key management) and
> cipher suite selected for current connection.
>
> To determine AKM & cipher suite today the dot11crypt engine searches
> through 4-way handshake EAPOL frames. Unfortunately even the format of
> EAPOL frames (MIC length) is based on current AKMS. A "chicken or the egg"
> kind of problem that can be solved by also tracking association req/resp
> frames. These frames are at the moment ignored by dot11crypt. The IEEE
> 802.11 dissector however already dissect both assoc and EAPOL frames
> perfectly fine so should be possible to reuse.
>
> The dot11crypt engine duplicate quite a lot IEEE 802.11 dissector
> functionality but now also lack certain parts. Instead of adding further
> duplication I'd like to propose the following changes:
>
> - Replace the scan for keys functionality from dot11decrypt engine with a
> new SetKey(from, to, key_index, key) function that the IEEE802.11 dissector
> can call when a key is found.
>
> Removing scan for keys means the following can be removed in dot11decrypt:
>
> - Check done on each and every 802.11 frame for certain type/format
> - 4-way handshake frame parsing
> - TDLS frame parsing
> - EAP keydata parsing
> - RSN tag parsing
>
> When this is done next steps to support the new key derivation and
> decryption methods needed for enterprise decryption should be easier.
>
> Any objections, comments? If anyone else is doing larger work in this area
> maybe we can sync the activities.
>
> Best regards,
> Mikael?
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe