Failing to get symmetric key using a commercial KMIPserver

[jeff-andre]

I've been trying to use libkmip with a commercial KMIP server. The same program works correctly with PyKMIP. Has anyone else gotten the the library to work with another server?

Also does one go about debugging an issue like this? The vendor will not provide a hex dump of the encoded packet; with it could probably figure out the problem in a short amount of time.

The error the server is generating:

WARN ... Failed to get ikm type for key (null) rc = -7 WARN ... Failed to get key details for key (null):(null) rc=-7 ERROR ... request.keys.kmip.UnknownOp ClientIP=xx.xx.xx.xx; ServerPort=5696; CN=KMIPtest; Username=KMIPtest; \ RequestCount=5812; Operation=1.0_Undefined Operation [0]; \ info=Exception: ...; ResultReason=GeneralFailure; \ errmsg=Unknown key name or insufficient permissions

[PeterHamilton]

Hi @jeff-andre, thanks for filing this issue. My apologies for the delay in response, this year has been pretty crazy.

I have not been able to test libkmip itself against a third-party commercial KMIP server. However, the PyKMIP server has been used as a stand-in for other third-party servers by third-party developers in the past and has worked well in those use cases, so I would be surprised if there are major failure cases that haven't shown up in our local open source testing. That said, I would always prefer to test libkmip against more server backends if possible.

It will be a bit challenging to debug this issue from the client side without more information from the server. The server error has multiple pieces of information that hint at the problem, including 1.0_Undefined Operation [0]; and Unknown key name or insufficient permissions. The former indicates a general failure with the KMIP request being sent by libkmip. The latter indicates that the KMIP request is fine but the key you are looking for is either inaccessible or cannot be found with the name or ID you provided.

If you are still experiencing this error and are interested in further assistance, please let me know.

[embedded-dev]

Peter, Sorry for the delay, yes it has been a crazy year.

I did figure out the issue. The problem with the C API library is that the maximum key size has a maximum length of 50 bytes. The two key servers I was able (with almost hostile support from their vendors) to test against had keys identifiers of 64+ characters in length, the code has a hard coded length of 50 characters.

I would post a patch but I had to make a number of changes to the C library to support the product I was working on: 1) Increase the key size; 2) Ability to change standard output for messages to another stream; and 3) provide the ability to have error text to be placed into memory. Unfortunately, there was a commit hook that stripped trailing white space, which did a number on the code.

Given the amount of changes, I never created a pull request. I could if you wanted. The repository is at:

https://github.com/versity/libkmip

[PeterHamilton]

Hi @embedded-dev, sorry for the delay, I'm finally getting back to some of these older issues. I believe the 50 character limit is just an arbitrary setting in demo_get.c, here. It's easy to bump that up to something more reasonable. While the demo applications are useful for testing out libkmip they are not really intended to work in all use cases.

I am interested in some of the other changes you mentioned. I updated many of the structure printing utilities to support fprintf a while back for alternative stream output, so I'm curious if the changes you mentioned were geared more toward the output from the demo applications themselves. As for in-memory error text, are you referring to a persistent global structure for storing and persisting error state?