RE: [kmip] Additional clarity around KMIP object owner

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

Hi Indra,

I'm not sure that replacing "certificate"
with "credentials specified during the authentication process"
is an improvement.  Since only SSL/TLS mutual authentication is permissible
(according to Profile section 3.1.3), that would imply that the only possible
credential is a certificate, according to my reading of the appropriate
RFCs (TLS 1.2 adds that it could be a PGP cert, otherwise it's got to be
X509v3).  Having thus narrowed the channel authentication, it seems
appropriate to speak of the only possible credential type, which is a certificate.
 I'd rather not force the reader to read all of the documents to be
able to understand any of them.

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

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

---

Hi Bruce,
 
The changes I proposed to the
Profiles document were supposed to provide additional clarification and
replace your original restrictive statements with more general ones. Your
proposed text (3.1.4) introduces the notion of interpreting the Credential
object, if provided, as the identity of the requestor and explicitly discusses
the Credential object and client certificate relationship. Note that the
Profiles document does not actually refer to client certificates and only
refers to channel level authentication. This was one of the things I removed
from your proposed text, referring to certificates only in the examples
I added to the Usage Guide.
If we allow servers to determine
the identity of the requestor using mechanisms that are outside the channel
level authentication, then we should explicitly point this out in the Profiles
document. As previously mentioned, it is essential that the identity of
the requestor is determined during the authentication process; including
this in the Profiles document will avoid confusion and potentially avoid
insecure implementations.
 
Regards,
Indra

---

From: Bruce Rich [mailto:brich@us.ibm.com]
Sent: Wednesday, October 21, 2009 10:46 AM
To: Fitzgerald, Indra
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] Additional clarity around KMIP object owner


Indra, 

Since the Usage Guide is illustrative and not normative, it is OK if it
illustrates some and not all of the possible usage patterns.  Therefore
it is not necessary that all the usages one has in mind are illustrated
in the Usage Guide.  My lack of disagreement with the use case that
you presented in the Usage Guide should be interpreted in those terms;
I do not disagree with a userid and password that relate to the client-provided
certificate.  I would disagree with credentials that MUST be so related.

Therefore I do object to the changes that you propose to sections 3.1.3
and 3.1.4 of the Profiles document.  Forcing the Credential into such
a tight relationship with the client certificate is a mistake.  The
existence of channel authentication greatly simplifies the issues of privacy,
integrity and authentication, and is wonderful for version 1.  Those
KMIP servers who want to enforce a tight relationship between the Credential
and the client certificate should be allowed to do so.  Those who
want to enable a richer authentication/authorization fabric on a v1 base
should also be allowed to do so.  Your language would overly constrain
such adopters. 

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/16/2009 08:27 PM
Subject:	RE: [kmip] Additional clarity around KMIP object owner

---

Hi Bruce,

I agree that it is essential to get normative protection for KMIP users. I am not suggesting for us to exclude the Credential structure. I just want to make sure that we fully understand the implication of including your proposed text and realize that this approach differs from what we previously agreed on. I also want to make sure that the documents are consistent.

Please see below for the changes I am proposing to the Client Authenticity section (3.1.3) in the Profiles spec, your proposed text, and the Authentication section in the Usage Guide (3.1). If anyone disagrees or would like to rewrite this, please chime in.

Regards,

Indra
Profiles spec:
3.1 3     Client Authenticity
Client authenticity is proven by the use of channel (SSL/TLS) level mutual authentication. Vendors MAY use the Credential object for passing additional identification information. This SHOULD NOT, however, be used as an alternative authentication mechanism to the chosen authentication set. If the Credential object is specified in the request and the identity of the requestor is provided in both the Credential object and during the channel level authentication, the KMIP server SHALL verify that the identities are the same. If they differ, the authentication fails and the server SHALL return an error. The actual mechanics of how the server ensures client authenticity is beyond the scope of this version of the specification.
 
The text proposed by Bruce (slightly modified):
3.1.4        Relationship between credential and object creator
KMIP objects have a creator.  The KMIP server SHALL interpret determine the identity of the requestor from the cCredentials object as the identity of the requestor if such a Credential is specified in the requestspecified during the authentication process. The authentication mechanism SHALL be one of the chosen authentication suites as specified in this Profiles specification.  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].
 
Paragraph from Section 3.1 of the Usage Guide
KMIP implementations that use other vendor-specific mechanisms for authentication may use the Credential attribute to include additional identification information. For example, in addition to performing mutual authentication during SSL/TLS, the client passes the Credential object in the request. If the client provides the username of the requestor in both the client certificate and the Credential object, the server verifies that the usernames are the same. If they differ, the authentication fails and the server returns an error. If the username is only specified in the Credential object, the server interprets the identity of the requestor from the Credential object. However, if this authentication option is not part of the chosen KMIP authentication suite, it should not be used to assert that an identity has been authenticated or be used as an alternative to the chosen KMIP authentication suite.
 

---

From: Bruce Rich [mailto:brich@us.ibm.com]
Sent: Friday, October 16, 2009 3:45 AM
To: Fitzgerald, Indra
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] Additional clarity around KMIP object owner


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