1 / 36

802.11i Wireless Networking Authentication Protocol

CS 259. 802.11i Wireless Networking Authentication Protocol. J. Mitchell. Next few lectures. Tuesday 1/17 Brief cryptography background Key exchange protocols and properties Today 1/19

jayme-buckley
Télécharger la présentation

802.11i Wireless Networking Authentication Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related