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