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

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

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.

Thanks,
Indra

-----Original Message-----
From: david.black@emc.com [mailto:david.black@emc.com] 
Sent: Thursday, May 19, 2011 7:49 AM
To: Bob.Nixon@Emulex.Com; Fitzgerald, Indra
Cc: 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

> Also, depending on the client registration proposal, this behavior should not be required. The
> Authentication Credential could simply point to the Transport Certificate.
> 
> bn>     If I understood him, T11’s favorite security systems expert expressed strong feeling that
> use of the Authentication Header was a serious vulnerability. On the other hand, ignoring one
> when present seemed to me to risk interoperability failures. Thus, I chose to forbid them. I’ll
> leave that open for further input, but I would need David Black’s tolerance, if not enthusiasm,
> for putting it back.

My concern stems from possible mismatch between the identity authenticated by TLS and the identity used in the KMIP Authentication header; serious mischief is possible if these don't match and aren't checked for correspondence.  If the identity in the KMIP Authentication header is required to match the identity in the certificate used with TLS, and the receiver of the message is required to check that the identities do match, that would be ok.

The class of attack of concern is that Mallory uses a TLS certificate that correctly identifies him as Mallory, but claims to be Alice in the KMIP Authentication header - if this isn't checked, Alice's keys may be given away.

Thanks,
--David

