KMIP Compliance
Redefining Server and Client
requirements to claim compliance
Presented by: Bob Lockhart
Feel the Pain
• The current standard does not require either
the server or the client to support all aspects
of either of the profiles defined
– Requires point to point interoperability testing
• Each vendor must test with every other vendor
• At some point we get to product by product testing
between two vendors that have multiple products
using KMIP with no two product making use of the
same set of operations, objects and attributes
Why fix it
• Due to the limited number of vendors with products
currently the solution has been patched together so
that interop went off fairly well at RSA
– It should be noted the man behind the curtain was still
apparent to some folks
• This does not scale in the long run
• To make life easier for other parts of the specification
we should address it now versus later
– Capability Advertisement/Negotiation will have to include
every object, operation, attribute and feature supported
by every server and client otherwise.
Solution
• The major problem is that there are vendors
that only want to build a solution that works
for their devices
– Server with no full profile support
– Client with only a portion of a given profile
• They are using KMIP so should be able to
claim compliance
Two Servers, One Client
• To solve this last dilemma two server and one
client definition can be created and
interoperability ensured
– Profile Compliant Server
– Profile Compliant Client
– Client Specific Server
KMIP Profile Compliant Server
• A server that provides all required and optional
objects, operations, messaging and attributes of a
specific profile
–
–
–
–
All objects
All operations
All optional attributes
Extended attributes using a pre-defined mechanism
(TBD as part of 2.0?)
– All defined wire protocols (TLS, SSL, IPSec, etc…)
– All defined methods of authentication
• We need to keep it simple here and to one method if
possible…
KMIP Profile Compliant Client
• A client that supports one or more defined objects,
operations and/or functions of a given profile for which
compliance is claimed
– The profile can make all client functions optional so that
only one has to be done to claim compliance or it can
define the minimum required support for a given profile
– In the case of a Client less is more
– Extensions will need to be well defined so that vendors
with clients can use existing profiles and add the objects
and attributes they need (TBD as part of 2.0?)
– Only one wire protocol must be supported
– Only one of the defined authentication mechanisms must
be supported
KMIP Client Specific Server
• A server that is built to support a specific set of clients
– A set can be one client or various clients belonging to a device
type or a client vendors product line
• In order to claim KMIP compliance the clients it supports
must be Profile Compliant Clients
– If the target client or clients do not support a defined profile
then the server can not claim KMIP compliance as a KMIP Client
Specific Server
• Extensions must be supported in a predefined manor (TBD
as part of 2.0?)
– Again since KMIP Profile Compliant Clients have to support
extensions in a set way any extensions used by the server to the
client must also comply with extension definitions as per KMIP
v2.0
Conclusion
• A simplified interoperability specification
– Creates ensured interoperability between client and server by setting specific
requirements on each so that the server will always meet or exceed a clients
requirements if they share a common profile
• Short and simple compatibility advertisement/negotiation for all future
versions of KMIP
– Potentially a 64 bit ID per profile supported by the server and client to figure
out which to apply
• Allows vendors to build KMIP compliant servers that are specifically
targeted at their own clients
– While it may be possible to use a given vendor’s product to manage another
vendor’s product where there is overlap, these managers won’t be customized
to do that in most cases (think SNMP Managers)
• Allows third parties to more easily define KMIP profiles for interoperability
purposes by having clearly defined guidelines for claiming compliance