Defense Against Multi-Channel Man-in-the-Middle Attacks in IEEE 802.11-17
Protecting against multi-channel Man-in-the-Middle (MITM) attacks in IEEE 802.11-17 is crucial to ensuring network security. This document discusses defense strategies, including operating channel validation, cipher protection, and protocol robustness. Authors Nehru Bhandaru, Thomas Derham, and Mathy Vanhoef address specific vulnerabilities such as IV Reset attacks and propose solutions like the use of Operating Channel Information (OCI) to mitigate risks. Stay informed about potential threats and learn how to safeguard your network against sophisticated MITM tactics.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
doc.: IEEE 802.11-17/1606r3 October 2017 Defense Against Multi-Channel Man-in- the-Middle (MITM) Date: 2017-10-30 Authors: Name Affiliations Address Phone Email Nehru Bhandaru Broadcom Ltd. 190 Mathilda Place, Sunnyvale, CA 94086 +1 408 922 5924 nehru.bhandaru@b roadcom.com Thomas Derham Broadcom Ltd. thomas.derham@br oadcom.com Mathy Vanhoef KU Leuven mathy.vanhoef@cs .kuleuven.be Submission Nehru Bhandaru et. al.
doc.: IEEE 802.11-17/1606r3 Introduction Recent IV Reset attacks against 802.11 RSN Mathy Vanhoef Paper CVE-2017-12968, CVE-2017-13077 CVE-2017-13079 CVE-2017-13080 CVE-2017-13081 CVE-2017-13084 CVE-2017-13086 CVE-2017-13087 CVE-2017-13088 Other exchanges (e.g. FTM, FILS) can be attacked Attacker relays frames Channel based MITM Masquerades as STA against legitimate AP on Channel A Masquerades as AP against legitimate STA on Channel B Generic defense against MITM requires Authentication Verification of protocol attributes Need protocol robustness against generic multi-channel attacks Submission 2
doc.: IEEE 802.11-17/1606r3 Channel-based MITM Channel A Channel B Attacker AP Attacker STA STA AP PTK/GTK Handshake, FTM PTK/GTK Handshake, FTM Attacker uses AP MAC address on Channel A, STA MAC address on Channel B relays frames between AP and STA may buffer frames, drop ACKs and cause retransmissions Submission 3
doc.: IEEE 802.11-17/1606r3 PossibleRSN defense for multi-channel MITM Advertise operating channel validation in RSNE Capability OCVC, Policy OCVR (Required)? Add operating channel information to RSN handshakes Similar to RSNE to protect against cipher downgrade Operating Channel Information (OCI) KDE Country, Operating Class, Channel Number or their Hash OCI KDE, under MIC protection included in M2 and M3 of 4-way handshake G1 and G2 of GTK handshake Receiver compares current operating channel information with that received in KDE Discard on mismatch if OCVC peer Discard on absence if OCVR device Submission 4
doc.: IEEE 802.11-17/1606r3 Related Topics - FT, FILS, FTM Do FT handshakes need this protection? Initial FT association uses 4-way handshake Reassociation MIC does not include channel information VHT/HT Operation Elements from AP non-AP STA Non-HT ? non-AP STA AP Include channel information as optional Subelement in FTE FTE is already validated via MIC Channel information needs to be validated if OCVC Do FILS handshakes need this protection? Association frames protected by MIC EAPOL frames protected by AEAD Include channel information KDE No change to FTE in TPK handshake Should 11az provide this protection? Authenticate channel information along with LMR feedback? Submission 5
doc.: IEEE 802.11-17/1606r3 Related Topics - Channel Switch Channel switch during 4-way or GTK handshake? Unlikely, but M1 and M4 need to be validated to be on the same channel as M3 and M2 respectively BSS Transition okay FT Action is protected Reassociation and key confirmation Channel Switch Announcements Beacons, Unprotected or Protected Dual of Public Action Recommend using Protected announcements Attacker may block even protected CSA and assume MITM position Attack window open until next handshake When peer STA supports OCVC initiate an SA Query? SA Query and Response frame extension to include channel information Channel information validation on SA query receipt Disassociate if validation fails Submission 6
doc.: IEEE 802.11-17/1606r3 Related Topic - Same Channel MITM AP and STA are within range of each other Hard to attack reliably Buffering and replay not effective AP and STA are out of range, but in range of the attacker Is there anything that can be done here? Submission 7
doc.: IEEE 802.11-17/1606r3 Strawpoll(s) A. 802.11 specification should define a mechanism to protect against multi- channel MITM Y: N: A: A. RSNE should advertise operating channel validation capability and policy Validation: Require: None: A. Operating channel information should be included and MIC protected in RSN key exchanges - Pairwise and Group Key handshakes Y: N: A: A. Operating channel information should consist of one of a. Country, Operating Class and Channel(s) b. Hash of Operating Channel Information c. Other Submission 8
