1 / 68

Authenticated Key Exchange

Authenticated Key Exchange. Nancy Cam-Winget, Atheros Greg Chesson, Atheros Russ Housley, RSA Labs Jesse Walker, Intel. Agenda. Motivation, Constraints, and Requirements Protocol Definition Protocol Analysis Summary and Next Steps. Why?. This work was motivated by 4 problems:

luella
Download Presentation

Authenticated Key Exchange

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. Authenticated Key Exchange Nancy Cam-Winget, Atheros Greg Chesson, Atheros Russ Housley, RSA Labs Jesse Walker, Intel Cam-Winget, Chesson, Housley, Walker

  2. Agenda • Motivation, Constraints, and Requirements • Protocol Definition • Protocol Analysis • Summary and Next Steps Cam-Winget, Chesson, Housley, Walker

  3. Why? This work was motivated by 4 problems: • Session Management • Race Conditions • Roaming and key hand-off • WEP “rapid rekeying” Cam-Winget, Chesson, Housley, Walker

  4. Problem 1: Session Management (1) • 802.11 security model doesn’t include the notion of a secure session • 802.11 security either is on (there is a configured key) or off • Nothing similar to station authentication, association services • Proper cipher suite operation requires not only synchronized key, but also synchronized sequence spaces and replay windows • TGi security will not “work” until this is fixed! • A broken TGi draft cannot pass sponsor ballot! Cam-Winget, Chesson, Housley, Walker

  5. Problem 1: Session Management (2) • TGi Draft 1 attempts to rectify the lack of a security session implicitly • Glues security onto the association service • This attempt is unsatisfactory • Political: What to do in an IBSS? Reality is many implementations do not support associations in IBSS! • Usability: Reassociation too heavy-weight just to update keys and sequence numbers, because reassociation interrupts the data flow. • Technical: association service manages link characteristics, not security characteristics Cam-Winget, Chesson, Housley, Walker

  6. Problem 1: Session Management (3) Potential Solutions: • Continue with draft 1 model • requires (Re)association in an IBSS. Straw poll of membership indicates substantial up-hill battle  questionable whether we can get this past letter ballot • Doesn’t address usability problem of poor performance • Build a new session management mechanism independent of association • Must work in an IBSS, i.e., without association • Must support frequent state resynchronization where policy dictates without degrading performance Cam-Winget, Chesson, Housley, Walker

  7. Problem 2: Race Conditions (1) • TGi Security uses 802.1X for master key establishment • 802.1X traffic appears as 802.11 data • in-band communication • Standard problem with in-band key distribution schemes: sender of last message cannot know with certainty whether it was delivered correctly and consumed Cam-Winget, Chesson, Housley, Walker

  8. Last Key Distribution Message Access Point Wireless Station Problem 2: Race Conditions (2) After key established, both STA and AP must enforce key usage: in the clear data must be discarded as spoof Dilemma for last message sender of in-band key distribution: enforce key usage? Or allow retransmissions? Sender can’t resolve dilemma if its peer doesn’t guarantee to use distributed key! Cam-Winget, Chesson, Housley, Walker

  9. Problem 2: Race Conditions (3) Potential solutions to the race conditions: • Ignore them • Requires the STA to reinitialize whenever this occurs • Inexcusable in a standard • Expose 802.11 internals to 802.1X • Requires reopening 802.1X specification, and inserting 802.11 specific knowledge into them • Increase inter-dependence of 802.11 and 802.1X • Inadvisable in a standard • Develop new out-of-band key synchronization Cam-Winget, Chesson, Housley, Walker

  10. Problem 3: Roaming and Key Handoff (1) • TGi wants to use 802.1X for authentication • Secure authentication in the 802.11 environment very expensive • Must be public key based: EAP-TLS, EAP-SRP • This requires too much overhead to do a full authentication on a roam • Consensus is leaning toward a solution of replacing full authentication with some sort of TGi/TGf key hand-off mechanism Cam-Winget, Chesson, Housley, Walker

  11. Old Access Point New Access Point Legitimate Wireless Station 2. Legitimate Station’s WEP key Reassociate 1. Problem 3: Roaming and Key Handoff (2) 3. Delete key from old AP Cam-Winget, Chesson, Housley, Walker

  12. 4. Delete key from old AP Old Access Point New Access Point Legitimate Station 3. Legitimate Station’s WEP key Associate Reassociate Rogue Station 1. 2. Problem 3: Roaming and Key Handoff (3) Problem Summary: new AP doesn’t know STA is authentic Cam-Winget, Chesson, Housley, Walker

  13. Old Access Point Rogue Access Point Legitimate Station 3. Data flow protected by old key, IV space 2. Associate Reassociate 1. Problem 3: Roaming and Key Handoff (4) Problem Summary: STA doesn’t know new AP is live and authentic Cam-Winget, Chesson, Housley, Walker

  14. Problem 3: Roaming and Key Handoff (5) • Key hand-off requires a mutual reauthentication • But reauthentication must be light-weight • Authenticated exchange is required at MAC, because we can’t assume 802.1X (think of static keys, proprietary authentication protocols, etc.) • Potential Solutions: • Ignore the problem • Hand it to 802.1X or TGf for solution • Introduce a light-weight (symmetric key) mutual authentication mechanism at the MAC Cam-Winget, Chesson, Housley, Walker

  15. Problem 4: WEP Rapid Rekeying • WEP IV space too small • Small IV space enables IV reuse attacks • Rekey mechanism required to avoid these • Fluhrer-Mantin-Shamir type attacks • Relies on observing enough packets to derive key • Can’t rekeying more rapidly help? • Not as much as people would like, but some sort of rekeying is needed for any solution Cam-Winget, Chesson, Housley, Walker

  16. Motivation Summary • Most urgent justification for MAC rekey protocol is security session management • Correctness says we need a MAC-level handshake to avoid race conditions when using 802.1X • Compelling long term justification for MAC level rekey also includes providing support for roaming • Short-term WEP rapid rekey the least compelling reason to develop a MAC-level rekey protocol—and it is important enough by itself to seek a solution Cam-Winget, Chesson, Housley, Walker

  17. Requirements (1) • Protocol must address the motivations • Synchronize and manage cryptographic state • Simplify interface with 802.1X to avoid race condition • Support roaming and key handoff • Provide rapid rekey • Protocol must work within existing security design • Security architecture must work with WEP keying scheme (KeyIDs, key-mapping keys, default keys) • Must work in both BSS and IBSS Cam-Winget, Chesson, Housley, Walker

  18. Requirements (2) • Protocol exchanges must be secure • Must assure liveness: no replayed sessions • Prevent rogue AP or STA from replaying earlier sessions that would reuse cryptographic state • Protocol messages must be authentic • Protocol must minimize packet loss • Must not change WEP, but must not preclude changes, either • Cipher suite independence: must work with WEP enhancements and with long term AES solution Cam-Winget, Chesson, Housley, Walker

  19. Constraints • Existing WEP design • Key namespace limitations • Key-mapping and Default keys • Minimizing packet loss (synchronizing distributed state) • Rekey Security Cam-Winget, Chesson, Housley, Walker

  20. Constraint 1: Key Namespace Limitations • 802.11 WEP keys are identified by the two WEP KeyID bits • Each WEP KeyID identifies a full-duplex key • To be backward compatible, key identified by a single KeyID must be switched simultaneously at peers Cam-Winget, Chesson, Housley, Walker

  21. Data exchange, protected by old KeyID key Communicate intent replace old key with new key On confirmation, replace old key with new key; re-enable traffic Acknowledge intent Data exchange, protected by new KeyID key Half-Duplex Key Rollover (Not WEP) A B Decide to replace old key with new key; halt traffic Cam-Winget, Chesson, Housley, Walker

  22. Observations on Full-Duplex Rekey Algorithms • Full-duplex rekey can be constructed from two half-duplex rekey exchanges  4 message total! • If same key identifier used for each half-duplex flow, the two exchanges have to be coordinated. • The 4 message handshake can be reduced to 3 messages with proper coordination, but not 2 messages. Expect a 3 message transition from old key to new key Cam-Winget, Chesson, Housley, Walker

  23. Constraint 2: Key-mapping Keys and Default Keys • Terminology • Key-mapping keys the 802.11 name for per-link keys • Default keys the 802.11 name for group keys • Must support both types • All members of a group must switch group key simultaneously  some sort of broadcast or timer-based scheme must be used for key roll-over • But doesn’t scale well to per-link keys • Key roll-over requires explicit key naming  explicit message exchange required to roll-over of per-link keys • But doesn’t scale well to group keys Expect different techniques for key-map and default keys Cam-Winget, Chesson, Housley, Walker

  24. Constraint 3: Synchronize Distributed State (1) • Problem: How to reliably synchronize WEP KeyID roll-over from old key to new? • Solution must be reliable, because communication fails absolutely if cryptographic state become unsynchronized • Solution: solved by theory of database concurrency control long ago: atomic commit, 2-phase commit, 3-phase commit, etc. Cam-Winget, Chesson, Housley, Walker

  25. Constraint 3: Synchronize Distributed State (2) • Atomic Commit Properties • 1 message exchange, but • A single failure blocks every participant • 2-phase commit properties • 2 message exchanges • First exchange tells what change to make • Second exchange makes change permanent • Separation of change and commit allows for more robust failure recovery options if one party can’t execute entire protocol Cam-Winget, Chesson, Housley, Walker

  26. Constraint 3: Application to WEP KeyIDs • Atomic Commit • No way to coordinate allocation, release of transitional KeyID • Only recovery vehicle is to restart entire link • 2-phase Commit • Phase 1 failure delays rekey, doesn’t destroy channel • Phase 1 success allows Phase 2 by reserving transitional KeyID • Phase 2 failure destroys channel, but is less likely because resources (KeyIDs) allocated by Phase 1 Expect a 2-phase commit from old key to new key Cam-Winget, Chesson, Housley, Walker

  27. Constraint 4: Secure Session Establishment • Protocol must guarantee • Live peers • Fresh uniformly distributed keys • Freedom from message modification, replay Cam-Winget, Chesson, Housley, Walker

  28. A securely learns B’s notion of time T IDA,IDB,R,T, MIC(IDA,IDB,R,T) IDA,IDB,RA IDB,RB , MIC(IDB,RB) IDA,RA IDB,IdA,RA,RB,MIC(IDB,IDA,RA,RB) IDB,IDA RA,RB,MIC(IDB,IDA,RA,RB) IDB,IDA RB IDA,IDB,R, MIC(IDA,IDB,R) IDA,IDB,RB,RA, MIC(IDA,IDB,RB,RA) Constraint 4: Protocols to Ensure Liveness A B A B A B Lacks flexibility: A and B must know which role to play; only A can initiate; how does B signal it needs to restart? Most expensive but only solution with sufficient flexibility Nice paradigm—only 2 messages—but how to securely distribute B’s notion of time? Expect initialization based on 2 2-way handshakes Cam-Winget, Chesson, Housley, Walker

  29. Constraint 4: Fresh Uniformly Distributed Keys • Encryption key refresh • Add entropy to master key • Guards from exhaustion of replay protection sequence • Resynchronize cryptographic state on roam • Rekey of master keys • Encryption Key entropy is also finite • Rekey of master keys can be achieved via reauthentication (802.1X) Expect key hierarchy based on key derivation Cam-Winget, Chesson, Housley, Walker

  30. Constraint 4: Freedom from Forgery, Replay • Protocol messages • Must have MIC • Must convey session-specific data established at session start-up • Must have sequence number Cam-Winget, Chesson, Housley, Walker

  31. Constraint Summary • WEP key naming architecture forces at least a 3 message handshake to effect key roll-over using a message-based approach • Rekey for default and key-map keys will differ • 2-phase commit architecture leads to more robust behavior than an atomic commit architecture • A secure protocol that allows any party to initiate rekey favors two 2-way handshakes over its alternatives • Key hierarchy will maximize master key mileage Cam-Winget, Chesson, Housley, Walker

  32. Agenda • Motivation, Constraints, and Requirements • Protocol Definition • Protocol Analysis • Summary and Next Steps Cam-Winget, Chesson, Housley, Walker

  33. Proposed Security Service • Fundamental data structure is security association • Security association = secure session • New rekey protocol to construct and manage security associations • 802.11 cipher suites applied only within security associations Cam-Winget, Chesson, Housley, Walker

  34. Invalid Secure Session Invalid Secure Session Invalid Secure Session Invalid Secure Session Authenticated Key Exchange Authenticated Key Exchange State 6: Authenticated, Associated, Secure Invalid Secure Session Security as a STA Service ULAP Authentication State 1: State 4: Unauthenticated, Unauthenticated, Unassociated, Associated, Successful Disassociation Deauthentication Authentication Notification Notification State 5: State 2: ULA authenticated, Authenticated, Associated, Unassociated, Deauthentication Disassociation Notification Notification State 3: Authenticated, Associated, Cam-Winget, Chesson, Housley, Walker

  35. Service Operation • Once established, Security Association enforces cipher suite usage • Protection based on temporal keys • All plaintext packets and packets with unknown keyids discarded • Security Association forces rekey when • Packet sequence space crosses a low-water mark for a key-mapping key • Rekey timer expires for a default key • Security Association establishment, rekey based on Rekey Messages Cam-Winget, Chesson, Housley, Walker

  36. Keys • Proposed key hierarchy defined as: • Master Key: acquired from ULA • Base Key: derived from Master Key • Temporal Key: derived from Base Key • Rationale for key hierarchy • Allows precomputation of temporal keys without compromising security • Guards against master key collisions Cam-Winget, Chesson, Housley, Walker

  37. Key Hierarchy Cam-Winget, Chesson, Housley, Walker

  38. Deriving Keys • Master Key is 256 bits • 1st 128 bits to be used to derive base encryption key (MEK) • 2nd 128 bits used as authentication key (MAK) • Base Key in message-based case: • Key-mapping Key Base Key ::= AES-CBC-MACMEK (MAC1 || MAC2 || Nonce1 || Nonce2 || Cipher-Suite) • Default Key Base Key ::= AES-CBC-MACMEK ( BSSID || Beacon-Nonce || Cipher-Suite) • Temporal Key:Cipher-suite specific • Basic idea is to use counter mode AES to generate as much keying material as required Cam-Winget, Chesson, Housley, Walker

  39. Rekey Info Element Beacon Body Duration Nonce Cipher Suite Version Number Key Seq Number KeyID Rekey Count Rekey Period MIC Frame Control Frame Control Frame Control Seq Control Frame Control Frame Control Seq Control Frame Control Frame Control SA DA SA DA BSSID FCS FCS BSSID Action frame header Rekey Info Element Duration Rekey messages Beacon Frame Action Mgmt Frame Cam-Winget, Chesson, Housley, Walker

  40. Nonce Cipher Suite Version Number Key Seq Number KeyID Rekey Count Rekey Period MIC Rekey Information Element All messages include the common Rekey Information Element Nonce: 16-byte message initiator’s nonce Cipher Suite: Selected algorithms for privacy and integrity protocol Version Number: this protocol’s version identifier Key Seq Number: Index to temporal key, also temporal key identifier KeyID: Index (0, 1, 2, or 3) into transitional key buffer Rekey Count: Number of beacons before next key refresh Rekey Period: Number of beacon intervals between key refreshes MIC: 1st 64 bits of AES-CBC-MACauth-key(DA || SA || BSSID || Nonce || Cipher suite || Version Number || Key Seq # || KeyID || Rekey Count || Rekey Period) Cam-Winget, Chesson, Housley, Walker

  41. Establishing a Security Association PeerB PeerA Security Association Request Security Association Request Security Association Response Security Association Response • Each peer initiates its own Security Association sequences to ensure liveness • Provides mutual authentication to securely establish security association • Security association identified by matching nonces Cam-Winget, Chesson, Housley, Walker

  42. Terminating a Security Association • 802.11 Deauthentication • Dissassociation • Association • Reassociation • Rekey failure Cam-Winget, Chesson, Housley, Walker

  43. Rekey Architecture 2-phase commit protocol • Enable exchange • Deadline for deriving new temporal key Ki • Reserves transitional key id to identify new key • Transition exchange • Fully enables new temporal key Ki • Obsoletes old temporal key Ki-1 • Releases transitional key id Timers or messages can trigger exchanges Cam-Winget, Chesson, Housley, Walker

  44. New keyKi use keyIDx Ki New keyKi use keyIDx Ki New keyKi use keyIDx Ki Enable Request Enable Response Transition Request Obsolete Ki-1 Queue flushed keyIDx Ki Obsolete Ki-1 Queue flushed keyIDx Ki Obsolete Ki-1 Queue flushed keyIDTA/DA Ki Transition Response Transition Confirm keyIDTA/DA Ki keyIDx not used keyIDTA/DA Ki keyIDx not used Rekey Concept Key-mapping Keys Default Keys Rekey Interval Enable Exchange New keyKi use keyIDx Ki Not Applicable Rekey Beacon Obsolete Ki-1 Queue flushed keyIDy Ki Transition Exchange Not Applicable keyIDy Ki keyIDx not used Not Applicable keyIDy Ki keyIDx not used Cam-Winget, Chesson, Housley, Walker

  45. Enable Request : keyIDx Ki New keyKi ready to Prepare to use keyIDx Ki New keyKi ready to recieve using keyIDx Ki Enable Response: Acknowledges request, proves liveness and synchronization Ki Both peers ready to start sending and receiving with new keyIDx Key-Mapping Keys Enable • Enable exchange triggers the rekey • Reserves transitional KeyID to identify new key • Either STA or AP can initiate the exchange • Optimization: STA can initiate by sending Enable Response • Session nonce, key sequence value, MIC prove liveness Cam-Winget, Chesson, Housley, Walker

  46. No more packets using old key, flush queue KeyTA/DA Ki ready to send using KeyTA/DA Transition Request: Trigger to obsolete old KeyTA/DA Ready to send and receive with KeyTA/DA Ki keyIDTA/RA Ki keyIDx not used keyIDTA/DA Ki keyIDx not used Transition Response: Acknowledges request, proves liveness and KeyTA/DA Ki Transition Confirm: Release use of keyIDx, proves liveness and KeyTA/DA Ki Key-Mapping Keys Transition • AP initiates Transition Request to control reserved KeyID usage • AP sends Request when old key packets have been flushed • Transition Request, Response are promises never to send with old key • Session nonce, key sequence value, MIC prove liveness • Optimization: Transition Confirm not needed if STA never sent using transitional KeyID Cam-Winget, Chesson, Housley, Walker

  47. New key must be derived between Rekey Beacon intervals New keyKi ready to send using keyIDx Ki New keyKi ready to receive using keyIDx Ki Not Applicable: no response sent Both peers ready to start sending and receiving with new keyIDx Default Keys Enable • No messages used; timer based on TSFT triggers enable (refreshed with every beacon) • Rekey Beacon provides information to synchronize key and next interval • Requires adding MIC, nonce to the Beacon Cam-Winget, Chesson, Housley, Walker

  48. No more packets using old key, KeyIDy Ki ready to send using KeyIDy Ready to send and receive with Keyy Ki Rekey Beacon frame triggers to use new key, Ki in keyIDx Not Applicable: no response sent Both peers now using Ki Default Keys Transition • Switch keys at Rekey Beacon interval timeout – this timeout is the “handshake” • New key identified by next KeyID before next Rekey Beacon • Ping-pong between two KeyIDs • Since no messages, keys cannot be explicitly obsoleted, so KeyIDs have to be reserved for duration of security association • Per-packet MIC required to make the scheme to be secure Cam-Winget, Chesson, Housley, Walker

  49. Agenda • Motivation, Constraints, and Requirements • Protocol Definition • Protocol Analysis • Summary and Next Steps Cam-Winget, Chesson, Housley, Walker

  50. Protocol Analysis • Security Properties • Performance Characteristics • Breaking the Race Condition • Potential Roaming Support • Implementation Considerations Cam-Winget, Chesson, Housley, Walker

More Related