Understanding 802.11i Wireless Networking: Authentication Protocols and Security Measures

1. CS 259 802.11i Wireless Networking Authentication Protocol J. Mitchell

2. Next few lectures • Tuesday 1/17 • Brief cryptography background • Key exchange protocols and properties • Today 1/19 • Some project ideas • Wireless security: 802.11i • Choose your project partner • Next Tues 1/24 • Password authentication protocols • Next Thurs 1/26 • Contract-signing protocols • Thursday after that 2/2 • Project presentation #1 • What system? What does it do? How does it work? In 5 minutes.

3. Some Project Ideas • VoIP • Privacy, authentication, DoS issues, Billing fraud • Traffic shaping? • SIP, H.323, Skype etc. • Password based authentication protocols • Vulnerability to dictionary attacks? • Fair exchange protocols • Voting protocols, anonymity • Digital cash • Anonymous electronic voting (Bart Jacobs’ water election protocol?) • Internet infrastructure protocols • SPF, other SMTP authentication mechanisms • S-BGP, BGP-S • Secure DNS, other DNS enhancements • NTP protocol? • Access policies? HIPAA compliance? • Look at last year’s projects

4. Changhua He • CS259 Project in 2004 • Mur analysis of 802.11i 4-way handshake protocol • PhD completed 2006 • Publications • Three papers on 802.11i (one with Mukund as coauthor) • http://theory.stanford.edu/~changhua/pubs.html

5. 802.11i Wireless Authentication

6. Wireless Threats • Passive Eavesdropping/Traffic Analysis • Easy, most wireless NICs have promiscuous mode • Message Injection/Active Eavesdropping • Easy, some techniques to gen. any packet with common NIC • Message Deletion and Interception • Possible, interfere packet reception with directional antennas • Masquerading and Malicious AP • Easy, MAC address forgeable and s/w available (HostAP) • Session Hijacking • Man-in-the-Middle • Denial-of-Service: cost-related evaluation

7. Wireless Security Evolution • 802.11 (Wired Equivalent Protocol) • Authentication: Open system (SSID) and Shared Key • Authorization: some vendor use MAC address filtering • Confidentiality/Integrity: RC4 + CRC • Completely insecure • WPA: Wi-Fi Protected Access • Authentication: 802.1X • Confidentiality/Integrity: TKIP • Reuse legacy hardware, still problematic • IEEE 802.11i (Ratified on June 24, 2004) • Mutual authentication • Data confidentiality and integrity: CCMP • Key management • Availability

8. What Went Wrong With WEP • No Key Management • Long Lived keys • Fix: Use 802.1X ( Standard for user, device authentication ) • Crypto Issues RC4 cipher stream • Key size: 40 bit keys • Initialization Vector too small:24 bit • Integrity Check Value based on CRC-32 • Authentication messages can be forged

9. Supplicant UnAuth/UnAssoc 802.1X Blocked No Key Supplicant Auth/Assoc 802.1X Blocked No Key Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Supplicant Auth/Assoc 802.1X Blocked MSK Supplicant Auth/Assoc 802.1X UnBlocked New GTK Supplicant Auth/Assoc 802.1X Blocked PMK Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorAuth/Assoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X UnBlocked New GTK AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorUnAuth/UnAssoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X Blocked No Key Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) MSK Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key 802.11 Association EAP/802.1X/RADIUS Authentication MSK 4-Way Handshake Group Key Handshake Data Communication 802.11i Protocol

10. Outline • Wireless Threat Models • IEEE 802.11i • Attacks and Solutions • Attacks on Authentication: • 1. Security level rollback • 2. reflection attack • Attacks on Availability: • 3. Michael countermeasure attack • 4. RSN IE poisoning • 5. 4-Way Handshake blocking • Failure Recovery and improved 802.11i • Conclusions

11. Security Level Rollback Attack Authenticator RSNA enabled Pre-RSNA enabled Supplicant RSNA enabled Pre-RSNA enabled Bogus Beacon (Pre-RSNA only) Beacon + AA RSN IE Probe Request Bogus Probe Response (Pre-RSNA only) Probe Response + AA RSN IE 802.11 Authentication Request 802.11 Authentication Response Bogus Association Request (Pre-RSNA only) Association Request + SPA RSN IE 802.11 Association Response Pre-RSNA Connections

12. Solutions • Security Level Rollback Attack • Similar to general version rollback attack • Destroy security since WEP is insecure • Not vulnerability of 802.11i standard, but an implementation problem • Solutions • Allow only RSNA connections: secure, but too strict for common networks, where Transient Security Network is more convenient • Deploy both, but • Supplicant manually choose to deny or accept • Authenticator limit pre-RSNA connections to only insensitive data

