KMIP 1.2 d01 comments - RNG Seed & Retrieve

Hi OASIS,

Comment on KMIP v1.2 draft 01 (2014-01-09):

1. RNG Seed

The “RNG Seed” operation looks useful, but it is potentially very dangerous if not implemented carefully. It must not allow one KMIP client to reset the entire state of a pseudo-random number generator that other KMIP clients are relying on for secure randomness. A KMIP server providing random bytes to one client must not assume that seeds provided by other clients actually provided any entropy.

The text needs to explicitly state that the operation must only add entropy to a RNG. The given seed needs to be mixed into any existing RNG state, not replace it. The mixing needs to be done in a cryptographically safe manner that preserves any existing entropy in the RNG state.

Suggested change to the first sentence of section 4.36 RNG Seed:

FROM: “This operation requests the server to seed a Random Number Generator.”

TO: “This operation requests the server to add entropy to a Random Number Generator by mixing a seed in to the state of the RNG. Mixing in the seed SHALL NOT replace any existing entropy.”

Suggested change to the description in table 216 RNG Seed request Payload:

FROM: “The data to be provided as a seed to the random number generator.”

TO: “An entropy source to be mixed into the state of the random number generator.”

I would be tempted not to use the word “seed” as it has the connotation of being the complete starting state, which is so dangerous in the context of this KMIP operation. Perhaps “RNG Add Entropy” operation would be a better name, and “entropy source” as a name for the data in the request.

It would be worthwhile referencing RFC 4086 “Randomness Requirements for Security” http://tools.ietf.org/html/rfc4086.

It can be time-consuming to collect good randomness. A KMIP server using a pseudo-random number generator probably keeps a estimate of how much entropy has been gathered so far so it knows how much more it needs to collect (which determines how long it has to wait) before giving a cryptographically-strong random output. If a client calls RNG Seed then the same client calls RNG Retrieve, it might be reasonable for the KMIP server to count the seed towards the entropy (though there is no good way for the server to estimate the entropy in any given seed). In contrast, a KMIP server must not count any entropy from a seed if a different client calls RNG Retrieve — unless there is some (unmentioned) trust relationship between the clients.

2. RNG Retrieve

The “RNG Retrieve” operation makes no statement about the quality of output from the RNG. Presumably the unstated assumption is that the output is “crypto-quality” randomness, eg 128 bits of entropy at an absolute minimum. My guess is that a KMIP server would delay responding to a RNG Retrieve request until it had gathered enough entropy. Should the KMIP server assume that the minimum required entropy for the RNG state is the amount of random bits being requested in any particular “RNG Retrieve” request?

Suggested addition to the first paragraph of section 4.35 “RNG Retrieve”:

ADD: “The output SHALL be suitable for cryptographic uses.”

James Manger

kmip-comment message