1 / 12

KMIP Stream and Asynchronous Delivery Enhancements for V1.2

KMIP Stream and Asynchronous Delivery Enhancements for V1.2. John Leiseboer, QuintessenceLabs KMIP Face to Face, September 2012. QKD: Distributed RNG for KMS. QKD. Key Stream Use Case. Periodic Delivery of Keys. Definitions. Key Stream

iain
Download Presentation

KMIP Stream and Asynchronous Delivery Enhancements for V1.2

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. KMIP Stream and Asynchronous Delivery Enhancements for V1.2 John Leiseboer, QuintessenceLabs KMIP Face to Face, September 2012

  2. QKD: Distributed RNG for KMS QKD

  3. Key Stream Use Case

  4. Periodic Delivery of Keys

  5. Definitions • Key Stream • Variable length, including “infinite” length, random stream of bits • Can be used as random, one-time pad key material, or universal hash based MAC key • Usually associated with two KMIP clients, but may be associated with any number (one or more) • Usually destroyed on server after delivery

  6. Definitions • Asynchronously Delivered Key • Any managed cryptographic object that is pushed from a server to a client • Can be associated with one or more clients • Usually delivered periodically with a new value

  7. 1. Implications for V1.2 • Does Register operation with key value make sense? • Probably not for stream • How would you register an infinite length key stream? • Possibly for asynchronous delivery • Need to somehow link sequences of keys together • One UID for all keys? • A sequence UID? • Issues with high frequency of registration?

  8. 2. Implications for V1.2 • Mutable or immutable cryptographic objects? • Each “fragment” of a stream is different • One UID for the stream, or one for each fragment? • Different clients sharing a common key stream may consume different fragment sizes • UID per fragment will not work • Asynchronously delivered keys • Just a quantised stream! • Continuous-discrete duality (just like wave-particle!)

  9. 3. Implications for V1.2 • Asynchronous delivery • Server pushes object to clients • Who initiates the connection, client or server? • High frequency vs. low frequency delivery • High frequency (e.g. >10 keys per second) - stay connected • Low frequency (e.g. once every two years) • Client attributes • Network address • Client authentication • An entity? • Registration?

  10. 4. Implications for V1.2 • Stream clients • One protect client • None, one (can be same as protect), or more process clients • Who initiates the connection? • Stay connected until stream terminates • Stream exhaustion • “Terminate” command • Not Revoke • Not Destroy • New command: Deactivate? • Collection of subscribers to a stream • Client group • Group of related entities

  11. 5. Implications for V1.2 • Initiating delivery • Client activates (or “primes the server ” for) delivery • For stream: • Each client, or • One client on behalf of all in the “group”? • Client initiated connection: Poll? • Server initiated connection: unsolicited Response? • Client can specify fragment length, and offset • Can offset wrap? • It must for an infinite length stream • Does it matter? • Offset from last received fragment? • Can only be positive • Limits

  12. 6. Implications for V1.2 • Stream delivery • Simply packaged random bits • Length of this fragment • Offset from start of stream or last received fragment • Can offset wrap? • Does it matter? • The stream

More Related