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
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
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
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