1 / 10

A Re-Key Proposal

This proposal aims to minimize frame exchanges required to re-key key mapping and default keys, without requiring a new MAC management frame type. It utilizes the re-key information element from 01/508 and follows the default key locations described in 01/508.

madger
Download Presentation

A Re-Key Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Re-Key Proposal Albert Young 3Com Corporation Santa Clara, CA Albert_young@3com.com Bob O’Hara Black Storm Networks Palo Alto, CA Albert Young, Bob O’Hara

  2. Re-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 Albert Young, Bob O’Hara

  3. Objective • 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 Albert Young, Bob O’Hara

  4. Assumptions & 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 Albert Young, Bob O’Hara

  5. Re-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 Albert Young, Bob O’Hara

  6. Re-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 Albert Young, Bob O’Hara

  7. 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? Albert Young, Bob O’Hara

  8. Key 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 Albert Young, Bob O’Hara

  9. Order of Frame Arrival & Queue Packet Ordering • 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 Albert Young, Bob O’Hara

  10. Transitional 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 Albert Young, Bob O’Hara

More Related