Post on 27-Mar-2015
November 2001
Albert Young, Bob O’HaraSlide 1
doc.:IEEE 802.11-01/540ar0
Submission
A Re-Key ProposalA Re-Key Proposal
Albert Young3Com Corporation
Santa Clara, CAAlbert_young@3com.com
Bob O’HaraBlack Storm Networks
Palo Alto, CA
November 2001
Albert Young, Bob O’HaraSlide 2
doc.:IEEE 802.11-01/540ar0
Submission
Re-key ProposalRe-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
November 2001
Albert Young, Bob O’HaraSlide 3
doc.:IEEE 802.11-01/540ar0
Submission
ObjectiveObjective
• 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
November 2001
Albert Young, Bob O’HaraSlide 4
doc.:IEEE 802.11-01/540ar0
Submission
Assumptions & ConstraintsAssumptions & 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
November 2001
Albert Young, Bob O’HaraSlide 5
doc.:IEEE 802.11-01/540ar0
Submission
Re-keying a Key Mapping KeyRe-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
November 2001
Albert Young, Bob O’HaraSlide 6
doc.:IEEE 802.11-01/540ar0
Submission
Re-key a Default KeyRe-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
November 2001
Albert Young, Bob O’HaraSlide 7
doc.:IEEE 802.11-01/540ar0
Submission
Response to Issues Raised.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?
November 2001
Albert Young, Bob O’HaraSlide 8
doc.:IEEE 802.11-01/540ar0
Submission
Key Sequence NumberKey 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
November 2001
Albert Young, Bob O’HaraSlide 9
doc.:IEEE 802.11-01/540ar0
Submission
Order of Frame Arrival & Queue Packet Order of Frame Arrival & Queue Packet OrderingOrdering
• 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
November 2001
Albert Young, Bob O’HaraSlide 10
doc.:IEEE 802.11-01/540ar0
Submission
Transitional KeyTransitional 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