Derive Key Operation

[John Leiseboer <JL@quintessencelabs.com>]

The KMIP standard states that the Derive Key operation must always pass a the UID of a symmetric key or secret data object for key derivation as a parameter in the request message. This appears to conflict with the intent of the operation which also describes a Derivation Data field that can be passed and used for key derivation.

The standard should be changed or clarified to reflect how Derive Key should be used.

More detail follows.

All paragraph and table numbers below are from kmip-spec-v1.1-csprd02.doc. I don't think that there are substantial differences in content for other versions.

"4.6 Derive Key 
This request is used to derive a symmetric key or Secret Data object from a key or secret data that is already known to the key management system."

This says that a new key is derived from an existing key or secret data object; i.e. that a new key cannot be derived solely from derivation data passed in the request.

Table 138, Request payload supports the above interpretation:

"Object: Unique Identifier, see 3.1
Required: Yes. MAY be repeated
Description: Determines the object or objects to be used to derive a new key. At most, two identifiers MAY be specified: one for the derivation key and another for the secret data. Note that the current value of the ID Placeholder SHALL NOT be used in place of a Unique Identifier in this operation."

Table 138 also specifies that Derivation Parameters must be provided. Derivation Parameters defined in table 140 are for all derivation methods except PBKDF2. Derivation parameters for PBKDF2 are specified in table 141.

Both tables 140, and 141 specify Derivation Data as follows:

"Object: Derivation Data
Encoding: Byte String
Required: Yes, unless the Unique Identifier of a Secret Data object is provided."

Other derivation methods may have similar issues, but let's just use PBKDF2 as an example...

Assume that I want to derive a key using PBKDF2 from a password. Currently, the specification requires that the password already be registered as a Secret Data object, and that the UID of this object be passed in the request (table 138).

If this is the case, then what is the purpose of the Derivation Data field in table 141? And why does it say that derivation data is required UNLESS the UID of a secret data object is provided? This appears to support the notion that PBKDF2 can be used to derive a key from the Derivation Data if a Secret Data object UID is NOT passed in the request. But this conflicts with table 138.

From a practical point of view, I see no reason to REQUIRE that a Secret Data object be registered on the server in order to use PBKDF2 to derive a key. The standard clearly states that this is required, but then it appears to contradict itself - sort of - in tables 140 and 141 when describing the Derivation Data field.

So either we should allow the UID to be optional in the request, or we should clarify what the Derivation Data field's purpose is for each derivation method, or remove it (at least for PBKDF2).

John

John Leiseboer | Chief Technology Officer | QuintessenceLabs | W: quintessencelabs.com
E: jl@quintessencelabs.com | M(AU): +61 409 487 510 | M(US): +1 202 294 6825 | Skype: jleiseboer
AU: 15 Denison St | Deakin | ACT 2601 | T: +61 2 6260 4922
US: Suite 220 | 175 Bernal Road | San Jose CA 95119 | T: +1 650 870 9920