RE: [kmip] Distributed Key Management Systems Usage Guide test

["Prashant V Mestri" <prmestri@in.ibm.com>]

Hi,

I agree with John. The inconsistency between servers of a replication cluster (SKLM has a distributed key management system, and we call it multi-master cluster) can arise because of many reasons and the resolution of this inconsistency can also have many solutions.

There can not be one standard solution that can be followed, but the important point is that the isolated server when it joins back the replication cluster should get a list of conflicts in name, attributes etc of the managed object. The KMS can provide tools/utilities/steps to resolve the conflicts on the joining server or in the cluster.

Best Regards,

Prashant Mestri
Software Architect
IBM Security Lifecycle Manager
91 808 701 0777 Mobile
91 204 202 6813 Office
prmestri@in.ibm.com

IBM Security

John Leiseboer ---28-09-2019 11:15:03---Iâm not sure that there is much more could be said in the Usage Guide other than for users to beware

From: John Leiseboer <JL@quintessencelabs.com>
To: "Stueve, Gerald" <GStueve@fornetix.com>, Mark Joseph <mark@p6r.com>, Anthony Berglas <anthony.berglas@cryptsoft.com>, Jeff <jeff@bartellemail.com>
Cc: Tony Cox <tony.cox@cryptsoft.com>, Tim Hudson <tjh@cryptsoft.com>, Bruce Rich <bar@cryptsoft.com>, OASIS KMIP Technical Committee <kmip@lists.oasis-open.org>
Date: 28-09-2019 11:15
Subject: [EXTERNAL] Re: [kmip] Distributed Key Management Systems Usage Guide test
Sent by: <kmip@lists.oasis-open.org>

---

Iâm not sure that there is much more could be said in the Usage Guide other than for users to beware of strange things that may happen (as the proposed texts by Anthony and Jeff say).
 
An obvious solution to the name clash due to partitioning event is to not add name attributes to objects. Or to only add name attributes that can be guaranteed to be unique by the client (perhaps with a client unique identifier embedded in the name), or an alternative attribute that can be used like name but doesnât have a uniqueness constraint. Another solution may be for a server to disallow adding name attributes when a cluster is partitioned. Or for the server to modify the name given by a client so that it contains a unique string. Yet another solution may be for a server to fall back to read-only mode when a cluster is partitioned. Yet another solution is for the server to permit duplicate names (and be non-conformant with the KMIP specification). There are probably dozens more possible âsolutionsâ for just the name attribute issue alone.
 
John
 
On 28/9/19, 9:28 am, "Stueve, Gerald" <kmip@lists.oasis-open.org on behalf of GStueve@fornetix.com> wrote:
 
First thought is that if one instance of the key is âFreshâ then it can be overwritten as the key material has never be delivered to the client. If both instances are delivered then that is a deep problem.
 
v/r,
Jerry Stueve
Lead Engineer, CGB
C: 703.624.0781     O: 571.293.9692
________________________________________________

www.fornetix.com
 
***CONFIDENTIALITY NOTICE:  This email may contain confidential or proprietary information. If you have received this email in errorâDO NOT OPEN ANY ATTACHMENTS, immediately destroy all copies, and notify sender. ***
 
From: kmip@lists.oasis-open.org <kmip@lists.oasis-open.org> On Behalf Of Mark Joseph
Sent: Friday, September 27, 2019 6:49 PM
To: Anthony Berglas <anthony.berglas@cryptsoft.com>; Jeff <jeff@bartellemail.com>
Cc: Tony Cox <tony.cox@cryptsoft.com>; Tim Hudson <tjh@cryptsoft.com>; Bruce Rich <bar@cryptsoft.com>; OASIS KMIP Technical Committee <kmip@lists.oasis-open.org>
Subject: Re: [kmip] Distributed Key Management Systems Usage Guide test
 
One point of clarification below.   The first server is disconnected from the other instances when the connection to the KMIP client occurs.
 
Hi,
 
   One inconsistency we have discussed with a customer is the following scenario.   
 
     A KMIP client first connecting to one server out of several to create a key.   Before the server response comes back the connection
fails.   At this point the client has no idea if the key was created and it used a "Name" attribute in the request.   Next, that client tries to recover from this situation by connecting to another instance of the server and creates the key again.  The second time the key is created  (using the same Name) and all is well.  Then the customer uses this second key for encrypting data locally.   
 
      Now sometime in the future the disconnected servers re-connect and as it turned out the first server did successfully create a key with the same Name as the second server.   Now what happens?   There is nothing in the text below that addresses that other than the server needs to deal with such inconsistencies.    But the client has used that second key to encrypt data and there is no way for that server to know that!  
 
    What do we tell our customers and what should we say in the user's guide about these type of inconsistencies and how clients should handle them?
