1. Security Analysis and Improvements for IEEE 802.11i Changhua He, John C Mitchell Stanford University NDSS’05, Feb. 03, 2005

2. Outline  Wireless Threat Models  Possible threats and their practicality in wireless networks  IEEE 802.11i  Data Confidentiality & Integrity: CCMP  Mutual Authentication: RSNA Establishment Procedure  Availability: not an original design objective, problematic  Attacks and Solutions  On Authentication: Security level rollback, reflection attack  On Availability: Michael countermeasure attack, RSN IE poisoning, 4-Way Handshake blocking  Failure Recovery and improved 802.11i  Conclusions

3. 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

4. IEEE 802.11i  Ratified on June 24, 2004  Data confidentiality and integrity  Encryption in Link Layer  WEP: Wired Equivalent Privacy  TKIP: Temporal Key Integrity Protocol  CCMP: Counter-mode/CBC-MAC Protocol  Mutual authentication  RSNA: Robust Security Network Association  EAP-TLS/802.1X/RADIUS  Key management: 4-Way handshake, Group key handshake, etc.  Availability  not an original design objective  Some real vulnerabilities exist

5. 802.11i: Confidentiality & Integrity  With a fresh key, 802.11i CCMP is believed secure for confidentiality and integrity !  WEP, TKIP for backward compatibility  CCMP: long-term solution  AES: 128-bit key, 128-bit block, Counter mode + CBC-MAC  48-bit Packet Number for replay prevention  Use the same key for both Encryption and MIC  Counter and init. vector not overlap  better to use different key for different purpose

6. 802.11i: Mutual Authentication  RSNA Establishment Procedures  Network and Security Capability Discovery  802.11 Open System Authentication and Association  EAP/802.1X/RADIUS Authentication  4-Way Handshake  Group Key Handshake  Secure Data Communications  RSNA security analysis gives:  can provide satisfactory authentication and key management  could be problematic in Transient Security Networks (TSN)  reflection attack could be possible if not implemented correctly

7. Authentica- tion Server (RADIUS) No Key Authenticator UnAuth/UnAssoc 802.1X Blocked No Key Supplicant UnAuth/UnAssoc 802.1X Blocked No Key Supplicant Auth/Assoc 802.1X Blocked No Key Authenticator Auth/Assoc 802.1X Blocked No Key Authentica- tion Server (RADIUS) No Key 802.11 Association EAP/802.1X/RADIUS Authentication Supplicant Auth/Assoc 802.1X Blocked MSK Authenticator Auth/Assoc 802.1X Blocked No Key Authentica- tion Server (RADIUS) MSK Supplicant Auth/Assoc 802.1X Blocked PMK Authenticator Auth/Assoc 802.1X Blocked PMK Authentica- tion Server (RADIUS) No Key 4-Way Handshake Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key Group Key Handshake Supplicant Auth/Assoc 802.1X UnBlocked New GTK Authenticator Auth/Assoc 802.1X UnBlocked New GTK Authentica- tion Server (RADIUS) No Key RSNA Conversations Data Communication Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key

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

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

10. Security Rollback: solutions  Security Level Rollback Attack  Similar to general version-rollback attack  Destroy the security since WEP is completely insecure  Not a real vulnerability of 802.11i standard, but an implementation problem of TSN  Very possible mistake for transparency requirement  Solutions  Allow only RSNA connections: secure, but too strict for common network systems, where TSN is more convenient  Adopt both, supplicant manually choose to deny or accept a connection, authenticator restrict pre-RSNA (WEP) connections to only insensitive data

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

12. Reflection Attack: Solutions  Possible in ad hoc networks  Each participant plays the role of both authenticator and supplicant  Violate the mutual authentication concept  Less damage if strong confidentiality adopted  Adversary fool the peers to send packets  Cannot decrypt the packet and generate response  Solutions:  Restrict each participant to play only one role: ok for WLAN, but inappropriate for ad hoc networks  Each participant play both roles, but under different PMK

13. 802.11i: Availability  Not an original design objective  Physical Layer DoS attack  Inevitable but expensive and detectable  Network and upper Layer DoS attack  Depend on protocols, not our focus  Link Layer DoS attack  Flooding attack: could be detected and located  Some Known DoS attacks on 802.11 networks  DoS attack on Michael countermeasure in TKIP  RSN IE Poisoning/Spoofing  4-Way Handshake Blocking

14. 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

15. 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 MACIV/KeyID TKIP MPDU Format Ext. IVData/MSDUMICICVFCS Encrypted Contains TSC

16. 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

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

18. 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

19. 4-Way Handshake Blocking AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC PTK Derived Random GTK PTK and GTK 802.1X Unblocked PTK and GTK 802.1X Unblocked Supplicant Auth/Assoc 802.1X Blocked PMK Authenticator Auth/Assoc 802.1X Blocked PMK AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC AA, ANonce[1], sn, msg1 AA, ANonce[n], sn, msg1

20. 4-Way Blocking: Solutions  Random-Drop Queue: not so effective  Authenticate Message 1  Make use of the share PMK, but need to modify packet format  Re-use supplicant nonce  Supplicant re-use SNonce, eliminate memory DoS  Performance degradation, more computations in the supplicant  Combined solution:  Supplicant re-use SNonce  Store one entry of received ANonce and derived PTK  If ANonce in Message 3 matches the entry, use PTK directly; otherwise derive PTK from Message 3 and use it  Eliminate the attack, ensure performance in “friendly” scenarios, only minor modifications on the algorithm

21. 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

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

23. 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

24. Highlight Our Findings ATTACKSSOLUTIONS security rollbacksupplicant manually choose security; authenticator restrict pre-RSNA to only insensitive data. reflection attackeach participant plays the role of either authenti- cator or supplicant; if both, use different PMKs. attack on Michael countermeasures cease connections for a specific time instead of re-key and deauthentication; update TSC before MIC and after FCS, ICV are validated. RSN IE poisoningAuthenticate Beacon and Probe Response frame; Confirm RSN IE in an earlier stage; Relax the condition of RSN IE confirmation. 4-way handshake blocking adopt random-drop queue, not so effective; authenticate Message 1, packet format modified; re-use supplicant nonce, eliminate memory DoS.