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

[<Bob.Nixon@Emulex.Com>]

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