Access Control in KMIPv1.1/v2

1. Robert Haas <rha@zurich.ibm.com> Access Control in KMIPv1.1/v2

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

3. Access Control in KMIPv1.1/v2: Proposal • We suggest two complementary mechanisms • Basic Access Control • Strict Access Control (SAC) • Basic Access Control • 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 • Strict Access Control (SAC) • 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)

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

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

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 • irrespective of create in UPL • Certify, Re-certify: • certify for MO • irrespective of create in UPL • 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)

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

8. Example of the Attack on BAC (Note: already presented at KMIP f2f Sep 28-29 2009) • 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

9. Example (Get Wrapped) Alice Bob

10. SAC: Details • 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 2010. Also available as IBM Research Report RZ 3739, June 2009.

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

12. Comments?