1. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 1 A Re-Key Proposal Albert Young 3Com Corporation Santa Clara, CA Albert_young@3com.com Bob OHara Black Storm Networks Palo Alto, CA

2. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 2 Re-key Proposal Described in 01/540r01 Not a stand-alone proposal –Uses re-key information element from 01/508 –Uses default key locations as described in 01/508

3. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 3 Objective Minimize frame exchanges required to re-key Does not require new MAC Management frame type Re-keying default and key mapping keys is done in the same fashion

4. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 4 Assumptions & Constraints Key sequence number is monotonically increasing and increments by a fixed value –Allows pre-calculation of the next temporal key –Simplifies key update synchronization

5. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 5 Re-keying a Key Mapping Key Key mapping relationship must pre-exist Re-key is initiated by frame with the Re-key information element –Can use a reassociation frame Enable sequence and transition sequence of 01/508 still exists –Merge enable sequence with transition sequence –Transition sequence to next key overlaps enable sequence of current key by 100% –Eliminates draining of pre-encrypted frames. This is an implementation, not protocol, issue

6. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 6 Re-key a Default Key Re-key information element is sent in Beacon frames, with countdown –New key becomes active when countdown reaches zero –Allows key updates over existing default key that is in use –Can still use ping pong method of 01/508 Less efficient usage of default keys Possibility exists for over use of a default key (2n frames encrypted, because of implicit invalidation

7. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 7 Response to Issues Raised. Increment key sequence value by 1 Assume that frames always arrive in order? Assumptions of queue packet ordering? Assumptions about the transitional key?

8. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 8 Key Sequence Number Fixed amount of keying material is derived from each key sequence number There may be some future requirement for more keying material than is available from a single key sequence number This proposal does not require incrementing the key sequence number by 1, but by a fixed value No limit on keying material

9. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 9 Order of Frame Arrival & Queue Packet Ordering Order of frame arrival is identical to order of frame transmission When a frame is encrypted is an implementation detail The protocol we describe may drive some implementation requirements, such as not pre- encrypting frames It is not a requirement of TGi that we enable all possible implementations, even those that require we design overly complex protocols

10. doc.:IEEE 802.11-01/540ar0 Submission November 2001 Albert Young, Bob OHara Slide 10 Transitional Key There is no transitional key Only one key is active for key mapping –No default key is used for transition Ping Pong default keys are not required –Can re-key over top of an existing key