RE: Entity: thoughts

["Pochuev,Denis" <Denis.Pochuev@safenet-inc.com>]

Mike,

Great summary and a cool story. Certainly helped my thought process.

I'd like to suggest a simpler use-case that we can also pick apart in our further discussions.

Here is how I understand the promise of interoperability, the big I in our favorite 4-letter acronym. 

Using your Sienar Systems example, suppose Sienar uses a key management server from vendor X. If, for whatever reason, Sienar is forced to use a server, from vendor Y, they can do so without much effort, provided that servers from X and Y interoperate. In a perfect world, Sienar would seamlessly backup keys and configuration on server x from X, restore it on server y from Y and continue as if nothing happened. This is fairly far-fetched. At the other extreme, server y, a perfectly compliant KMIP server, may have no support whatsoever for any user list/directory, no concept of key access control by different clients. This, of course, is discovered only after a big contract with Y has been signed and now Sienar engineers are forced to re-design their entire system.

I am wondering if there is something fairly concrete between these two extreme scenarios? If there is, is it possible to define it using means at our disposal? And finally, is Entity proposal the right context for this?

Regards,
Denis

-----Original Message-----
From: Mike Allen [mailto:Mike_Allen@symantec.com] 
Sent: Wednesday, September 14, 2011 11:39 AM
To: Tim Hudson; Pochuev,Denis
Cc: 'mbj@zurich.ibm.com'; 'indra.fitzgerald@hp.com'; 'judith.furlong@emc.com'; 'robert.griffin@rsa.com'; 'Lockhart, Robert'; 'Bruce Rich'; 'Wierenga, Steven (HPN/Atalla)'; 'Feather, Stan S'
Subject: Re: Entity: thoughts

Hi all, not a lot of discussion on this topic this week, but I have been
doing some thinking I wanted to share.

As Tim correctly pointed out, in order to accommodate the use cases we
brought up last week, having an Entity object doesn't really help (or
hinder).  When I think about what we discussed, I feel like other
solutions would be better suited than using KMIP.  For instance, if I want
to do disaster recovery, likely I already have some mechanism in place to
pull my key database from one data center and transport it to the backup
center.  If I am doing DR for myself, then likely both of these key
servers are from the same vendor and will have the same format used to do
these kind of database dumps.

Building generalized administration clients via KMIP for any kind of KMIP
server sounds like a nice idea but not, I think, where our customers feel
any pain such that developing these clients would be interesting to them.
I also have the feeling that such generalized admin clients would always
be four steps behind the specific administration console developed by each
vendor.

So what use case might actually drive us to really *want* KMIP doing
communication between two servers?  It would have to be something that met
something like this list of criteria:

 * The two servers are from different vendors
 * The two servers need to exchange keys on an on-going basis
 * The two servers need to exchange a *lot* of keys using an automated
process
 * The servers need to respect whatever permissions and limits are
appropriate for the given use of a given key

Any others that people can think of?

Off the top of my head, I can think of one story that might fit all these
criteria, but I don't know if it's a real world pain point or not.  I'll
write it here, and then maybe we can pick it apart and brainstorm other
ideas and/or criteria on our call tomorrow?

--------------------------------

Imagine I am the email administrator for Sienar Systems, a 10,000 person
Internet company.  I am responsible for, among other things, backing up
our email archives to tape, for which I have purchased a very nice LTO4+
tape system matched with backup management software that has in it key
management capabilities so that I can encrypt my tapes individually to
different AES keys.

Suddenly Sienar is embroiled in a huge lawsuit.  The legal discovery
requirements for this lawsuit apply to the encrypted tapes in my
possession.  Sienar decides that rather than spend my time to decrypt all
the data, they are going to outsource the problem to a firm that
specializes in indexing and sorting through these sorts of documents for
lawsuits, Theed Legal Discovery, run by Tim Hudson.  Tim's company has
tape drives that can read my tapes, but a totally different software
system in front of them with a completely different key management server.
 

In the idealized world of vast KMIP adoption, Tim and I talk on the phone,
agree on some basic credential details, and I set up a process whereby I
can export my keys from my server into his.  My keys are marked in such a
way that they can only be accessed within Tim's server when Tim is doing
work on my behalf.  I also ship off my tapes to Tim's company.  Tim uses
his software to decrypt the tapes (with my keys), read the data, and
provide indexes and other digested data back to Sienar's lawyers.

In order to perform such an exchange successfully, I think I'm going to
want to request that entities be created in Tim's server that have
ownership permission over my key material.  Tim wants to be able to pass
audits that attest to the fact that all of Tim's work with cryptographic
keys is segmented by customer with strong permission systems enforcing
that.

--------------------------------

Thoughts?


-= Mike =-
________________________________________

Mike Allen
Sr. Technical Director, Symantec Corporation
www.symantec.com <http://www.symantec.com/>

________________________________________
Office: (650) 527-0716
Personal Mobile: (415) 699-0106
Fax: (650) 527-1984
mike_allen@symantec.com

________________________________________








On 9/8/11 9:02 AM, "Tim Hudson" <tjh@cryptsoft.com> wrote:

>I simply see "entity" as a code word for tackling the various different
>problems
>we discuss in and around the previous entity proposal.
>
>We talked about two (potential) drivers on the call:
>1) administering a KMIP server using the KMIP protocol
>2) exporting/importing state from one KMIP server to another KMIP server
>
>These are both interesting problems to look at tackling and I think very
>little
>to do with some of the drivers discussed in the past for having Entity
>represented as an object within KMIP - however it may indeed be part of
>how to
>solve it.
>
>As an example of this point there are many different ways we could solve
>item 2.
>
>a) do nothing; we can already export keys in plaintext and wrapped and we
>can
>locate all the objects that a user has permission to see and can represent
>different permissions using the TLS client certificate and a
>username+password
>on top of that if desired.
>
>b) introduce two new operations Export and Import which perform
>serialisation in
>a vendor-specific format. It would solve the issue being raised as the
>problem
>but doesn't get involved in or tackle the concept of cross-vendor
>serialisation
>of everything required.
>
>However I do think we need to settle on what problem we are trying to
>tackle
>separate from the solutions being proposed until we reach a consensus on
>what
>the scope of work is.
>
>I also think it is important to keep in mind just how wide this problem
>is if we
>move beyond just the value and attributes associate with an object. Case
>in
>point is the usual PKCS#11 with HSMs - the mechanisms used for solving
>this
>problem are in general vendor specific - and there is no concept of being
>able
>to serialise state from one vendor's HSM to another vendor's HSM.
>
>Tim.
>

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.