Get Random Proposal John Leiseboer 11 October 2012

Desirable Features Minimal changes to KMIP Supports single “chunk”, and streaming random Can share same random amongst several clients Server can push random to clients Same model of operation as other proposed crypto operations (encrypt, sign, MAC, etc.)

Object or Operation? Cryptographic Operations Objects… – Objects that perform cryptographic operations Random, Encipher, Decipher, Sign, SignVerify, MAC, MACVerify, Hash – Consistent with OO programming Data fields: KMIP attributes Methods: KMIP operations

Random Object Object Type – Random Attributes – UID, Name, RNGAlgorithm, EntropyQuality, Offset, Length, others TBD Operations – Create, Locate, Get, Destroy, Notify, Put

Usage Client requests server to Create a Random Object – UID returned – Name attributes can be assigned to Random Object – Placeholder ID works for batch operations Client locates Random Object by Name Client gets Random Object bytes specifying Offset and Length – Get operation can be called more than once to read a stream of random bytes from the Random Object Client destroys Random Object Multiple clients can get (share) the same random stream

Test Case Outline Create (Random) – In: objectType=Random, attributes={Name={NameValue=’RNDStream1’,NameType=X}, RNGAlgorithm=X, EntropyQuality=X} – Out: objectType=Random, UID Locate (Random) – In: attributes={objectType=Random, Name={NameValue=’RNDStream1’,NameType=X}} – Out: UID Get (Random) – In: UID, attributes={Offset=X, Length=X} – Out: objectType=Random, UID, Random Destroy (Random) – In: UID

Simple, Single Chunk Operation For simple, single chunk operations – Client can send a batched request Create Get Destroy

Streaming Operation For streaming operation – The client can issue individual requests Create Get... Destroy

Sharing a Stream Clients (out of band) communicate information that identifies the shared stream – UID – Name, or other attributes that work with Locate Each client sends its own Get requests Only one client should Create and Destroy – Others can only Get

Discussion – KMIP Object Model What is "the model" for KMIP objects? Recent mutability discussion is relevant This proposal clearly models objects as mutable Also introduces the notion of Objects performing operations Standard does specify an Object model – Several different, incompatible interpretations are possible – One interpretation is that all objects are static and immutable – Another interpretation is that objects can be mutable and can perform operations Like OO programming models of objects

Discussion – Simple to Share Simple means to share Random/Key streams Each random stream can be identified by a UID, or a name – Very easy for cooperating clients to access the same stream The UID, or Name can be shared out of band by clients No new object type, or new attribute needed to enable sharing of Random/Key material

Discussion – Easy to Stream Streaming operations easily supported The alternative proposal is limited to single chunk operation – Does not support streaming operations (init, update, update,..., final), as supported in almost all crypto products and libraries Streaming mode of operation works very naturally with this proposal – Create functions as "init"; Get functions as "update"; and Destroy can function as "final"

Discussion – Easy Single Chunk Single chunk, one-off operation supported using batch Falls out very naturally from the current KMIP standard If only a single chunk crypto operation is to be performed, it can be done as a sequence of Create/Get/Destroy in a single batched set of requests

Discussion – Push to Client Notify and Put – Possibly some more thought needed, but… – Notify and Put should work with very little change with this model Notify Example – As new Random is generated, Notify messages can be sent by the server to registered clients to indicate that the Random Object's attribute(s) have changed – A simple Get by the client in response to a Notify will return the next Offset/Length chunk of random Put Example – As new random is produced, the server can send a Put message to registered clients – The Put object would retain the UID of the Random Object – Consider a new attribute called "update" rather than either of the current attributes (“new” and “replace”)

Summary Easily allows sharing of random/key streams (and sharing of cipher streams) using UID or Name Supports the mutability side of the Template debate – Can stop the debate with a compelling reason for selecting one side over the other Supports encipher, decipher, sign, etc. stream operations Works with Notify (no change) and Put (with addition of Update attribute) Is compatible with almost all OO paradigms – And matches usage models of currently deployed cryptographic products Requires little change to the existing KMIP specification – Where changes (mostly additions) are made, they fit in very naturally with the current standard – Reuses existing features of the standard wherever possible; e.g. Templates, Create, Get, Locate, Destroy, Notify and Put operations, batched operations using Placeholder ID, etc.