Re: [kmip] Specification clarification in regard to managed object retrieval

[Bruce Rich <brich@us.ibm.com>]

Saikat,

I agree that the spec is silent about
the consideration of the object's state relative to the Get operation,
and that we have exercised testcases (from the very beginning of the protocol)
that return a key's value despite its state.
(I would also point out that in the
errors for all operations and for the get operation in particular, there
is no reason listed that relates to "key in improper state for operation")
One of the reasons that the server can
get away with this is that we have no idea what the requesting client proposes
to do with the key material, so the server has "plausible deniability".

Since the obtaining of key material
is not what the NIST state model is about, but rather the usage of such
material, I would assert that this question becomes much more pertinent
for the newer cryptographic services addition to the spec.  Where
the server is performing an operation that is supposed to be modulated
by an object's state, then the server should consider the state of the
key and the request being processed and return an error if the request
and the state conflict.  (That's a part of the M in KMIP)  Hmm,
when I go to the spec, I see NO errors returned by any of the new cryptographic
services, so it seems we are missing some needed pieces to answer your
question in this new context.  Why no new error reasons from the new
operations?  I do not think the server has plausible deniability here.

Bruce A Rich
brich at-sign us dot ibm dot com




From:      
 "Saha, Saikat"
<Saikat.Saha@safenet-inc.com>
To:      
 "kmip@lists.oasis-open.org"
<kmip@lists.oasis-open.org>
Date:      
 06/27/2013 11:52 AM
Subject:    
   [kmip] Specification
clarification in regard to managed object retrieval
Sent by:    
   <kmip@lists.oasis-open.org>

---

KMIP Team,
 
Section 4.22 of the KMIP spec at http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html#_Toc333494539
doesn’t mention any state restrictions. It’s very unlikely this is an
oversight. More likely Get is allowed in any state.
 
The section 3.22 in the KMIP spec quoted
below says "Pre-Active: The object exists but is not yet usable for
any cryptographic purpose." Retrieving using Get is not a cryptographic
purpose so returning a pre-active key does not violate this. This is reinforced
by the text in test 4.1 which says “[being in the compromised state] does
not stop a client from being able to add, modify and delete attributes
or even get the key (since we assume here that the out-of-band registration
has been used to make the server aware of the fact that the client is capable
of interpreting the attributes of the key and determining what it is allowed
to do with the key).” Emphasis added by me. Therefore it appears it is
the client’s responsibility to determine what is allowed to be done with
the key based on the attributes returned by the KS/DS.
 
Test case 3.1.3 at http://docs.oasis-open.org/kmip/testcases/v1.1/cn01/kmip-testcases-v1.1-cn01.html#_Toc333488775
is titled “Test Case: Create / Locate / Get / Destroy”. That sequence
of commands is supposed to succeed. Requiring that the Activate command
or setting the Activation Date such that the key becomes Active before
the Get command is called would cause this test case to fail.
 
 
Given above, what is committee
members consensus of allowing the “Get” command to retrieve a “Pre-Active”
key or Secret Data object? 
 
One view is that precluding
Get from retrieving Pre-Active keys does appear to violate spec.
Other view is that
why would the KMIP server allow to retrieve a key that is in “Pre-active”
state. Some real-life customers have proposed that server should not allow
clients to retrieve an object in pre-active state.
 
Would appreciate some feedback
from the committee members. 
 
Regards,
Saikat

The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.