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" <>
To:
Bruce Rich/Austin/IBM@IBMUS, ""
<>
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:]
Sent: Friday, October 16, 2009 3:45 AM
To: Fitzgerald, Indra
Cc:
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"
<>
To:
Bruce Rich/Austin/IBM@IBMUS, ""
<>
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:]
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
