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

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

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

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

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

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

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

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 21 November 2018

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

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 2010. Also available as IBM Research Report RZ 3739, June 2009. 21 November 2018

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

Comments? 21 November 2018