doc.:IEEE /636r1 Submission November 2001 Dmitri Varsanofiev Slide 1 A Simple Rekeying Proposal Dmitri Varsanofiev Resonext Communications San Jose, CA

doc.:IEEE /636r1 Submission November 2001 Dmitri Varsanofiev Slide 2 Rekeying Proposal Goals –Eliminate the synchronization exchange at the MAC level –Handle the per-link keys and multicast keys in a uniform manner

doc.:IEEE /636r1 Submission November 2001 Dmitri Varsanofiev Slide 3 Rekeying Proposal: Idea Temporary key is derived based on a master key and a nonce Rekeying is synchronized using the nonce broadcasted in the clear in each beacon To avoid the packet loss during rekeying, two keys are used. Rekeying moments for the two keys are different. Stations avoid using the key that is about to be changed All stations are rekeyed simultaneously Two nonces are transmitted with the corresponding key IDs: the current one and the next one as well as the number of beacon intervals before a key change.

doc.:IEEE /636r1 Submission November 2001 Dmitri Varsanofiev Slide 4 Rekeying Proposal: Assumptions Master key setup is done using means outside of the scope of this proposal (Upper Layer Authentication) Rekeying is infrequent (once per so many minutes) Rekeying is done using a temporary key which is a function of a master key and a nonce. Nonce and key derivation for temporary key are outside of the scope of this proposal. For example, the formula for base_shared_key in the 01/508 can be used

doc.:IEEE /636r1 Submission November 2001 Dmitri Varsanofiev Slide 5 Beacon Information Element Patterned after the Rekey Information Element in 01/508 Includes –Current Nonce –Current Key ID –Next Nonce –Next Key ID –Key Sequence Number –Cipher Suite –Rekey Count –MIC

doc.:IEEE /636r1 Submission November 2001 Dmitri Varsanofiev Slide 6 Rekeying Proposal: Drawbacks The rekeying is based on the station that was the first to exhaust the IVs. AP has to derive keys for all associated stations each time – more calculations needed than in the case of individual rekeying of each station. Two key IDs are needed (can be relaxed)

doc.:IEEE /636r1 Submission November 2001 Dmitri Varsanofiev Slide 7 Rekeying Proposal Inspired by Young / OHaras proposal 01/540 Not a stand-alone proposal –Uses re-key information element similar to 01/508 Possible modifications –Use just one key ID. May require re-encryption of few packets during the key switch time, if they would fall into a different beacon interval than planned. Alternatively, packets encrypted both with the old and new key can be always transmitted during the predetermined overlap period. –Transmit nonces only along with DTIM information –Broadcast two nonces at a time; one for each direction