KMIP -- An Important Standard

Sorry to be late on this post, but I thought it worth some commentary as to why this particular standard should be tracked by IT infrastructure professionals everywhere.

Now, I always tell people to put aside their "standard skepticism" when discussing industry standards, and I always have to make a case as to why the topic of discussion isn't JAS -- Just Another Standard.

Chuck's Informal Criteria For Standards

In my world, the important standards have three key attributes: (1) they solve a really big customer problem, (2) no one vendor can solve the problem by themselves, and (3) the right vendors are working together.

Such is the case with KMIP -- the Key Management Interoperability Protocol.  It solves a big hairy customer problem, no one vendor can provide a complete solution, and -- at least in this case -- IBM, HP, EMC and others have come together to drive an important interoperability standard.

The Storage Perspective

I got somewhat involved in this topic a few years ago when EMC acquired RSA (now the security division of EMC), and many of us started asking hard questions about encryption, keys and management.

The first (and inevitable) debate was "where was it best to encrypt storage?"  It's not too hard to come up with good arguments about putting it in the SAN, or putting in the devices themselves, or putting it in the HBA, or in the MPIO stack, or in the file system, or perhaps the application itself.

We quickly became comfortable in the view that storage encryption was going to be available up and down the I/O stack, and it would be hard to make the case that there was one "best" approach.  Indeed, as we look at EMC's portfolio today, there are multiple places to encrypt your data, depending on your needs.  I know, it's yet another "it depends ..." argument.

Interestingly enough, while we were having this internal debate at EMC, NetApp went out and acquired Decru. 

At the time, we were of the collective opinion that the dedicated encryption appliance business wouldn't be around very much longer -- encryption would simply be a feature of other products in the stack.

I guess this view has come to pass -- we haven't heard much from the Decru part of NetApp for quite some time.  My guess is that it will eventually suffer the same fate as Topio -- no real market.

More recently, certain storage vendors have tried to put forth the idea of encrypting at the disk drive and/or array level.  It sounds like a nice feature in the abstract, but the more you think about, the less useful it begins to seem -- especially as you start to think about the pros and cons of doing it in other places -- like in the MPIO stack, for example.

The second debate was around key management.  RSA had a key management appliance known as RKM (RSA Key Manager, naturally), so we started to take a close look at how it could play in the enterprise storage environment we knew so well.

Over time, we started to realize that key management -- taken by itself -- wasn't a particularly interesting capability.  Certainly necessary, but there was definitely a need for more -- specifically, the ability to seamlessly orchestrate keys and key management as part of day-to-day operations -- at least, in the storage domain.

The classic example was a disaster recovery test.  Imagine thousands of volumes being replicated to a remote site (each encrypted) and imagine you'd like to do a recovery test over the weekend.

Many thousands of keys would be involved at a minimum.  Not only that, the upper-level management applications would ideally be able to request and receive these enormous key sets as a part of their normal operations.

Or consider provisioning secure virtual machines in a multi-tenancy environment?  You'd want to provision the app and its storage in one fell (and keyed) swoop.  Certainly an opportunity for upper-level integration, no?

There were dozens of other similar real-world examples we could come up with -- scenarios where management processes and related software needed to be taught how to request and manipulate encryption keys as part of their normal functionality.

Didn't it make sense to focus our efforts on this sort of upper-level key integration, rather than thinking in terms of a black box that managed keys?

But ut was clear that a standard was needed, right?  We couldn't assume that only EMC were producing all the required keys, or that it was only EMC software that was managing the keys.  The real value appeared to be in the area of orchestrating key management as part of an upper-level IT process.

More on KMIP

Standards efforts seem to range from "that'll never see the light of day" all the way to "that's not too hard to do".

I'm no expert, but the people close to the KMIP effort at EMC tell me that this particular standard is not hard to implement, nor is it that far off from existing implementations in the marketplace.

Maybe it's too easy -- how else can we explain Sun's recent obfusticating move of tossing their proprietary approach into the open source pool?  My guess is that the legacy STK part of Sun's business saw a standard that didn't help their business model, so they did what they could to slow things down.

I don't think this particular manuever is going to work for them, though.

Regardless of Sun's (STK's?) concerns, I'm guessing that we'll see reference implementations of KMIP before too long.

And then we all can get on to the serious business of integrating key management into the rest of our IT management processes.

Comments

[Alex McDonald]

"Although NetApp wasn’t in the press release that hit the news wire, we [NetApp] fully support this new standards effort, and we are a contributing member of the OASIS KMIP Technical Committee."

http://blogs.netapp.com/standards_watch/2009/02/kmip-a-proposed.html

[David Jones]

Hi Chuck,

Down here in the SAN administrator cellar we see very little of this Key Management Interoperability Protocol. Or indeed any standard when it comes to managing storage at a basic level, never mind encrypting the stuff.

There is not one single application that will manage our storage arrays, not one product that will allow a holistic view of the entire SAN environment. ECC barely works for Symmetrix, is a bloated mass of agents, and is rarely accurate. So excuse me if I am cynical of allowing encryption of a data between storage array to be managed by any application produced by any large storage vendor.

Into open standards when it suits, a closed shop for everything else.

Regards,

Disgruntled SAN Buyer.

[Chuck Hollis]

Hi David

Sorry to hear you're frustrated.

What vintage are you running of Symmetrix and ControlCenter? It's often the case that frustrated SAN administrators are running 5-6 year old product, and haven't been able to upgrade their software, let alone their hardware.

ControlCenter, in particular, is an entirely different animal these days if you haven't seen a recent version. And, yes, prior versions from years back had problems with how they used agents.

I'd be frustrated as well!!

So -- who do you work for? What vintage equipment and software are you running? I can kick it around here and see if there's something simple and easy we can do to make your life better.

Regardless of whether you end up using RSA or HP or whatever to manage your keys, you'll end up using (trusting) someone for this role.

Or not -- it's not a foregone conclusion that everyone will need to encrypt their storage environment.

Especially people running really old stuff :-)

-- Chuck