RE: [kmip] Comments about access control proposal

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

Steven, Michael,

first, thank you very much for your excellent comments. I find them very
useful in bringing the AC discussion forward. Let me try to address some of
the issues you raised along with some related comments from Indra (my
intention is to address comments from Indra and Marcus in details
separately).

1) General reflection on Strict Access Control (SAC) policy in KMIP

The idea for defining SAC policy in KMIP stems from the possibility of
circumventing ACLs by exploiting the KMIP API and dependencies among keys
("API attacks").  I would like to reiterate that the intention here is a)
to define how a policy that prevents KMIP API attacks looks like and b) to
stipulate that SAC support will only be OPTIONAL.

In my opinion, it is very important that the future proposal for Access
Control in KMIP says something about the API attack issue. While, arguably,
these API attacks were not very much of an issue in existing enterprise
systems with smart administrators who can guard their master keys
"religiously", the KMIP picture seems somewhat different. We are defining a
standard that aims wide proliferation and potential use of many keys for
wrapping and derivation in settings that rely on different security
assumptions.

The reason for defining SAC as a part of the protocol is to say: a) this is
the problem that MAY arise if you are using the KMIP API and b) IF this is
a concern (cf. the "optional" clause for SAC) this is how one could solve
it without diving into the scientific literature.

Reaching a strategic decision concerning SAC is IMO vital for the AC in
KMIP. Once the TC reaches this decision, I am positive that the current SAC
proposal can be tweaked to improve on its technical aspects which are not
carved in the stone (a more detailed discussion follows).

2) On modifying object state in SAC on "read-only" KMIP operation

As both Steven and Michael pointed out, there are read side-effects in SAC
related to changing metadata, notably the attribute Readers. This attribute
acts as a sort of a filtered log, that records the users/roles that
accessed the plaintext of a given key that falls under the SAC policy.

Since client has no strong reason to read the Readers attribute and
likewise for Dependents/Ancestors, it would be possible to not expose those
as KMIP attributes. This would be a simple solution to read side-effects:
if Readers would not be an attribute, then Get object under SAC policy
would not change the object metadata.

However, the reason that Readers/Dependents/Ancestors are proposed as KMIP
attributes is that their values need to be bound to the key material along
with other attributes when a key under the SAC policy is exported in a
wrapped form. The use case here is exporting a key from one server to
another server (I admit this is not clear from the AC slides I presented,
but this was a conscious choice to keep the slides fairly simple).

To summarize: it is an open question whether Readers/Ancestors/Dependents
really need to be KMIP attributes of Managed Object. However, we need to
include those along with other attributes when a key is exported in a
wrapped form.

3) Dependents/Ancestors vs. Links

Dependents/Ancestors are not defined re-using Links, notably because they
encompass multiple Link levels, whereas Links point only to first level
ancestors/dependents, forming a dependency tree. On its own this is not a
satisfactory answer since one could compute Dependents/Ancestors from Links
(provided that we introduce additional Link Types for wrapping which are
not present in KMIPv1). However, the need for binding Dependents/Ancestors
to the wrapped key (see the use case mentioned in 2) ) makes the proposal
simpler to express with separating Ancestors/Dependents from Links.

4) on wrap/unwrap permissions and reusing Crypto Usage mask

As Indra pointed out, there is break in symmetry in the proposal, since it
contains "wrap" Object Permission, but not "unwrap". This is a valid
concern, with a simple answer: namely, there is no way to specify , in KMIP
language, on Register,  that the KMIP server should indeed unwrap the
object registered in a wrapped form; the protocol is underspecified in this
respect. That said, perhaps this is something we want to address already in
KMIP v1, and then include unwrap permission in SAC? (I would like to
underline that the research papers that form the basis for SAC already
envision unwrap permission so this will not be a quick hack).

On the other hand, wrap and unwrap exist in Cryptographic Usage Mask.
Reusing those is possible - the implication would be that this would allow
ANY user/role to use the keys for wrapping/unwrapping potentially creating
dependencies. Keeping separate object permissions for wrap (and, in
prospect, unwrap) provides finer AC granularity here.

Please keep the comments coming. Best,
Marko