[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Additional clarity around KMIP object owner
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 |
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: | "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 |
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/Austin/IBM@IBMUS |
To: | kmip@lists.oasis-open.org |
Date: | 10/14/2009 12:51 PM |
Subject: | [kmip] Additional clarity around KMIP object owner |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]