KMIP Compliance Redefining Server and Client requirements to

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 based on feedback from end users • 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 the “non-public profile” client/server 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 unless specified as not required in the profile – All operations unless specified as not required in the profile – All optional attributes unless specified as not required in the profile – 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 extensions existing in profiles and add the objects and attributes they need (TBD as part of 2. 0? ) • This will be the toughest on how to store and return unknown extensions – Only one wire protocol must be supported – Only one of the defined authentication mechanisms must be supported by the client

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 compliance as a KMIP Client Specific Server • Extensions must be supported in a predefined manner (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 v 2. 0

Creating Public Profiles • Any vendor or organization (other standards bodies) should be able to create a profile and publish it – The profile would have to be publicly available and would need to be registered with KMIP profile registry (TBD if this is even an option) – This would allow a vendor to claim to be KMIP Profile Compliant Server as long as they clearly defined all aspects of the profile including: • • • Objects, Operations, Messaging, Error Messages & Extensions Wrapping mechanisms Protocols and associated service ports Authentication mechanisms Others?

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