RE: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf)uploaded

["Fitzgerald, Indra" <indra.fitzgerald@hp.com>]

Hi Tim,

I am not suggesting to remove the authentication structure from KMIP nor am I prohibiting the use cases you mention below. I am only addressing the case where the identity is specified in both the certificate and the credential structure. What you are suggesting can be achieved by not specifying the client identity in the certificate and using the credential structure to identify the client. We had several discussions on this topic and, as mentioned below, added the clarification in Section 3.1 of the Usage Guide.

-Indra 

-----Original Message-----
From: Tim Hudson [mailto:tjh@cryptsoft.com] 
Sent: Thursday, May 19, 2011 6:57 PM
To: Fitzgerald, Indra
Cc: david.black@emc.com; Bob.Nixon@Emulex.Com; kmip@lists.oasis-open.org; cds@cisco.com
Subject: Re: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded

On 20/05/2011 3:50 AM, Fitzgerald, Indra wrote:
> Hi David,
> 
> Thanks for the clarification. I agree that we do not want to allow this type of attack. If we specify the client identity in the certificate and specify additional credential information in the Authentication structure, the server should verify that the identities match.
> We are aware of this concern and have addressed this in the KMIP Usage Guide (section 3.1). The TC is currently working on a related proposal where we can further address this issue.

I disagree - in that the mutual authentication at that level is representing a
link level connection - i.e. system to system - and the finer level of details
in terms of the specifics of the particular request are left to the handling in
the authentication credentials encoded.

It is entirely up to the server as to what it handles in this context if it has
information which is different.

The argument expressed is basically taking a position that the credentials
structure should be removed from KMIP (if it can never differ then why include
it at all) and that I don't think that would gain the support of the TC.

It is perfectly reasonable to have a host based mutually authenticated
connection with finer grained control offered using the existing
username+password authentication inside KMIP. In fact that's how a whole range
of existing (non-KMIP) key management products actually operate today.

It's not unreasonable in certain contexts to not allow that level of flexibility
- but that's a per-organisation per-context decision to be made and not
something which should be wired into KMIP.

KMIP has to address the full range of possible key management contexts - and
it's one of the reasons why substantial items are left to 'server policy' to
handle the specifics.

Tim Hudson
tjh@cryptsoft.com

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php