13. Reflection Attack Adversary Impersonates Communicating Peers Legitimate Devices Authenticator and Supplicant {A1, Nonce1, sn, msg1} {A2, Nonce1, sn, msg1} {A1, Nonce2, RSN IE, sn, msg2, MIC} {A2, Nonce2, RSN IE, sn, msg2, MIC} {A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {A2, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {A1, sn+1, msg4, MIC} {SPA, sn+1, msg4, MIC} Peers Authenticated Bogus Authentication

14. Reflection Solutions • Possible in ad hoc networks • Violates mutual authentication • Solutions: • Restrict each entity to single role • Access point is not wireless station • Allow one entity to have two roles • But require different pairwise master keys (PMK)

15. 802.11i Availability • Not an original design objective • Physical Layer DoS attacks • Inevitable but detectable, not our focus • Network and upper Layer DoS attack • Depend on protocols, not our focus • Link Layer attack • Flooding attack: Lots of traffic and power req’d • Some Known DoS attacks in 802.11 networks • DoS attack on Michael algorithm in TKIP • RSN IE Poisoning/Spoofing • 4-Way Handshake Blocking • Failure Recovery

16. Known DoS attacks and Solutions • DoS attacks on plain 802.11 networks • Forge unprotected management frames, like Deauthentication/Disassociation frame • Exploit virtual carrier sense mechanism by forging unprotected control frames, like RTS/CTS etc. • 802.11i still has these problems, solutions could be • Authenticate management frames • Validate virtual carrier sense in control frames • DoS attacks on EAP messages • Forge EAPOL-Start, EAPOL-Success, EAPOL-Logoff, EAPOL-Failure • 802.11i can eliminate these by simply ignoring them ! • Send more than 255 association request to exhaust the EAP identifier space (8 bits) • Adopt separate EAP identifier counter for each association

17. MAC IV/KeyID Ext. IV Data/MSDU MIC ICV FCS Contains TSC Encrypted TKIP MPDUFormat Michael Countermeasure • TKIP Michael algorithm and countermeasures • Message Integrity Code (MIC), provide 20-bit security • one successful forgery / 2 min., need countermeasures • Cease communication for 60 sec. if two Michael MIC failures detected in one minute, re-key & deauthentication • Limit to one successful forgery / 6 month • Check order: FCS < ICV < TSC < MIC • Update TSC unless MIC is validated

18. Michael DoS and Solutions • DoS attack through MIC failures • Intercept a packet with valid TSC (possible) • Modify packet and corresponding values of FCS, ICV (easy) • Send modified packet twice in one minute (easy) • MIC always invalid, TSC always valid • Solutions • When MIC failure, cease communication only, no re-keying and deauthentication • Update TSC before MIC is validated • What happens if modify TSC to extremely large number? • Change TSC also change encryption key, wrong decryption • Some confidence on TKIP key schedule algorithm • Mitigation but not elimination

19. Bogus Beacon + Modified RSN IE Bogus Probe Response + Modified RSN IE Disassociate the Supplicant RSN IE confirmation failed, Disassociation RSN IE Poisoning Supplicant Unauthenticated Unassociated 802.1X Blocked AuthenticatorUnauthenticated Unassociated 802.1X Blocked (1) Beacon + AA RSN IE (2) Probe Request (3) Probe Response + AA RSN IE Legitimate Message Exchanges (18) {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC}

20. RSN IE Poisoning: Solutions • Easy to launch the attack • Legitimate participants unaware of it • Continue message exchanges, waste resources • Adversary have more time to repeat the attack • Solutions • Authenticate management frames • Difficult to authenticate Beacon and Probe Response frame • Confirm RSN IE as soon as possible (EAP-TLS) • Necessary modifications on the standard • Relax the condition of RSN IE confirmation • Ignore insignificant bits, only confirm authentication suite • If authentication suite modified, probably error at the beginning of associations

21. Supplicant Auth/Assoc 802.1X Blocked PMK Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorAuth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK Authentica-tion Server(RADIUS) No Key Authentica-tion Server(RADIUS) No Key 802.11 Association EAP/802.1X/RADIUS Authentication {AA, ANonce, sn, msg1, PMKID} {SPA, SNonce, SPA RSN IE, sn, msg2, MIC} {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC} {SPA, sn+1, msg4, MIC} Group Key Handshake Data Communication The 4-Way Handshake MSK

22. Problem Statement • Assumption • PMK is shared between the Supplicant and the Authenticator • Handshake Goals • Confirm the possession of PMK • Derive a fresh session key for data transmission PTK=PRF{PMK, AA||SPA||ANonce||SNonce} • Analysis • Based on the existing specifications of the 4-way handshake • Murj verification using “rationale reconstruction”

23. Modeling the 4-Way Handshake • Authenticators/Supplicants: • Each authenticator maintains one association with each supplicant, and vice versa • Each association has a uniquely shared PMK • Multiple sequential legitimate handshakes in one association • Intruder • Impersonate both supplicant and authenticator • Eavesdrop, intercept and replay messages • Compose messages with known nonce and MIC • Forge fresh Message 1 • Predict and replay nonces for pre-computation of MIC • Rationale reconstruction • Turn on/off fields: nonce, sequence, msg, address

24. AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC Simplified 4-Way Handshake Supplicant Auth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X Blocked PMK PTK Derived PTK Derived Random GTK AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC PTK and GTK 802.1X Unblocked PTK and GTK 802.1X Unblocked

25. Protocol Clarifications • Sequence number, AA, SPA • Essentially redundant • Message flag • Necessary to be included and protected • Otherwise could ambiguously use Msg 2 as 3, or vice versa • Exclusive supplicant and authenticator • Otherwise reflection attacks • Fresh nonces • Globally unique and unpredictable • Otherwise pre-computation attacks and replay attacks

26. AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC AA, ANonce, sn, msg1 AA, ANonce, sn, msg1 Forged Message 1 Attack Supplicant Auth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X Blocked PMK PTK Derived PTK Derived Random GTK AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC PTK and GTK 802.1X Unblocked PTK and GTK 802.1X Unblocked

27. Need for “half-open” handshakes • TPTK/PTK solution • Proposed in the documentation • Does not work for all cases • Keep state for each Message 1 received • Memory/CPU exhaustion • Similar to TCP SYN flooding attack • Interleaving handshakes may be required • Authenticator can reject unexpected messages • Supplicant must accept Msg 1 in all stages • Parallel incomplete handshakes are required

28. Countermeasures (1) Random-Drop Queue: Randomly drop a stored entry to adopt the state for the incoming Message 1 if the queue is filled. Not so effective

29. Countermeasures (2) • Authenticate Message 1 • To reuse the algorithms/hardware, set nonces to special values, e.g., 0, and derive PTK. • Calculate MIC for Msg 1 using the derived PTK • Good solution if PMK is fresh • If PSK and cached PMK, replay attacks ! • Add a monotonically increasing global sequence counter • Use local time in authenticator side • Sufficient space in Message 1 ( 8-octet sequence field ) • No worry about time synchronization Modifications on packet format

30. Countermeasures (3) • Re-Use Nonce • Supplicant re-use SNonce until one 4-way handshake completes successfully • Derive correct PTK from Message 3 • Authenticator may (or may not) re-use ANonce • Solve the problem, but • Attacker might gather more infomation about PMK by playing with Message 1, recall PTK=PRF{PMK, AA||SPA||ANonce||SNonce} • More computations in the supplicant Performance Degradation

31. Our Proposal • Combined solution • Supplicant re-use SNonce • Store one entry of ANonce and PTK for the first Message 1 • If nonce in Message 3 matches the entry, use PTK directly; otherwise derive PTK again and use it. • Advantages • Eliminate the memory DoS attack • Ensure performance in “friendly” scenarios • Only minor modifications on the algorithm in the Supplicant • No modifications on the packet format • Adopted by TGi • Documentation will be updated once a chance

32. Failure Recovery • Important for large protocols like 802.11i • Not affect protocol correctness, but efficiency • Not eliminate DoS vulnerabilities, but make DoS more difficult • 802.11i adopts a simple scheme • Whenever failure, restart from the beginning, inefficient ! • Tradeoffs • Defensive DoS attack vs Captured DoS attack • Assumptions on adversary’s capability and network scenario • A better failure recovery for 802.11i • If failure before 802.1X finishes, restart everything • Otherwise restart components from nearest point • channel scanning time >> protocol execution time

33. Complex Control Flows Simple Flow Complex Flow

34. Stage 1: Network and Security Capability Discovery Stage 2: 802.1X Authentication (mutual authentication, shared secret, cipher suite) 802.1X Failure Stage 3: Secure Association (management frames protected) Association Failure Stage 4: 4-Way Handshake (PMK confirmation, PTK derivation, and GTK distribution) 4-Way Handshake Timout Stage 5: Group Key Handshake Group Key Handshake Timout Stage 6: Secure Data Communications Michael MIC Failure or Other Security Failures Improved 802.11i Architecture

35. Vulnerability Summary

36. Conclusions • 802.11i provides • Satisfactory data confidentiality & integrity with CCMP • Satisfactory mutual authentication & key management • Some implementation mistakes • Security Level Rollback Attack in TSN • Reflection Attack on the 4-Way Handshake • Availability is a problem • Simple policies can make 802.11i robust to some known DoS • Possible attack on Michael Countermeasures in TKIP • RSN IE Poisoning/Spoofing • 4-Way Handshake Blocking • Inefficient failure recovery scheme • Improved 802.11i