Server to Server Group Requirements Simplifying key management

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) Group 1 Group 2 Group 3 • 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 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 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. AES 256 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?