RE: [kmip] Comments about access control proposal

Hi,

I took another quick look at Marko's proposal. Please see my comments below.

Michael made some valid comments. I do agree that we may need to re-evaluate what exactly we are trying to achieve.

Michael, BTW I think the reason why Link was not reused is because the attribute rules for Link are not the same as for Dependents/Ancestors.

Regards,

Indra

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

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

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

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?

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.

Slide 10: The wrap permission only covers key encryption. What about for signing and MACing? Do we need to include the unwrap permission? During Register an object may be registered in wrapped format. The user should have permission to access the key wrapping key. Alternatively, instead of defining wrap and unwrap, could we just re-use the Cryptographic Usage Mask?

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.

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

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.

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?

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.

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).

You raise some excellent questions, and likewise, I claim no particular insight or authority and mostly stay in listen mode.

I tend to agree that simple reads of keys should not change key metadata state and should not be specified to do so in the protocol. Accesses/actions by clients and adminstrators should always or often be logged, but they should not necessarily change the object state. For example, if I as administrator view a key name, that should not change the key state, or even necessarily be logged. Client/server activity logging is an excellent alternative to complicating KMIP messaging and conformance.

Log/activity monitoring is an important aspect of any operational security controls. KMIP should not attempt to predict/limit/control what types of API attacks or legitimate accesses are possible; that belongs in another controls layer. We do not need to solve all possible problems in the KMIP spec.

I would agree and prefer re-using the KMIP Links, if possible, to support the proposed Ancestor and Dependent attributes.

I agree that Conformance requiring any particular Server Policy is problematical. KMIP should be supporting various user policy controls; end-users should be controlling their specific securioty Policy settings.

As I read through it, the basic access policy made a lot of sense and seems relatively straightforward to implement. The strict access control policy, though, I have some concerns about. While I think it would address the problem at hand (confounding the so-called API attack), I'm wondering if that's a problem worth us solving in the protocol itself.

The API attack as described in the presentation goes something like this (and fill in any blanks where I get things wrong, TC experts!):

User Bob has permissions to use symmetric keys SK-WRAP and SK-TAPE-ENC.
Bob requests the key material of SK-TAPE-ENC encrypted to SK-WRAP in order to store it on the tape that was encrypted with SK-TAPE-ENC.
Later on, Mary is granted permission to read and use SK-WRAP, but not SK-TAPE-ENC.
However, because Mary can get to the physical tape itself, she can get the encrypted copy of SK-TAPE-ENC and decrypt it using SK-WRAP.

The attack scenario here is one where the system grants permission for a user to see and use one key without understanding its relationships to other cryptographic material in the same system. Marko's proposal details a solution to this problem that involves tracking which roles have read which keys under particular circumstances, so that the security system can make particular assertions about who should be able to read keys.

The solution presented has a couple of things right off the bat that I find a bit weird:

Reads of keys are causing writes of meta-data. If I read a key under the SAC policy, then my role gets recorded on to that key (and its descendants?) as a "Reader". As an implementor and user of a KMIP-like system, I don't expect that reading material alters anything about that material I'm reading. I do understand why the proposal has that, as it wants to do security assertions later about who read things, but again, the fact that reading keys causes writes on the server strikes me as a scalability issue.
The Ancestor and Descendant notions are attributes of the keys, but they feel like specializations of the Link object already in the system. Rather than inventing new types of meta-data, couldn't we reuse the Link concept here?
This is the first instance of KMIP defining a policy that conforming servers must enforce. Without a more comprehensive look at what kinds of other policies we would want to put into something like this, does it make sense to have this instance be our first foray into that realm?

It strikes me that this concern might not be a real-world worry. I would love to hear from the rest of you how often this attack might really happen against known use cases. As I think about it, if you have a symmetric key like SK-WRAP above, you would guard who you handed it out to rather religiously (i.e. with much ceremony and pomp). As an administrator of a key management system, you've probably given Bob access to SK-WRAP because he, as a high security officer-type person, needs to have access to all the keys on all the tapes so that he can recover their material in case of a disaster. You're not going to hand that access out willy-nilly. If Mary gets access to SK-WRAP, she probably has it for a reason.

In KMIP, you can basically ask for any key to be wrapped under any other key. Maybe *that's* the security assumption we should be looking at to attack this problem. Do we need to have some notions about which keys are allowed to wrap others, and who can perform those operations, rather than trying to solve this rather more tricky problem of tracking who has read what?

Thanks, I'd love critical feedback about my thinking here. I've been kind of quiet on the calls so far, as I was coming in at the tail-end of the 1.0 spec, so if some of my questions have already been discussed, please let me know.

- Mike

Michael Allen

Sr. Manager, KMS Engineering

PGP Corporation

mallen@pgp.com

650-319-9071

Michael Allen

Sr. Manager, KMS Engineering

PGP Corporation

mallen@pgp.com

650-319-9071

kmip message