OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] Additional clarity around KMIP object owner



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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]