1. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 1 Authenticated Key Exchange Nancy Cam-Winget, Atheros Greg Chesson, Atheros Russ Housley, RSA Labs Jesse Walker, Intel

2. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 2 Agenda Motivation, Constraints, and Requirements Protocol Definition Protocol Analysis Summary and Next Steps

3. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 3 Why? This work was motivated by 4 problems: Session Management Race Conditions Roaming and key hand-off WEP “rapid rekeying”

4. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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!

5. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

6. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

7. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

8. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 8 Problem 2: Race Conditions (2) Access Point Wireless Station Last Key Distribution Message 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!

9. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

10. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

11. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 11 Problem 3: Roaming and Key Handoff (2) Old Access Point Legitimate Wireless Station New Access Point Reassociate 1. 2. Legitimate Station’s WEP key 3. Delete key from old AP

12. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 12 Problem 3: Roaming and Key Handoff (3) Old Access Point Legitimate Station New Access Point Associate 1. Rogue Station Reassociate 2. 3. Legitimate Station’s WEP key 4. Delete key from old AP Problem Summary: new AP doesn’t know STA is authentic

13. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 13 Problem 3: Roaming and Key Handoff (4) Old Access Point Legitimate Station Associate 1. Rogue Access Point Reassociate 2. 3. Data flow protected by old key, IV space Problem Summary: STA doesn’t know new AP is live and authentic

14. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

15. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

16. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

17. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

18. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

19. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 19 Constraints Existing WEP design –Key namespace limitations –Key-mapping and Default keys Minimizing packet loss (synchronizing distributed state) Rekey Security

20. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

21. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 21 Half-Duplex Key Rollover (Not WEP) AB Data exchange, protected by old KeyID key Decide to replace old key with new key; halt traffic On confirmation, replace old key with new key; re-enable traffic Communicate intent Acknowledge intent replace old key with new key Data exchange, protected by new KeyID key

22. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

23. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

24. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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.

25. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

26. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

27. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 27 Constraint 4: Secure Session Establishment Protocol must guarantee –Live peers –Fresh uniformly distributed keys –Freedom from message modification, replay

28. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 28 Constraint 4: Protocols to Ensure Liveness ABABAB A securely learns B’s notion of time T ID A,ID B,R,T, MIC(ID A,ID B,R,T) ID A,ID B,R, MIC(ID A,ID B,R) Nice paradigm—only 2 messages—but how to securely distribute B’s notion of time? ID A,R A ID B,ID A R A,R B,MIC(ID B,ID A,R A,R B ) ID B,R B, MIC(ID B,R B ) Lacks flexibility: A and B must know which role to play; only A can initiate; how does B signal it needs to restart? ID A,ID B,R A ID B,Id A,R A,R B,MIC(ID B,ID A,R A,R B ) ID B,ID A R B ID A,ID B,R B,R A, MIC(ID A,ID B,R B,R A ) Most expensive but only solution with sufficient flexibility Expect initialization based on 2 2-way handshakes

29. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

30. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

31. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

32. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 32 Agenda Motivation, Constraints, and Requirements Protocol Definition Protocol Analysis Summary and Next Steps

33. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

34. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 34 Security as a STA Service State 1: Unauthenticated, Unassociated, State 2: Authenticated, Unassociated, State 3: Authenticated, Associated, State 4: Unauthenticated, Associated, Deauthentication Notification Disassociation Notification Successful Authentication Deauthentication Notification ULAP Authentication State 5: ULA authenticated, Associated, Invalid Secure Session Authenticated Key Exchange Authenticated Key Exchange State 6: Authenticated, Associated, Secure Disassociation Notification

35. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

36. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 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

37. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 37 Key Hierarchy

38. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 38 Deriving Keys Master Key is 256 bits –1 st 128 bits to be used to derive base encryption key (MEK) –2 nd 128 bits used as authentication key (MAK) Base Key in message-based case: –Key-mapping Key Base Key ::= AES-CBC-MAC MEK (MAC1 || MAC2 || Nonce1 || Nonce2 || Cipher-Suite) –Default Key Base Key ::= AES-CBC-MAC MEK ( 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

39. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 39 Rekey messages Duration Frame Control Frame Control SADA Frame Control BSSID Frame Control Seq Control FCS Rekey Info Element Beacon Body Action Mgmt Frame Beacon Frame Key Seq Number KeyID Rekey Count MIC Cipher Suite Nonce Rekey Period Version Number Duration Frame Control Frame Control SADA BSSID Frame Control Seq Control FCS Rekey Info Element Action frame header

40. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 40 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-MAC auth-key ( DA || SA || BSSID || Nonce || Cipher suite || Version Number || Key Seq # || KeyID || Rekey Count || Rekey Period ) Key Seq Number KeyID Rekey Count MIC Cipher Suite Nonce Rekey Period Version Number

41. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 41 Establishing a Security Association Peer A Peer B Security Association Request 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 Security Association Response

42. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 42 Terminating a Security Association 802.11 Deauthentication Dissassociation Association Reassociation Rekey failure

43. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 43 Rekey Architecture 2-phase commit protocol 1.Enable exchange Deadline for deriving new temporal key K i Reserves transitional key id to identify new key 2.Transition exchange Fully enables new temporal key K i Obsoletes old temporal key K i-1 Releases transitional key id Timers or messages can trigger exchanges

44. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 44 Rekey Concept Enable Exchange New key  K i use keyID x  K i Obsolete K i-1 Queue flushed keyID x  K i keyID TA/DA  K i keyID x not used Enable Request Enable Response Transition Request Transition Response Obsolete K i-1 Queue flushed keyID TA/DA  K i keyID x not used New key  K i use keyID x  K i Transition Confirm Transition Exchange New key  K i use keyID x  K i Obsolete K i-1 Queue flushed keyID x  K i keyID y  K i keyID x not used Rekey Interval Not Applicable Rekey Beacon Obsolete K i-1 Queue flushed keyID y  K i keyID x not used New key  K i use keyID x  K i Not Applicable Key-mapping KeysDefault Keys

45. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 45 Key-Mapping Keys Enable New key  K i ready to Prepare to use keyID x  K i Enable Response: Acknowledges request, proves liveness and synchronization K i Both peers ready to start sending and receiving with new keyID x 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 Enable Request : keyID x  K i New key  K i ready to recieve using keyID x  K i

46. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 46 Key-Mapping Keys Transition No more packets using old key, flush queue Key TA/DA  K i ready to send using Key TA/DA Ready to send and receive with Key TA/DA  K i Transition Request: Trigger to obsolete old Key TA/DA 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 Transition Response: Acknowledges request, proves liveness and Key TA/DA  K i keyID TA/RA  K i keyID x not used keyID TA/DA  K i keyID x not used Transition Confirm: Release use of keyID x, proves liveness and Key TA/DA  K i

47. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 47 Default Keys Enable New key  K i ready to send using keyID x  K i Not Applicable: no response sent Both peers ready to start sending and receiving with new keyID x 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 New key  K i ready to receive using keyID x  K i New key must be derived between Rekey Beacon intervals

48. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 48 Default Keys Transition No more packets using old key, KeyID y  K i ready to send using KeyID y Rekey Beacon frame triggers to use new key, K i in keyID x Ready to send and receive with Key y  K i Not Applicable: no response sent Both peers now using K i 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

49. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 49 Agenda Motivation, Constraints, and Requirements Protocol Definition Protocol Analysis Summary and Next Steps

50. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 50 Protocol Analysis Security Properties Performance Characteristics Breaking the Race Condition Potential Roaming Support Implementation Considerations

51. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 51 Security Properties: Protocol Ensures Liveness AB Each party randomly selects nonce Its peer must MIC the nonce  peer is alive Nonces in each pair of handshakes must match  common notion of a live session IDs (MAC addresses) tie the exchange to these two peers Note: MIC must include Beacon Nonce in default key case ID A,ID B,R A ID b,Id a,R A,R B, MIC(ID b,ID a,R A,R B ) ID b,ID a R B, ID A,ID B,R B,R A, MIC(ID A,ID B,R B,R A )

52. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 52 Security Properties: Chain of Trust We trust Master Key because it comes from ULA We trust Base Key, because authenticated Security Association exchange shows it is derived from (fresh) Master Key We trust Temporal Key, because it is derived from fresh Base key by authenticated Enable/Transition exchange We trust data packets, because its keys derived from trusted Temporal Key –This assumes a per-packet MIC and replay protection

53. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 53 Key Refresh Performance Key-mapping Key Requires 3 to 5 messages Adjusts to packet rate Number of rekeys governed by the channel bandwidth, not number of STAs Allows graceful key transitions while minimizing queue flushing Default Key Rekey information element must be present in every beacon Requires one rekey element per default key Must rekey at absolute maximum packet rate, or data halts when sequence space is exhausted No transition period

54. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 54 Rekey Frequency (TCP)

55. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 55 Rekey Frequency (UDP)

56. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 56 Performance Analysis Message-based rekeys on average packet rate –11Mbps / 500b/pkt  1900 pkts/sec – @65536 pkts  34 sec –3 to 5 msgs every 34 sec Countdown-scheme must rekey on absolute max packet rate –11Mpbs / 48b/pkt  5200 pkts/sec –@65536 pkts  12.5 sec –@ n beacons/sec and 1 rekey element per key in beacon

57. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 57 Countdown vs Message-based message ratio per rekey interval Using a 65536 packet rekey frequency for Message-based scheme

58. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 58 Rekey Rate vs. Bandwidth Using a 65536 packet rekey frequency for Message-based scheme

59. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 59 Breaking the Race Condition Security Association exchange cannot complete unless 802.1X succeeds at distributing master key to both parties Security Association exchange does not block 802.1X retries Rekey protocol exchanges do not suffer from same race conditions because they use a separate channel –Management messages instead of Data messages

60. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 60 Potential for Roaming Support Old Access Point Legitimate Wireless Station New Access Point Reassociate 1. 2. Legitimate Station’s WEP key 3. Security Association Exchange 4. Delete key from old AP

61. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 61 Implementation Considerations (1) Requires Rekey Information Element –Needed for positive key synchronization (key-mapping key case) –Controls rekey time interval (default key case) –Provides key identities in both cases –Messages required to establish first temporal key (for both shared and per-link key types) Message-based method scales –Multiplex arbitrary number of enable sequences in parallel –Rapid dispatch for transition sequences

62. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 62 Implementation Considerations (2) Count-down scheme requires adding Rekey Information Element to Beacon Security of Count-Down Scheme also requires TSFT to be MIC’d –The value of the Beacon TSFT is not known until Beacon is passed to the PHY  interesting implementation problem ESS-wide default key attractive for multicast/broadcast –But STA’s can’t trust any message as authentic until establishing security association with sender

63. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 63 Implementation Considerations (3) Proposals defines one new management frame type for TGi –Cloned from TGe action frame –Extend ability of TGi to update security parameters including rekeying –Protocol requires 7 action opcodes; the rest should be reserved for future use

64. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 64 Implementation Considerations (4) No changes needed to cipher engines –But not precluded –But does restrict their use to within an SA context No dependence on external authentication service –But not precluded Protocol security depends on introducing MIC into Disassociation, Deauthentication messages –Use the master authentication key for this –It will also need the session nonce(s)

65. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 65 Agenda Motivation, Constraints, and Requirements Protocol Definition Protocol Analysis Summary and Next Steps

66. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 66 Summary Proposed rekey protocol –Provides solution to all its motivating problems –Is the simplest correct solution possible given the problem requirements and constraints –Provides robust security and performance for both key-mapping keys and default keys –Supports both short-term and long-term cipher suite proposals

67. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 67 Next Steps 1.Finish review of state machines 2.Reissue doc 11-01-573 with reviewed state machines 3.Converge protocol with TGi/TGf key hand-off scheme 4.Adopt text from doc 11-01-573 as TGi draft

68. doc.: IEEE 802.11-00/573a Submission November 2001 Cam-Winget, Chesson, Housley, WalkerSlide 68 Discussion