Differences in key states may be a little easier to handle than the Name attribute.   But what if two vendor's each implement a different scheme to fix the problem what does a KMIP client do if its been written to talk to several (not just one) vendor's server.   
 

Best,
Mark Joseph, Ph.D. President P6R, Inc 408-205-0361 mark@p6r.com Skype: markjoseph_sc http://www.linkedin.com/pub/mark-joseph/0/752/4b4


From: Anthony Berglas <anthony.berglas@cryptsoft.com> 
To: Jeff <jeff@bartellemail.com> 
Cc: Mark Joseph <mark@p6r.com>, Tony Cox <tony.cox@cryptsoft.com>, Tim Hudson <tjh@cryptsoft.com>, Bruce Rich <bar@cryptsoft.com>, OASIS KMIP Technical Committee <kmip@lists.oasis-open.org> 
Sent: 9/27/2019 9:10 AM 
Subject: Re: [kmip] Distributed Key Management Systems Usage Guide test

Looks fine to me. Thank you for providing it.

Anthony

On Fri, Sep 27, 2019 at 1:41 PM Jeff <jeff@bartellemail.com> wrote:
Here is the updated text.


4.7 Key Replication Between Servers

Key management systems may be designed to consist of multiple servers to address fault tolerance, performance, management, and communication considerations. Each server would contain the same objects and attributes. Operations made to one server would be replicated to all the other servers.

4.7.1 Architecture Considerations

Some architectures permit operations to be performed even though all servers are not continuously connected. This means that an operation performed on one server may not be immediately replicated to the rest of the servers. Or different operations can be performed on the same key on different servers. Any inconsistencies may not be noticed until the servers can again communicate with each other.

One example of an inconsistency is that a given key may have different states on different servers. For example, one server might consider a key with a given unique identifier to be Active, while a different server might consider the same key with the same unique identifier to be Compromised. Another example is that two different keys in different servers may end up with the same Name. Forward and backward links might also be inconsistent.

Key management systems consisting of multiple servers need to be carefully designed to ensure that servers can resolve any inconsistencies that arise, and those systems that claim KMIP compliance must ensure that the resolution complies with KMIP specification.


Thanks,
Jeff



On 8/22/2019 7:04 PM, Anthony Berglas wrote:
Hello Mark,

The text is simply alerting people to the issue which is the first small step. A full solution would take some thought and discussion, and might be an excellent topic for next year's face to face meeting. I would be happy to help you make a proposal if you like.

Discussion of the text has been put on the agenda for discussion in next week's call. But please feel free to contribute any additional text that you think might be useful.

Anthony

On Thu, Aug 22, 2019 at 6:53 PM Mark Joseph <mark@p6r.com> wrote:
I am not saying there are easy solutions to these problems but your text really does not help. It allows each vendor to resolve such issues in their own way. Thus someone writing a client will likely have to write different code for each vendor after they figure out what each vendor does.
Best,
Mark Joseph
P6R, Inc
408-205-0361
mark@p6r.com


On Aug 21, 2019, at 9:23 PM, Anthony Berglas <anthony.berglas@cryptsoft.com> wrote:
Hello All,

I would propose the following text for the usage guide following my talk at the face to face. Any comments most welcome.

4.7 Distributed Key Management Systems

Key management systems may be distributed across multiple servers which are not continuously connected. This means that updates can be made to one server that are inconsistent with updates to a second server. The inconsistency may not be detected until the servers communicate with each other which might be some time after the conflicting updates were made, so they cannot simply be rejected from the clients.

One example is that a given key may end up in inconsistent states on different servers, such as both Active and Compromized. Another is that two keys in different servers may end up with the same Name. And forward and backward links may be inconsistent.

Distributed KMIP systems need to be carefully designed to address such issues. For example, if inconsistent states are encountered, then a strategy is needed to produce a sensible resolution. Likewise having multiple keys from different sources with the same name should be resolved in a consistent manner, and operations such as Re-Key need to behave sensibly in such a situation.


--
Anthony Berglas Ph.D.
Principal Engineer
Anthony.Berglas@Cryptsoft.com


--
Anthony Berglas Ph.D.
Principal Engineer
Anthony.Berglas@Cryptsoft.com



--
Anthony Berglas Ph.D.
Principal Engineer
Anthony.Berglas@Cryptsoft.com