60 likes | 76 Views
A Simple Rekeying Proposal. Dmitri Varsanofiev Resonext Communications San Jose, CA dmitri@varsanofiev.com. Rekeying Proposal. Goals Eliminate the synchronization exchange at the MAC level Handle the session keys and default keys in a uniform manner. Rekeying Proposal: Idea.
E N D
A Simple Rekeying Proposal Dmitri Varsanofiev Resonext Communications San Jose, CA dmitri@varsanofiev.com Dmitri Varsanofiev
Rekeying Proposal • Goals • Eliminate the synchronization exchange at the MAC level • Handle the session keys and default keys in a uniform manner Dmitri Varsanofiev
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 Dmitri Varsanofiev
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 Dmitri Varsanofiev
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 Dmitri Varsanofiev
Rekeying Proposal • Inspired by Young / O’Hara’s 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 Dmitri Varsanofiev