RE: [kmip] Comments about access control proposal

["Wierenga, Steven" <steve.wierenga@hp.com>]

Michael,

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.

 

Thank you,

--Steve W.

HP

---

From: Michael Allen [mailto:mallen@pgp.com]
Sent: Tuesday, March 09, 2010 5:38 PM
To: kmip@lists.oasis-open.org
Subject: [kmip] Comments about access control proposal

Hi all, I had some thoughts about the access control presentation that Marko put together for us for the face-to-face.  Marko, thanks for doing that, by the way, getting these ideas down on paper (or in PowerPoint at least) really helps us move the standard forward and isn't easy.

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