RE: [kmip] Additional clarity around KMIP object owner

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

Indra,

I believe that specifying the protection
that KMIP servers will offer their users is important enough to specify
in normative text.  That said, the focus of KMIP v1 is mainly on the
protocol for information exchange, not the set of allowable mechanisms
for protecting such information in transit, nor the identity proof mechanisms
between endpoints.  The challenge is to find a mechanism for protection
and proof that offers adequate safeguards, yet leaves some maneuvering
room to allow multiple possible usecases.  The troika of mutual channel
authentication via SSL/TLS, a Credential structure in the request header
and an operational policy name promise made by the server is the set of
things that must work together to codify the protection that KMIP servers
will offer their users.  I think that in the absence of a Credential
structure in the request (and the concomitant  usage of the peer certificate
from the channel binding), if the KMIP server says that the OperationalPolicyName
for an object that it created/registered is "default", then the
KMIP user has a decent understanding of the protections that will be provided.
 The rub comes when the KMIP user chooses to also pass a Credential
structure on the request.  As you point out, the Usage Guide would
suggest a relationship between the certificate on the binding to the credential
on the request somehow, perhaps to further constrain the certificate usage.
 I believe the presence of a credential in the request should open
up a new set of usecases, not further constrain things (just as an OperationalPolicyName
other than "default" opens up new possibilities).  My change
was to clearly define a mechanism to allow the KMIP user to constrain KMIP
server behavior (by omitting the Credential).  The language used had
the effect of also loosening it on the other hand (if the KMIP user chooses
a credential not related to that supplied on channel binding).  My
main focus was on getting normative protection for KMIP users.  At
the time I proposed the text, I did not realize that the Usage Guide had
language that spoke so clearly in the opposite direction, so now we will
have to work this out.  Unfortunately, I will only be intermittently
connected over the next week and a half, so I will not be able to be very
responsive.

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

From:	"Fitzgerald, Indra" <indra.fitzgerald@hp.com>
To:	Bruce Rich/Austin/IBM@IBMUS, "kmip@lists.oasis-open.org" <kmip@lists.oasis-open.org>
Date:	10/15/2009 04:15 PM
Subject:	RE: [kmip] Additional clarity around KMIP object owner

---

Bruce and all,

In the Usage Guide, we currently address the case where clients may include the Credential attribute as additional identification information. We explicitly point out that if the Credential attribute is not part of the chosen authentication suite, the Credential attribute cannot be used to assert that an identity has been authenticated.

Similarly, the profiles spec explicitly points out that the Credential object may be used to pass additional identification information. This should not, however, be used as an alternative authentication mechanism.

Bruce's proposal allows the Credential object to be used to interpret the identity of the requestor. If a Credential object is not specified the certificate shall be used as the identity of the requestor.

There appears to be a disconnect. We cannot use the Credential object as the primary source for interpreting the identity of the requestor, if the Credential object is not part of the authentication suite. The authentication process will determine and authenticate the identity of the requestor. Decoupling the authentication and identity interpretation process could potentially weaken the security of the authentication process and restrict certain use-cases. For example, clients may provide the username inside the certificate and provide additional identification information inside the credential object. According to Bruce's proposal, the identity specified inside the certificate will not be acknowledged if the credential object contains a different username.

To resolve this, we need to explicitly allow the Credential object to be used during the authentication of the requestor. Depending on the server's configuration, this may or may not be required by the server. If both the certificate and Credential object contain the identity of the requestor, the server shall verify that they are the same. If they differ, the authentication fails and the server shall return an error.

We also need to update the KMIP docs (i.e. the profiles spec and Usage Guide) to make sure that they are consistent.

Regards,

Indra

---

From: Bruce Rich [mailto:brich@us.ibm.com]
Sent: Wednesday, October 14, 2009 6:02 PM
To: kmip@lists.oasis-open.org
Subject: Fw: [kmip] Additional clarity around KMIP object owner


It's been pointed out that the spec uses the term "creator" rather
than "owner" (thanks, Steve and Marko), so better text might
be: 

3.1.4        Relationship between credential and object
creator 
KMIP objects have a creator.  The KMIP server SHALL interpret the
Credential object as the identity of the requestor if such a Credential
is specified in the request.  If a Credential object is not specified,
KMIP SHALL use the certificate passed in the channel binding (or some unique
value derived from the certificate or its components) as the identity of
the requestor.  For those KMIP requests that result in new managed
objects this identity SHALL be used as the creator of the managed object.
 For those operations that only access pre-existent managed objects,
this identity SHALL be checked against the creator, and access SHALL be
controlled as detailed in section 3.13 of [KMIP]. 

And I'll refrain from talking the "creator endowed with certain unalienable
rights...", but I really wanted to slip that in there somewhere.

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

----- Forwarded by Bruce Rich/Austin/IBM on 10/14/2009 07:52 PM -----

From:	Bruce Rich/Austin/IBM@IBMUS
To:	kmip@lists.oasis-open.org
Date:	10/14/2009 12:51 PM
Subject:	[kmip] Additional clarity around KMIP object owner

---

Although we've clarified KMIP client/server authentication in the KMIP
Profiles document, I think the concept of "owner of KMIP object"
needs to be tied a bit more tightly to the authentication.

I propose this language be added as section 3.1.4 in the Profiles doc:

3.1.4        Object Ownership 
KMIP objects have an owner.  The KMIP server SHALL interpret the Credential
object as the identity of the requestor if such a Credential is specified
in the request.  If a Credential object is not specified, KMIP SHALL
use the certificate passed in the channel binding (or some unique value
derived from the certificate or its components) as the identity of the
requestor.  For those KMIP requests that result in new managed objects
this identity SHALL be used as the owner of the managed object.  For
those operations that only access pre-existent managed objects, this identity
SHALL be checked against the owner, and access SHALL be controlled as detailed
in section 3.13 of [KMIP].


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