[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
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". 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. 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? 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. 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”? 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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]