Re: [kmip] Re: Groups - KMIP AC in v1.1 (AC-kmipf2f-mar2010.pdf)

[Marko Vukolic2 <MVU@zurich.ibm.com>]

Hi Marcus,

thanks for your comments! Please look below for the responses and please
let me know your position on particular questions.

Thanks,
Marko

Marcus Streets <Marcus.Streets@thales-esecurity.com> wrote on 03/11/2010
02:53:14 PM:

> -------------
>
> I think that Activate and Revoke are different for Add/Modify/Delete
> object and should have their own Object permission - Change State

I see your point. Still Add/Modify/Delete Attr could be used to Change the
state (e.g., by setting Deactivation date to present time/date).

There is actually this idea to consolidate rekey, archive and modify_attrs
into a single permission (called, for example, operate - see also my
response to Indra). Would you strongly object this? Do you have a specific
use case that would require the distinction between permissions for
Add/Modify/Delete vs. Revoke?

>
> Extension for role permissions
> -----------------------------
> I think it might be useful if role permissions could take a template
> name - if the template is specified then that role may only create a key
> using the specified template.
>
> We may the want to split create key and create key pair, as the latter
> would need a pair of template, one for the private key and one for the
> public key.
>
> To enable a role to create keys with different template they would need
> multiple permissions, on for each template.
>
> Obviously we need to be able to permit unrestricted creates, I can see
> two ways of doing this. Either make template name optional - and
> interpret an entry without a template name as allowing any template
> Or invent a special names "Any" that permits any defined template and
> "None" that allows creation of keys without specifying a template.
>
> I prefer the latter.
>
> Obviously the Admin role would have to be given [Register "None"] by
> default or you could never register any templates.
>
> IF we do this then we can permit referencing a Template in Template/Attr
> structure to all - rather than requiring the role to have
> read_attributes on the template.

What seems simpler, yet with the same functionality (modulo the separation
between Create and Create Key Pair, discussed later) is to have 4 role
permissions: Create, Register, Template Create, Template Register, with
keeping read_attributes in the template ACL.

Is there a particular problem with the read_attributes in the Template ACL
requirement? If this mainly for the support of "Any" Template in your
proposal?

As for the separation between Create and Create Key Pair, I am not sure
that the use case you target requires this. We could have, for Create Key
Pair:

1) in the variant that you proposed:

      two "role-template" permissions for a given role R
      (Create + PrivateTemplate) and (Create + PublicTemplate)

2) in the proposal w. 4 role permissions and read_attributes in the ACL of
a Template

Template Create permission for R and (R, read_attributes) in both
PrivateTemplate.ACL and PublicTemplate.ACL


> I am actually more concerned with users being allowed to override the
> attributes defined in a template. I would prefer that more facilities to
> force users to stick to the defined templates - rather than putting any
> roadblocks in the way of clients using them.

This can actually be covered by the above proposal with 4 role permission
(RP) + read attributes in ACL. We could have the following rules:

1) Role R can create object using template T if it has the Template Create
RP and (R,read_attributes) in T.ACL

2) Create RP implies the Template Create RP

3) a role R can override attributes in a Template if and only if has a
Create RP


> Read Attribute / Modify_Attribute
> ---------------------------------
>
> Is there any mileage in allowing the acl to specify a list of attributes
> that can be read / modified?

no. Except for the ACL attribute (which requires admin permission to be
Modified/Deleted).

>
> Again we can use either and empty list or "Any" to allow access to al
> attributes. Once again I would prefer the latter option.

is there a use case where a finer granularity than "any" or
"none" (currently supported) would be required? If you feel there is a
strong need one could of course define such an extension.

>
> Export
> ------
>
> Do we want to restrict which keys can be used to wrap another key - for
> example by adding a list of UUIDs to either export of wrap permissions.
>
> The list on export would specify the keys that are permitted to wrap
> this key. The list on export would specify the keys that this key could
> be used to wrap.


Would you really want to segment export/wrap permissions or would a simple
introduction of additional Link Types like 'WrappableBy' and 'CanWrap' be
sufficient?

>
> Again we can use either and empty list or "Any" to allow wrapping of/by
> any key. Once again I would prefer the latter option.
>
> Two final extensions - but these might be getting too rococo.
>
> We might want to allow "Owner" to allow keys to wrap/be wrapped by any
> key that is owned by the same Identity.

It seems to me that already with this proposal (after we introduce the
Owner) you could configure this by ensuring that there is (owner,wrap) and
(owner, export) in the ACL of every object.


> And perhaps <Role> to allow keys to wrap/be wrapped by any key that is
> owned by an identity that belongs to that role.

>
>
> --
> Marcus Streets
> Security Standards Officer
>
> THALES Information Systems Security
> nCipher product line
>
> ------------------------------------------------------
> T:  +44 (0) 1223 723613 (Direct)
> F:  +44 (0) 1223 723601
> E:  Marcus.Streets@thales-esecurity.com
> W:  www.thalesgroup.com/iss
>
> [attachment "signature.asc" deleted by Marko Vukolic2/Zurich/IBM]