Server to Server Group Requirements Simplifying key management between multiple vendor implementations

(Re)Defining a Group What a group should be – A collection of common entities, objects or other groups Should not be more than two or possibly three groups deep (complexity) A group should not be – A container for multiple types of entities and objects If a group contains other groups it cannot contain entities or objects – e.g. Homogeneity Group 1 Group 3Group 2 Group 4

Groups as Containers Group of Entities – Contains one or more like entities that use a common set of objects Like = same attributes, crypto capability, etc… (Read as homogenous) Group of Objects (keys, certificates, etc…) – A set of like objects that can then be bound to or accessed by a – Consideration of a Policy object for server to server may be needed if messaging isn’t enough (use case anyone?) Group of Groups – A group that contains one or more groups Including one or more entity groups, objects & users – How deep groups can go needs to be seriously looked at Group within a group, within a bigger group, ad infinitum Group of Users – Access control for users when external authentication is used in multivendor environments – Defined by KMIP? This would be an example of a potential “other” group category that would not be extended from one vendor server to another other than in a system that uses role based management – Bob L.’s personal opinion is no…

Group Purposes Access Control – Using two levels allows one or more group of entities to map to one or more groups of objects – Provides a common definition between vendors for server to server access control implementation without restricting a vendor’s capabilities to perform access control Ownership – A primary group owns one or more entities, objects or “other” All entities will have a single primary group All objects will have two groups, a group for the individual object and a group of common objects (e.g. AES256 keys, certificates, etc…) – Takes ownership away from devices that can be temporary or long lived but that may not live as long as the keys they access and use Destroying entities doesn’t impact objects if they don’t own the objects to begin with

Questions to Consider Do clients care about Groups? – Is there a reason or use case? Does it make sense to have more than two layers of groups? – Is there a use case where a common set of keys are accessed by different device types that would require this – What kind of access control issues arise with more than two layers of groups – If not two what is a good limit that can be set for server to server instances Is there a good reason to go beyond three layers? Do groups play a part in a global namespace for server to server? – A question to be asked if a model such as URI is used for global key naming How do you resolve policy conflict between server implementations? – Should we stay away from it and let the vendor handle it who makes the call on policy for a given instance? Are there any looming conflicts?