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:]
Sent: Wednesday, October 14, 2009 6:02 PM
To:
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:
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
