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

[<Larry.Hofer@Emulex.Com>]

Hi David,

Good point. My train of thought was about keeping the barrier to entry low for clients. It would be nice, from a client's view to avoid the cost of developing or using non-open source. However, the open source work doesn't seem to be picking up standards all that quickly.

If the key management companies, for example, are willing to provide the changes, it might make it better for client implementations to keep cost/work down.

That was my train of thought, anyway. 

Whatever the server vendors think is best I am ok with.

Cheers,
Larry H, CISSP, PE

-----Original Message-----
From: david.black@emc.com [mailto:david.black@emc.com] 
Sent: Friday, May 20, 2011 11:31 AM
To: Hofer, Larry; indra.fitzgerald@hp.com; tjh@cryptsoft.com
Cc: Nixon, Bob; kmip@lists.oasis-open.org; cds@cisco.com; david.black@emc.com
Subject: RE: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded

> I have a question about the certificates aspect. Since many implementations may rely on open source
> code checking of certificates, it may be reasonable to avoid that tie in?

Why?  There are plenty of examples of use of open source code in commercial products that contain
significant non-open-source, and non-open-source code for certificate handling is readily available.

Thanks,
--David


> -----Original Message-----
> From: Larry.Hofer@Emulex.Com [mailto:Larry.Hofer@Emulex.Com]
> Sent: Friday, May 20, 2011 12:21 PM
> To: indra.fitzgerald@hp.com; tjh@cryptsoft.com
> Cc: Black, David; Bob.Nixon@Emulex.Com; kmip@lists.oasis-open.org; cds@cisco.com;
> Larry.Hofer@Emulex.Com
> Subject: RE: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded
> 
> I have a question about the certificates aspect. Since many implementations may rely on open source
> code checking of certificates, it may be reasonable to avoid that tie in? Tim may have an opinion on
> this. Perhaps Indra's suggestion avoids that, which seems like it could make it easier to implement.
> And it may be just as secure, although I did not look at the details.
> 
> My 2 cents,
> Larry H
> 
> -----Original Message-----
> From: Fitzgerald, Indra [mailto:indra.fitzgerald@hp.com]
> Sent: Thursday, May 19, 2011 9:20 PM
> To: Tim Hudson
> Cc: david.black@emc.com; Nixon, Bob; kmip@lists.oasis-open.org; cds@cisco.com
> Subject: RE: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded
> 
> 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