1 / 5

KMIP Profiles version 1.3

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.

astrid
Télécharger la présentation

KMIP Profiles version 1.3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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)

  3. 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

  4. 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

  5. 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

More Related