RE: [kmip] Comments about access control proposal

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

Hi Indra,

thanks for your comments! Please look for the responses below. Please let
me know if the proposed actions make sense to you.

Best regards,
Marko

> Slide 2: The KMIP spec supports Role Type in Cryptographic
> Parameters. Could this potentially cause some confusion?

proposed change (synched w. Robert and Mathias): Change the "Role Type" in
KMIPv1 to "Key Role Type"

> Slide 5: As mentioned during the f2f, we need to support the object
> owner role.

This is sure possible and we need such a functionality. But Owner sounds to
me more like a Managed Object Attribute that can be used as a role in ACLs,
do you agree? It would also be subject to Add/Modify/Delete Attribute.

Note that we would also have to revisit SAC proposal with owner in mind,
but I do not expect any problems there.

> Slide 9: Certify and Re-certify create a certificate; should the ACL
> be implicitly set for these operations?

yes. Will take into account in the next version of the AC proposal.

> Slide 10: The spec and UG require special authorization when
> invoking Revoke, Recover, Destroy, and Archive. Should all of these
> operations be covered by the admin permission?

Strictly speaking, all these operations have "special authorization",
albeit not the admin one.

That said, we might want to consolidate the proposal a bit. I discussed
this with Robert and Mathias and the idea is to merge rekey,
modify_attributes and archive permissions into a single permission, called
"operate". Unless I hear voices against this, the new version of the
proposal will reflect this.

> Slide 10: I think it's confusing to define the read permission for
> getting a plaintext object and the export permission for getting a
> wrapped object. We could change these to get_object and
> get_wrapped_object. I am open to other suggestions.

agree. Proposed renaming:

read -> get
export -> get_wrapped

> Slide 10: The wrap permission only covers key encryption. What about
> for signing and MACing? Do we need to include the unwrap permission?

yes. The new proposal version of the proposal will incorporate unwrap, both
in SAC and BAC. I did not include unwrap so far, only since KMIPv1 does not
mandate that a server should indeed unwrap the key registered in the
wrapped form.

> During Register an object may be registered in wrapped format. The
> user should have permission to access the key wrapping key.

to be handled by 'unwrap' permission. If a server actually supports
unwrapping it will need to check 'unwrap' perm.

> Alternatively, instead of defining wrap and unwrap, could we just
> re-use the Cryptographic Usage Mask?

The question is do we want to allow any user to wrap/unwrap using a given
key. If so, Crypto Usage Mask would be sufficient. Otherwise, if we require
some access control for wrap/unwrap, we should keep both Crypto Usage Mask
and Object permissions. Since wrapping created dependencies, my suggestion
is to keep the wrap/unwrap permissions.

> Slide 10, slide 26: In the future (i.e., after we incorporate Judy's
> proposal for making certificate request optional in Certify and Re-
> certify), there should be a separate object permission for Certify
> and Re-Certify. Yes, there may be external proof of possession
> mechanisms in place, but we are not covering all the use-cases. The
> key pair may reside on the server and the user simply invokes the
> Certify operation without providing the certificate request. The
> server should verify that the user has permission to access the key
> pair prior to performing the Certify or Re-certify operations.

certify and re-certify will have either a dedicated permission, or fall
into the consolidated "operate" permission (probably the latter option is
more likely).

> Slide 12: Include Certify and Re-certify next to "When Implicitly
> set"; certificates are being created.

ok

> Slide 19: Why is the Dependents attribute set during a Create or
> Create Key Pair? If it is set because a key is always dependent on
> itself, the text needs to clearly state this.

precisely. will take into account.

> Slide 21: states "Denotes roles who have, or may potentially have,
> obtained the cleartext value of the given object". Does this also
> cover the case when an object is exported in wrapped format?

Yes. This was my oversight when I copied the SAC policy into slides. Thanks
for spotting that.

> Slide 23: As discussed during the f2f, we should not disallow the
> object to be registered if the digest value is equal to a registered
object.

The SAC was worked out with this assumption... One could reformulate the
SAC policy to incorporate this change, but this would require a fundamental
change in the design.

With the current proposal multiple objects with the same digest would be
allowed, but those objects could not profit from SAC policy.

> Slide 25: We cannot assume that a registered object is always used
> to derive a key. KMIP supports the HASH key derivation mechanism,
> which may derive a key by hashing the derivation data provided by
> the client (i.e., no registered object is being used).
>

will take into account.