1. Access Control in KMIPv1.1/v2
Robert Haas
21 November 2018
Access Control in KMIPv1.1/v2

2. Access Control in KMIPv1
Operation Policy Name placeholder
Object Attribute
Not mandatory
Defines the default permissions
21 November 2018

3. Access Control in KMIPv1.1/v2: Proposal
We suggest two complementary mechanisms
Basic Access Control
Strict Access Control (SAC)
Possibly mandatory (at least regulated through profiles)
Access Control Lists (ACLs) attached to objects
Object Attribute
Consists of (user/role,permission) pairs
User Permission Lists (UPLs)
For operations that refer to not yet existing objects (Create, Create Key Pair, Register)
“global” list of (user/role, permission pairs)
“global” is here in the sense of “unique per key-management domain”
Finer granularity (e.g., multiple subdomains) possible
Possibly optional (also could be regulated through profiles)
To prevent KMIP API attacks introduced by object dependencies
Object dependencies are introduced notably through derivation and key wrapping
API might “leak” information about dependent keys
This may lead to ACL violation if object interdependencies are not checked
Through standardization of additional SAC specific attributes (in addition to Basic AC)
21 November 2018

4. Basic Access Control (BAC)
ACLs and UPLs are forseen as lists (user/role, permission) pairs
ACL is foreseen as a potentially mandatory attribute of an object
A UPL (potentially also mandatory) is not attached to any object
Users
There is a tight interplay between the standardization of user representation in KMIP (cf. Client Registration Action Item)
Special users any and creator already in KMIPv1
Permissions
Suggested in the following
Rough initial proposal, to be refined for each Object type
21 November 2018

5. BAC: Proposed UPL permissions
Operations and permissions
Create, Create Key Pair, Register : create
21 November 2018

6. BAC: Proposed ACL Permissions
Operations, ACL permissions and UPL permissions
Special permission admin permitting all operations
Rekey:
rekey for the targeted Managed Object (MO)
irrespective of create in UPL
Derive:
derive for MO
Certify, Re-certify:
certify for MO
Locate, Check, Get Attrs, GetAttrList:
read_attributes for MO
Get:
for MO: read (for Get in cleartext), export (for Get wrapped)
for the wrapping key: wrap (Get wrapped)
Add, Modify, Delete Attr, Activate, Revoke:
modify_attributes for MO (to change everything but ACL)
Obtain Lease, Get Usage Allocation:
read or export for MO
Destroy:
destroy for MO (or simply admin)
Archive/Recover:
archive for MO (or simply admin)
Validate:
read for all given Certificate objects
TBD: should read be implicit for all Certificates?
Query:
no permission
Cancel, Poll:
TBD: separate permission for asynchronous operations (if at all)
21 November 2018

7. Strict Access Control (SAC): Motivation
API attacks on key management APIs
a legitimate concern
Operation on cryptographic keys might introduce dependencies between keys
Example operations: Derive, Get (wrapped)
If only basic ACL/RBAC mechanisms are implemented/specified in KMIPv2, these might be circumvented by exploiting the KMIP API
Such API attacks are applicable to existing practical key management interfaces like PKCS #11
21 November 2018

8. Example of the Attack on BAC
(Note: already presented at KMIP f2f Sep )
Use case
Tape drive encryption
Setup
Key B is used to encrypt the tape drive
Key B wrapped with key A is stored on a tape drive (e.g., by user Bob)
Initially no user (except administrator) has a permissions to read the key material of Key A
Administrator gives the permission to user Alice to read the key material on key A, not knowing that it was used to wrap key B
Administrator does not intend to allow Alice the permission to read key B
Attack
Alice reads the key material of Key A from KMIP server, gets the wrapped Key B, unwraps it and obtains the key material of Key B
21 November 2018

9. Example (Get Wrapped) Alice Bob User/Key Key A Key B Alice read - Bob
export
21 November 2018

10. SAC: Details References:
Proposed solution for the API attack problem in future KMIP servers
Support could be optional (perhaps related to certain KMIPv1.1/v2 profiles)
Standardize KMIP attributes to track dependencies among keys and modify basic AC mechanisms to account for these
References:
1. Christian Cachin and Nishanth Chandran. A secure cryptographic token interface. In Proc. Computer Security Foundations Symposium (CSF-22). IEEE, July 2009.
2. Mathias Bjorkqvist, Christian Cachin, Robert Haas, Xiao-Yu Hu, Anil Kurmus,
Rene Pawlitzek, and Marko Vukolic, Design and Implementation of a Key Lifecycle Management System. To appear in Proc. Financial Cryptography and Data Security (FC’10), January Also available as IBM Research Report RZ 3739, June 2009.
21 November 2018

11. SAC: Proposed Attributes
Strict (flag, boolean)
Denotes whether strict policy applies to an object
Important for support of legacy applications in use cases where SAC guarantees are not required/possible to implement
Dependents
Set of UUIDs of Dependent objects
Ancestors
Set of UUIDs of Objects that have a given object in the Dependents
Readers
Set of users that have read the cleartext of the key
21 November 2018

12. Comments?
21 November 2018