50 likes | 178 Views
KMIP Profiles version 1.3. A Method to Define Operations Access Control and Interaction Between a Client and Server Presented by: Kiran Kumar Thota & Bob Lockhart. Defining the Problem.
E N D
KMIP Profiles version 1.3 A Method to Define Operations Access Control and InteractionBetween a Client and Server Presented by: Kiran Kumar Thota & Bob Lockhart
Defining the Problem • A user wants to create and control the lifecycle of a key via an application that is responsible for the data being protected • Primary use cases are for applications that manage data lifecycle • A client needs to get the key to access the data but CANNOT create or control the key • Data is encrypted or decrypted at its point of use and thus protected when in flight or at rest. • If defined properly, profiles could be created to support any version of the KMIP specification (e.g. 1.0, 1.1, 1.2, etc…) • Use the KMIP Profiles 1.3 document to define how it is done • This keeps client development requirements lower • Puts more work on server vendors (potentially)
Solving the Problem – Step 1 • To date profiles have only defined object types and attributes • There is no reason not to allow it to also define operations • Limit the operations performed by a given client profile • “Administrative” users could perform some or all operations with the exception of get key • “Managed” users could perform get and other allowed operations NOTE: Defining two or more client types within one profile should be allowed to avoid confusion between different profiles
Example Different Clients in a Profile Administrative Client Operations Managed Client Operations Locate Check Get Get Attributes Get Attribute List Add Attribute Modify Attribute Obtain Lease Get Usage Allocation Validate Query Discovery Versions • Create • Create Key Pair • Register • Re-Key • Re-Key Key Pair • Derive Key • Certify • Re-certify • Locate • Check • Get Attributes • Get Attribute List • Add Attribute • Modify Attribute • Delete Attribute • Activate • Revoke • Destroy • Archive • Recover • Validate • Query • Discovery Versions • Cancel
Considerations • What ifs… • What if an “administrative” client needs to access a different set of keys? • What if a managed client needs to fit into two profiles • What if … • There are a lot of different use cases but until someone finds one, these are vendor specific implementations we should stay away from • We need to be flexible enough to allow server and client vendors to determine how best to differentiate themselves • We need to stay just enough ahead of the market when defining how KMIP works • This will require additional considerations for test cases by requiring two different clients or sets of credentials • We haven’t really done this one before • Focus on the messaging via Profiles in 1.x, tackle the tough stuff in 2.x and later