RE: [kmip] KMIP Spec v1.2 wd05: Multiple Cryptographic Parameters for a Single Key

[John Leiseboer <JL@quintessencelabs.com>]

I think I have a solution for the Multiple Cryptographic Parameters issue.

The heart of the issue is how to interpret "multiple instances permitted". These are all potential interpretations:

1. The key can be used with any one or all of the defined parameters
2. The key should be used with only one of the defined parameters
3. Both interpretations 1 and 2
4. It's okay to ignore the defined parameters, KMIP can't enforce what implementations do anyway

Some examples may make this clearer:

Assume that we have a key on the server with two Cryptographic Parameters instances defined. Instance 1 has Block Cipher Mode set to ECB. Instance 2 has Block Cipher Mode set to CBC.

Interpretation 1 now means: the key MAY be used in ECB *AND* CBC modes, and SHOULD NOT be used in other modes; i.e. a client can perform cryptographic operations with the same key in both ECB and CBC modes. Clients make the decision. Using a key this way is insecure, but the "AND" interpretation allows this.

Interpretation 2 now means: the key MAY be used in ECB *OR* CBC mode, SHOULD NOT be used in both modes, and SHOULD NOT be used in other modes; i.e. clients decide which of the two allowed modes will be used, and then they stick with that mode. Using a key this way is secure (in the sense that mixed modes are not used).

Interpretation 3 now means: the key MAY be used in ECB AND/OR CBC mode, but SHOULD NOT be used in any other mode; i.e. clients decide between them whether interpretation 1, interpretation 2 or both should be used. Using a key this way can be insecure, and makes interoperability more difficult.

Interpretation 4 means: it doesn't matter what the Cryptographic Parameters are, it's okay for an implementation to ignore them and do whatever it wants. A better way to support this is to not define any Cryptographic Parameters at all. This would make it clear to all that there are no intended restrictions or guidelines for use of Cryptographic Parameters.

None of the interpretations guarantees security, nor guarantees that a client will use the key in the way that the attributes indicate it should be used. This is true for all sorts of attributes, not just Cryptographic Parameters; e.g. an expired lease time doesn't require a client to renew a lease; a 256-bit AES key can be used with 128-bit AES, DES or RC4 ciphers; a key marked for encryption only, can be used for decryption.

I think that interpretation 2 is the one that we should encourage in the standard. On reflection, this seems the interpretation that would have most likely been intended when v1.0 of the standard was written. It provides the flexibility of choice to use whatever Cryptographic Parameters are defined, but at the same time encourages a secure use.

It makes sense that an enterprise policy may limit, for example, the allowed modes of operation to a small set. It makes sense, that this policy is encoded as a set of Cryptographic Parameters. It makes sense too, that secure implementations are desirable. These all lead to interpretation 2. Of course, implementers intent on building insecure applications can ignore the policy implicitly encoded in the attributes and do their own thing anyway, but this does not mean that we should not provide guidance or clarify intent to users of KMIP.

If we agree that interpretation 2 is the one we'd like to adopt, then I think the minimum required change is to explain interpretation 2 in the Usage Guide. I would prefer to see some words added to Section 3.6 of the standard as well, but I'm happy to accept the consensus of the group. Of course, the most secure change to the standard would be to disallow multiple instances of Cryptographic Parameters. Ultimately I would prefer this, but I can accept interpretation 2 if the TC doesn't want to go "all the way".

Does anyone else have an opinion on this?

John

----------------------------------------------------------------------
John Leiseboer                          QuintessenceLabs Pty Ltd
Chief technology Officer                Suite 23, Physics Building #38
Phone:  +61 7 5494 9291 (Qld)           Science Road
Phone:  +61 2 6125 9498 (ACT)           Australian National University
Mobile: +61 409 487 510                 Acton ACT 0200
Fax:    +61 2 6125 7180                 AUSTRALIA
Email:  JL@quintessencelabs.com         www.quintessencelabs.com
----------------------------------------------------------------------