OASIS Key Management Interoperability Protocol (KMIP) TC

Submitter's message We have a request to provide closer coordination between client and server logs. This very simple proposal provides a text field that enables the client to provide extra information for the server to log. The server can also pass back a string to the client which can be used to identify server log values.

I would like to present this at the next call. All feedback in advance most welcome. -- Anthony Berglas Document Name : Client / Server Correlation Value Description Proposal to enhance communication between the client and server. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Proposals Date submitted : 2015-12-14 23:58:43

Anthony, Nice and simple.  But even that proved too much for me.  I still bumped my head on something....I was expecting the server to return the ClientCorrelation so the client could make the connection in its own logs. I can see that the server might return its own ServerCorrelation, so would expect the response header might have two correlators in it. Since the server can initiate a request, I would expect that a RequestHeader could contain either a ClientCorrelation or a ServerCorrelation.  Or were we thinking that the KMIP server is in a client role and thus uses the ClientCorrelator and we are going to trust the client to know it's in the server role on those services and should use the ServerCorrelation in its ResponseHeader? And since this information is to be logged and we don't necessarily know the access controls on said log(s), the UsageGuide SHOULD contain some language about the correlator's potential lack of privacy (e.g., don't put something secret in there/a bearer token). Bruce A Rich brich at-sign us dot ibm dot com From:         Anthony Berglas <anthony.berglas@cryptsoft.com> To:         kmip@lists.oasis-open.org Date:         12/15/2015 01:59 AM Subject:         [kmip] Groups - Client / Server Correlation Value uploaded Sent by:         <kmip@lists.oasis-open.org> Submitter's message We have a request to provide closer coordination between client and server logs. This very simple proposal provides a text field that enables the client to provide extra information for the server to log. The server can also pass back a string to the client which can be used to identify server log values. I would like to present this at the next call. All feedback in advance most welcome. -- Anthony Berglas Document Name : Client / Server Correlation Value Description Proposal to enhance communication between the client and server. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Proposals Date submitted : 2015-12-14 23:58:43

Hi Anthony,      It is almost like you want a unique request identifer for each request.   The client generates it and the server places that request identifier into their logs.    And of course the server includes a server response identifier. The fact that all of this gets placed in the logs is a by product to me. Best, Mark From: Bruce Rich <brich@us.ibm.com> To: Anthony Berglas <anthony.berglas@cryptsoft.com> Cc: <kmip@lists.oasis-open.org> Sent: 12/15/2015 1:10 PM Subject: [GRAYMAIL] Re: [kmip] Groups - Client / Server Correlation Value uploaded Anthony, Nice and simple.  But even that proved too much for me.  I still bumped my head on something....I was expecting the server to return the ClientCorrelation so the client could make the connection in its own logs. I can see that the server might return its own ServerCorrelation, so would expect the response header might have two correlators in it. Since the server can initiate a request, I would expect that a RequestHeader could contain either a ClientCorrelation or a ServerCorrelation.  Or were we thinking that the KMIP server is in a client role and thus uses the ClientCorrelator and we are going to trust the client to know it's in the server role on those services and should use the ServerCorrelation in its ResponseHeader? And since this information is to be logged and we don't necessarily know the access controls on said log(s), the UsageGuide SHOULD contain some language about the correlator's potential lack of privacy (e.g., don't put something secret in there/a bearer token). Bruce A Rich brich at-sign us dot ibm dot com From:         Anthony Berglas <anthony.berglas@cryptsoft.com> To:         kmip@lists.oasis-open.org Date:         12/15/2015 01:59 AM Subject:         [kmip] Groups - Client / Server Correlation Value uploaded Sent by:         <kmip@lists.oasis-open.org> Submitter's message We have a request to provide closer coordination between client and server logs. This very simple proposal provides a text field that enables the client to provide extra information for the server to log. The server can also pass back a string to the client which can be used to identify server log values. I would like to present this at the next call. All feedback in advance most welcome. -- Anthony Berglas Document Name : Client / Server Correlation Value Description Proposal to enhance communication between the client and server. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Proposals Date submitted : 2015-12-14 23:58:43

