[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Comments about access control proposal
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]