OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]