> -----Original Message-----
> From: Bob.Nixon@Emulex.Com [mailto:Bob.Nixon@Emulex.Com]
> Sent: Wednesday, May 18, 2011 7:12 PM
> To: indra.fitzgerald@hp.com
> Cc: kmip@lists.oasis-open.org; cds@cisco.com; Black, David
> Subject: RE: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded
> 
> Thanks again, Indra!
> 
> I'll incorporate your recommendations on issues 1 and 3 in my next revision, and leave the
> questions on use of the Authentication structure pending further discussion.
> 
> With respect to the new work for client registration, I'd note that this profile targets KMIP
> 1.0, which puts the client registration feature out of reach. The choice of 1.0 cannot be called
> certain, because it looks like there are several things in 1.1 we could leverage. Unfortunately,
> basing the profile on 1.1 would be bound up in a three-way race among KMIP 1.1 technical
> stability, FC-FS-3 technical stability, and my retirement   8-)
> 
>    - bob
> 
> -----Original Message-----
> From: Fitzgerald, Indra [mailto:indra.fitzgerald@hp.com]
> Sent: Wednesday, May 18, 2011 3:41 PM
> To: Nixon, Bob
> Cc: kmip@lists.oasis-open.org; cds@cisco.com; Black_David@emc.com
> Subject: RE: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded
> 
> Hi Bob,
> 
> Please see my responses inline.
> 
> Regards,
> Indra
> 
> -----Original Message-----
> From: Bob.Nixon@Emulex.Com [mailto:Bob.Nixon@Emulex.Com]
> Sent: Wednesday, May 18, 2011 1:04 PM
> To: Fitzgerald, Indra
> Cc: kmip@lists.oasis-open.org; cds@cisco.com; Black_David@emc.com
> Subject: RE: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded
> 
> Thanks for your help with this profile, Indra!
> 
> I’m augmenting the distribution with David Black, who assisted in the early review, and whom I
> inadvertently omitted from my posting notice.
> 
> Otherwise, I’ve inserted responses in-line with your comments. I'd welcome anyone's opinions on
> them!
> 
>    - bob
> 
> -----Original Message-----
> From: Fitzgerald, Indra [mailto:indra.fitzgerald@hp.com]
> Sent: Wednesday, May 18, 2011 11:15 AM
> To: Nixon, Bob; kmip@lists.oasis-open.org
> Cc: cds@cisco.com
> Subject: RE: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded
> 
> Hi Bob,
> 
> Below are my comments on the T11 profile.
> 
> Regards,
> Indra
> 
> 1. X.3.2.1 (c) (should not use TLSv1.2 to provide assurance of client authenticity for the Query
> operation) is already covered by (b) (shall use TLSv1.2 to provide assurance of mutual
> authenticity for KMIP messaging, with the exception of the Query operation)
> 
> bn>     I think c) is needed.  b) excuses QUERY from the “shall”, but it does not express any
> preference. The KMIP specification and its profiles consistently discourage (or prohibit)
> requiring client authentication for QUERY. That preference is what c) was trying to add. I see it
> would be more accurate if c) were to say "should not require" rather than "should not use".
> 
> [IF] I think it would be clearer to replace "should not use" with "should not require".
> 
> bn>     As a side note, I have had more than one note advising that I should model on Basic
> Authentication, not TLSv1.2 Authentication. My next revision will reflect that unless there is
> some further and very enthusiastic favor expressed for TLSv1.2.
> 
> [IF]  TLS 1.2 has not been widely adopted. It makes sense to me to go with the Basic
> Authentication Suite.
> 
> 2. X.3.2.3 states that the server shall return an error if the Authentication structure is
> specified in the Request Header. In particular, according to the profile, the server should
> return the following:
> a) no Operation field;
> b) a Result Status field set to Operation Failed; and
> c) a Result Reason Enumeration set to Authentication Not Successful.
> 
> The Operation needs to be specified in the Response. This is required by the spec. Please see
> Table 190, which states that Operation is required if specified in Request Batch Item.
> 
> bn>     Since the whole request, not just one of possibly many batch items, is failed, I modeled
> on the general error “Protocol major version mismatch” (KMIP Spec table 226), which uses “a
> header and a Batch Item without Operation”. But I’m not wedded to that. Is it preferred to return
> a Response message reflecting every Batch Item in the Request, each one identically failed?
> 
> [IF] I see. If that is the case, we should be able to use the action specified for the "Protocol
> major version mismatch" error.
> 
> Also, depending on the client registration proposal, this behavior should not be required. The
> Authentication Credential could simply point to the Transport Certificate.
> 
> bn>     If I understood him, T11’s favorite security systems expert expressed strong feeling that
> use of the Authentication Header was a serious vulnerability. On the other hand, ignoring one
> when present seemed to me to risk interoperability failures. Thus, I chose to forbid them. I’ll
> leave that open for further input, but I would need David Black’s tolerance, if not enthusiasm,
> for putting it back.
> 
> [IF] I am not suggesting that your authentication mechanism should depend on the Authentication
> structure. Depending on how the credential proposal is defined, you could rely on the TLS
> authentication and specify the Authentication structure without performing additional
> authentication mechanisms and without specifying the actual client certificate. I am still
> waiting to get additional clarification on the latest client registration/credential proposal. It
> was only a suggestion.
> 
> I think disallowing the Authentication structure could potentially cause interoperability issues
> depending on how the server is configured.
> 
> 3. X3.3 (d) (A) requires support for Block Cipher Mode. This is not an attribute and does not
> need to be explicitly specified. It is specified inside Cryptographic Parameter, which is already
> required by the Server conformance clauses (a). See Section 12.1 2f in the specification.
> 
> bn>     I cannot find in the KMIP specification that a conformant server is required to support
> optional fields within a required attribute, so I believe I need to make an explicit statement.
> You are correct about the error in classifying it, of course. Would it be properly expressed as
> “Block Cipher Mode field within Cryptographic Parameter”?
> 
> [IF] This should already be covered by X3.3 B). How about making your suggested change in B)?
> 
> 4. X3.3 (E) (ee) lists the Cryptographic Usage Mask Derive Key. Are keys derived externally
> (i.e., not by the KMIP server)?
> 
> bn>     Yes. Derived keys are produced within the GPSK implementation from the value produced by
> using the original key to encrypt a concatenation of data exchanged in the GPSK protocol. I am
> not certain this fits the formal definition of Derive Key usage, but it led me to presume so. I’d
> be completely open to being advised to the contrary.
> 
> [IF] It's fine to include this usage mask. I just wanted to make sure that X.3.3 c) A) lists all
> the required operations.
> 
> 5. x3.3 (G) states that requests containing the Authentication structure shall be rejected.
> Please see my comment for (2) above.
> 
> 
> -----Original Message-----
> From: bob.nixon@emulex.com [mailto:bob.nixon@emulex.com]
> Sent: Wednesday, May 11, 2011 3:43 PM
> To: kmip@lists.oasis-open.org
> Cc: cds@cisco.com
> Subject: [kmip] Groups - T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) uploaded
> 
> Ive posted the current draft of the KMIP 1.0 profile for EAP/GPSK/FC-SP-2
> that is being developed in INCITS T11.  Given KMIPs intention to
> facilitate externally developed profiles, this profile is being developed
> as an annex to FC-SP-2 rather than as a KMIP standard or committee draft. I
> would appreciate any feedback the KMIP TC membership is willing to offer to
> assure that it is consistent to KMIPs expectations as well as technically
> correct.
> 
> Ive already incorporated some changes recommended by a small group that
> included both KMIP and FC-SP-2 expertise.  Full disclosure:  I have not yet
> incorporated everything that was recommendedthe members of that smaller
> group have to engage in some more arm-twisting. That may succeed. If not,
> they will have a more rational T11 group to convince after my retirement at
> the end of June   8- )
> 
> -	bob
> 
> 
>  -- Bob Nixon
> 
> The document named T11 profile for EAP/GPSK/FC-SP-2 (11-022v2.pdf) has been
> submitted by Bob Nixon to the OASIS Key Management Interoperability
> Protocol (KMIP) TC document repository.
> 
> Document Description:
> This is a draft of a KMIP 1.0 profile being developed in the INCITS T11
> work group FC-SP-2. Its intention is to specify requirements for a
> KMIP-conformant Key Server to manage shared keys used by EAP/GPSK
> authentication in the FC-SP-2 protocol.
> 
> View Document Details:
> http://www.oasis-open.org/committees/document.php?document_id=42111
> 
> Download Document:
> http://www.oasis-open.org/committees/download.php/42111/11-022v2.pdf
> 
> 
> PLEASE NOTE:  If the above links do not work for you, your email application
> may be breaking the link into two pieces.  You may be able to copy and paste
> the entire link address into the address field of your web browser.
> 
> -OASIS Open Administration