OASIS Key Management Interoperability Protocol (KMIP) TC

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

On 19/12/2014 12:50 PM, John Leiseboer wrote: > 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. It doesn't contradict itself at all - something you appear to also be agreeing with in your choice of wording with the use of "appears" and "sort of". Summarising the context: 1) There can be one or two unique identifiers provided in the request - it is a YES-may-be-repeated parameter. 2) The derivation data can be provided either via a unique identifier referencing a secret data item (one of those provide in the request) or by direct value. The two statements are themselves not contradictory and the combination makes it clear that you can only use derivation data when you are using a derivation mechanism that is referencing a unique identifier - that provides for both statements to remain true and not be contradictory. That there is an alternate way of sometimes specifying derivation data doesn't override that one or more unique identifiers are always required. The "Yes, unless the Unique Identifier of a Secret Data object is provided" could be reworded to "Yes, but only when the Unique Identifier of a Secret Data object has not been provided" but without adding something like "and don't forget this doesn't override all the other statements within this section" there remains (as always) opportunities to creatively misread the specification (by ignoring the clear statements). The whole concept with this operation (which I've raised multiple times before could do with a pile of test cases and additional vendor implementation) is that it is always operating on a managed object and it produced a managed object as the result of the operation. I'd also like to note that you have argued passionately against the concept of operations which don't referenced managed objects on multiple occasions and it seems to me at least that you've shifted to a different view (in this context). I've also previously mentioned that Table 156 and 155 (using the references in the current TC approved version of the KMIP 1.2 - the CS version) should be listed as one table with the last two items as required for PBKDF2 and not permitted for the other values - but that is more of a style issue in terms of how different variations of the same structure should be handled. Elsewhere we have defined it once and listed the variations inline. Also thinking back to the TC meeting this week - you stated your context for hitting this item was that of PKCS#11 itself and your mapping across to KMIP - and the C_DeriveKey operation there always mandates a reference to an object handle within PKCS#11 - so in that context you always have a unique identifier (equivalent) mapping. Tim.