Hi Anthony   I support effective logging, but the existing protocol specification provides all that is needed in the form of the Unique Batch Item ID . This field supports the unique identification of each and every Batch Item originated by a client or by a server:   REQUEST: <RequestMessage>   <RequestHeader>     <ProtocolVersion>       <ProtocolVersionMajor type="Integer" value="1"/>       <ProtocolVersionMinor type="Integer" value="1"/>     </ProtocolVersion>     <BatchCount type="Integer" value="3"/>   </RequestHeader>   <BatchItem>     <Operation type="Enumeration" value="Create"/>     < UniqueBatchItemID type="ByteString" value=" 75e8bdb337aec40e "/>     <RequestPayload>       <ObjectType type="Enumeration" value="SymmetricKey"/>       o o o     </RequestPayload>   </BatchItem>   <BatchItem>     <Operation type="Enumeration" value="Create"/>     < UniqueBatchItemID type="ByteString" value=" ac0e6e56e8d99f66 "/>     <RequestPayload>       <ObjectType type="Enumeration" value="SymmetricKey"/>       o o o     </RequestPayload>   </BatchItem>   <BatchItem>     <Operation type="Enumeration" value="Create"/>     < UniqueBatchItemID type="ByteString" value=" 77e87d356ba09da1 "/>     <RequestPayload>       <ObjectType type="Enumeration" value="SymmetricKey"/>       o o o     </RequestPayload>   </BatchItem> </RequestMessage>   RESPONSE: <ResponseMessage>   <ResponseHeader>     <ProtocolVersion>       <ProtocolVersionMajor type="Integer" value="1"/>       <ProtocolVersionMinor type="Integer" value="1"/>     </ProtocolVersion>     <TimeStamp type="DateTime" value="2012-04-27T08:14:44+00:00"/>     <BatchCount type="Integer" value="3"/>   </ResponseHeader>   <BatchItem>     <Operation type="Enumeration" value="Create"/>     < UniqueBatchItemID type="ByteString" value=" 75e8bdb337aec40e "/>     o o o   </BatchItem>   <BatchItem>     <Operation type="Enumeration" value="Create"/>     < UniqueBatchItemID type="ByteString" value=" ac0e6e56e8d99f66 "/>     o o o   </BatchItem>   <BatchItem>     <Operation type="Enumeration" value="Create"/>     < UniqueBatchItemID type="ByteString" value=" 77e87d356ba09da1 "/>     o o o   </BatchItem> </ResponseMessage>   The Unique Batch Item ID is superior to a message identifier because it identifies individual operations within a message. This same identifier is returned to the client in the server’s response. The proposed Client / Server Correlation ID s provide no value beyond what the Unique Batch Item ID already provides.   I would suggest that the KMIP Usage Guide be amended to say that every Batch Item SHOULD include a Unique Batch Item ID – even if the message contains just a single Batch Item (if only to facilitate problem analysis) – and both clients and servers SHOULD include the Unique Batch Item ID in any logs. The Usage Guide should further state that a Unique Batch Item ID SHOULD be globally unique [and not merely unique within a message] so as to preclude logging ambiguities.   Cheers, … Dave       From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Anthony Berglas Sent: Tuesday, December 15, 2015 2:59 AM To: kmip@lists.oasis-open.org Subject: [kmip] Groups - Client / Server Correlation Value uploaded   Submitter's message We have a request to provide closer coordination between client and server logs. This very simple proposal provides a text field that enables the client to provide extra information for the server to log. The server can also pass back a string to the client which can be used to identify server log values. I would like to present this at the next call. All feedback in advance most welcome. -- Anthony Berglas Document Name : Client / Server Correlation Value Description Proposal to enhance communication between the client and server. Download Latest Revision Public Download Link Submitter : Anthony Berglas Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Proposals Date submitted : 2015-12-14 23:58:43   The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

On 16/12/2015 12:35 PM, Featherstone, David wrote: > > Hi Anthony > > > > I support effective logging, but the existing protocol specification > provides all that is needed in the form of the *Unique Batch Item ID*. > This field supports the unique identification of each and every *Batch > Item* originated by a client *_or_* by a server: > Unfortunately it doesn't allow for request level tracking or flows that span multiple requests and its use is entirely optional (for requests or responses containing a single batch) and it doesn't handle error responses where you may have no response for a given input batch item in a prior request. Basically for the logging context for flows we have nothing currently other than vendor-specific extensions. There is also no expectation of the unique batch item id being anything actually particularly unique cross-request - noting that most of the examples use 01 02 03 etc as a naming scheme - nothing of course precludes a vendor from implementing the unique batch item id as a globally unique item cross-requests but we haven't seen any vendor to date taking that as a strategy so it doesn't offer a solution to the stated problem. The purpose of the unique batch item id was to handle out-of-order batch item processing - it is not intended to be a globally unique item (although it isn't precluded from being one either). We have talked numerous times during plugfests and interops for wanting to have a way to line up the client and server logs for faster (and more automated) matching of checking of conforming results and this definitely addresses that concern whereas at the batch item level it would not. Tim.