Cisco WPA3 configuration
What’s the Difference Between WPA2 and WPA3?
To really understand this difference we have to tell a little bit of the history since Wi-Fi security has a long past.
once upon a time ....
The original Wired Equivalent Privacy (WEP) for 802.11 wireless networks was inplemented with 802.11a and 802.11b. It used an RC4 stream cipher for encryption and the CRC-32 checksum for integrity. WEP has 64-bit and 128-bit versions. Unfortunately, though, it’s been hacked like a piece of cake and in fact it is garbage!
The Wi-Fi Alliance addressed WEP by moving to Wi-Fi Protected Access (WPA). WPA2 has been commonly used and improved since 2004. Most systems ship with WEP for backward compatibility, but WPA2 is the recommended platform all around the world speacially in DACH region and Europe.
WPA2 utilized the Advanced Encryption Standard (AES) to provide better security along with new handshake protocols. WPA2 has been under attack, too, like PMKID Hashcat, WPA2 KRACK attack etc. WPA2 could make it just a little bit harder for crackers to gain access but could never be an ultimate security solution.
WPA3 was released in June of 2018. Like WPA2, it has WPA3-Personal and WPA3-Enterprise versions. WPA3 forces youto use Protected Management Frames (PMF), whereas the PMF was a late option kinda feature and optional for WPA2. The 128-bit AES encryption employed with WPA2 is still in effect with WPA3, but the enterprise version requires 192-bit AES support. It’s optional for the personal edition.
WPA3 uses the Simultaneous Authentication of Equals (SAE) to replace WPA2’s Pre-Shared Key (PSK) exchange protocol. SAE is a more secure protocol for handling the initial key exchange exploited with the KRACK methode. SAE, also known as Dragonfly Key Exchange, uses forward secrecy and is resistant to offline decryption attacks.
In this post we will look at WPA3-SAE Transition Mode implementation. Your requirements for transition mode are:
• When WPA2-PSK and WPA3-SAE are configured on the same BSS (mixed mode), the AP should reject an association for SAE if PMF is not negotiated for that association
• A WPA3-SAE STA should negotiate PMF when associating to an AP using WPA3-SAE Transition Mode
• When WPA2-PSK and WPA3-SAE are configured on the same BSS (mixed mode), PMF should be set to capable (MFPC bit should be set to 1, and MFPR bit should be set to 0 in the RSN Capabilities field in the RSNE transmitted by the AP)
In the transition mode both WPA3-SAE supported client as well as WPA2-PSK supported clients can connect to same SSID. So in this mode, WPA2-PSK clients’ traffic can be decrypted where as WPA3-SAE clients’ traffic cannot be decrypted even password is compromised.
Here you can see SSID security configuration that enable both WPA2 & WPA3. Note that PMF set to optional as WPA2-PSK clients may not support it.
Let's jump into some packet captures for better illustration!
Also note that AP advertise it is PMF Capable, but set PMF required to False under RSN Capabilities field.
We used NetAlly AirCheckG2 (6c:0b:84:c2:4e:99) and google Pixel3phone (5e:a7:ec:a8:33:ab) for testing. You can filter Pixel3 Phone traffic without control frames using below Wireshark display filter.
wlan.addr==5e:a7:ec:a8:33:ab && not wlan.fc.type==1
As you can see Pixel3 is go through WPA3-SAE (4 auth frames, Ass Req/Res, 4-Way handshake)
If you look at Association Request frame (#156) details, you will see AKM is SAE and both PMF Required & PMF Capable bit set to 1.
You can filter AirCheckG2 traffic without control frames using below display filter.
wlan.addr==6c:0b:84:c2:4e:99 && not wlan.fc.type==1
You will notice AirCheckG2 connecting using normal WPA2-PSK method (2 Open Auth frames, Assoc Req/Res, 4 Way Handshake). Pls note that I have used “Cisco123” as password for this SSID and you can see WPA2-PSK traffic can be decrypt easily
Because of some reason AirCheck Traffic seems having some issue, only see TCP SYN mostly.
You can see AirCheckG2 is doing its testing (DHCP, DNS, ICMP) as part of connecting to given network.
If you look at Association Request frame #146 ( 147 & 148 are re-transmission of same frame #146) , you will see AKM suite is PSK and MFPC bit set to False. Since no PMF support, no group management cipher suite included in RSNE.
If you look for Robust Management Frame in this capture, you can check those frames are protected or not. There are 3 types of Management frames are considered as robust management frames when PMF in action. Those are
* Deauthentication frames * Disassociation frames * Robust Action Frames (action codes as per table 9-47 IEEE 802.11-2016)
0 – Spectrum Management 1 – QoS 2 – DLS 3- Block Ack 6- Fast BSS Transition (FT) 8 – SA Query 9- Protected Dual of Public Action 10 – WNM 13 – Mesh 14 – Multihop 16- DMG 18 – Fast Session Transfer 19 – Robust AV streaming
Specific to Pixel3, you will see those robust management frames are now encrypted. You can find a deauth frame where data get encrypted using CCMP as it is individually addressed robust management frame. Note that Protected Flag is set to 1 in that frame.
There are certain vulnerabilities of WPA3-SAE Mode. You can watch following video on those vulnerabilities. (Dragonblood A Security Analysis of WPA3’s SAE Handshake by Mathy Vanhoef).
– Attacks on the STA
• Downgrade Diffie Hellman Groups used in SAE
• ECC and MODP side channel timing attacks • Switch clients from WPA3 Personal to WPA2 Personal on transition mode BSS
– Attacks on the AP
• DoS from flooding spoofed authentication frames to AP
TRADEMARK LEGAL NOTICE
All product names, logos, and brands are the property of their respective owners in Austria or other countries. All company, product and service names used in this website are for identification purposes only. Pheniix is not affiliated with or an official partner of Cisco, CompTIA,Dimension Data, VMware, Amazon, Microsoft, Certified Ethical Hacker, (ISC)², Juniper, Wireshark, Offensive Security,Google, GNS3, F5, Python, Linux, Java, OpenStack, Vagrant, Ansible, Docker, GIT, Blockchain or other companies. Use of these names, logos, and brands does not imply endorsement. The opinions expressed in Pheniix are personal perspectives and not those of Cisco, Dimension Data or any other company. Pheniix runs as an independent blog.
#IPSEC #SecurityCenter #InfoSec #ASASecurityDeviceManagerASDM #CCNASecurity #NationalCyberSecurityAwarenessMonth #Cybersecurity #ServiceProvider #CloudSecurity #Security #security #NationalSecurityAgencyNSA #IBMSecurity #CiscoSecurity #cybersecurity #securityflaw #CyberSecurity #CCNAWireless #Wireless #WPA3 #WPA2 #WEP #MikeGhahremani #Pheniix #Mike #CCIE #CCIELab #CCNARoutingandSwitching #CCNAIndustrial #CCNA #CCNP