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

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. 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 802.11i Protocol Data Communication Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key

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 Probe Request Supplicant RSNA enabled Pre-RSNA enabled Authenticator RSNA enabled Pre-RSNA enabled 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

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 {A2, Nonce2, RSN IE, sn, msg2, MIC} {A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {A1, sn+1, msg4, MIC} Legitimate Devices Authenticator and Supplicant Bogus Authentication Peers 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}

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

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

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 Authenticator Auth/Assoc 802.1X Blocked PMK Authentica- tion Server (RADIUS) No Key The 4-Way Handshake 802.11 AssociationEAP/802.1X/RADIUS Authentication Group Key Handshake Data Communication MSK {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} Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key

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  Mur j 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. Simplified 4-Way Handshake 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

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. Forged Message 1 Attack 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, sn, msg1

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 FlowComplex Flow

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

35. Vulnerability Summary 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.

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