OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]