1. doc.:IEEE 802.11-01/636r0 Submission November 2001 Dmitri Varsanofiev Slide 1 A Simple Rekeying Proposal Dmitri Varsanofiev Resonext Communications San Jose, CA dmitri@varsanofiev.com

2. doc.:IEEE 802.11-01/636r0 Submission November 2001 Dmitri Varsanofiev Slide 2 Rekeying Proposal Goals –Eliminate the synchronization exchange at the MAC level –Handle the session keys and default keys in a uniform manner

3. doc.:IEEE 802.11-01/636r0 Submission November 2001 Dmitri Varsanofiev Slide 3 Rekeying Proposal: Idea Temporary key is derived based on a shared key and a nonce, just as in ??? Rekeying is synchronized using the nonce broadcasted in each beacon To avoid the packet loss during rekeying, two keys are used. Rekeying times for the two keys are different. Station avoids using the key that is about to be changed All stations are rekeyed simultaneously Two nonces are transmitted in the clear along with the corresponding key IDs: the current one and the next one as well as the number of beacon intervals before a key change. Nonces and key IDs are protected using a MIC

4. doc.:IEEE 802.11-01/636r0 Submission November 2001 Dmitri Varsanofiev Slide 4 Rekeying Proposal: Assumptions Shared key setup is done using means outside of the scope of this proposal (say, 802.1X) Rekeying is infrequent (once per many minutes) Rekeying is done using a temporary key which is a function of a shared key and a nonce. Nonce and key derivation for temporary key are outside of the scope of this proposal

5. doc.:IEEE 802.11-01/636r0 Submission November 2001 Dmitri Varsanofiev Slide 5 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 used for each station

6. doc.:IEEE 802.11-01/636r0 Submission November 2001 Dmitri Varsanofiev Slide 6 Rekeying Proposal Inspired by Young / OHaras proposal Not a stand-alone proposal –Uses re-key information element from 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. –Transmit nonces only along with DTIM information –Broadcast two nonces at a time; one for each direction