Re: KMIP & EKMI Credential Bootstrapping

["Anders Rundgren" <anders.rundgren@telia.com>]



Hi Matt,
My personal reason for scanning certain lists and specs as well as putting "newbie" questions is because I don't believe I have monopoly on good ideas.

Regarding IP: it is close to impossible to know if there are any IPR in the stuff you find at home or on the web.  Personally, I find IPR on protocols as the best way NOT to succeed, so I publish everything that feels the slightest bit "novel" on

http://defensivepublications.org

including putting in a specific notice that I don't have any IPR claims myself (but of course somebody else could).

Device certificates is not a unique idea so KMIP should be able to use it if they want.  I'm going to publish the (unfortunately) probably unique enrollment concept that you get as a bonus so that anybody can use it without fear:

A side-effect of using certificate-based device IDs is that you can create efficient and still quite secure on-line enrollment processes where a non-authenticated user signs-up for credentials by sending an SKS-attested request to an issuer. The issuer can then verify the user’s identity with an OOB (Out Of Band) method meeting the issuer’s policy which can be anything from the classic “e-mail roundtrip”, to requiring the user to show up in an office with an identity card. The final part is asking the user for something like the first 8 characters of the 40 hexadecimal-digit SHA1 certificate hash which is the short-form of the device ID. If the answer is matching the device ID of the request, the issuer returns the completed credential package to the user’s SKS. Note that this scheme can completely eliminate enrollment passwords!

Air-tight provisioning is already published.  It is pretty cool idea but applying to a protocol is not trivial; it caused at total rewrite of KeyGen2 as well as requiring complete reprogramming of smart cards:

http://sourceforge.net/mailarchive/forum.php?thread_name=E39A6481FD734E9EA548052072D201A8%40AndersPC&forum_name=trousers-users

 

Many people would consider such requirement as fairly stupid but the fact is that I'm "fighting" with HTML5's <keygen> which is a really useless thing that the browser vendors have decided to make the *their* KM solution:

http://www.nabble.com/Re%3A-Smart-cards-and-the-%3Ckeygen%3E-element-p23876670.html

 

Actually, quite a bunch of the smart card vendors have indicated interest in air-tight provisioning.  It might be a better thing than JavaCard3 because it is very unclear why you need WS* inside a smart card while air-tight provisioning enables faster and cheaper ways of enrolling and distributing tokens.

 

enjoy!

Anders

----- Original Message -----
From: Matt Ball
To: Anders Rundgren
Cc: kmip-comment@lists.oasis-open.org
Sent: Thursday, June 11, 2009 23:20
Subject: Re: KMIP & EKMI Credential Bootstrapping


Hi Anders,

This message appears to be a suggestion that the OASIS KMIP TC adopt certain ideas.  Before the TC can consider these recommendations, you need to do one of these things:

Join KMIP as a member and agree to the IP Policy

Sign the "Feedback License" (see http://www.oasis-open.org/who/intellectualproperty.php#appendixa)

Without one of these two things, there's not much the KMIP TC can do with this information.

Thanks!
-Matt

Anders Rundgren wrote:
When you are about to perform trustworthy operations between different entities, authentication of the end-points is typically necessary.

It seems that KMIP (as well as EKMI) leaves the bootstrapping of end-point authentication credentials to somebody else to cater for.

Since this process is both highly device-dependent as well as generally difficult, KMIP interoperability may in practice prove to be quite limited.

As a comparison, my own brain-child, KeyGen2, builds on the fact that devices are shipped with a device certificate.
One may claim that KeyGen2 requires enhanced devices, and yes this is true!

The problem with not requiring enhanced devices is that "the tyranny of the least common denominator" will rule which is a stopgap to progress.  That is, the missing bootstrap may severely impede market acceptance.

Note: KeyGen2 does not compete with KMIP because KeyGen2 (deliberately) supports a very limited range of devices that are used by everybody (phones) but would be totally useless for storage.  I would if I were you consider "borrowing" the device certificate concept.

Properly implemented, all kinds of shared secrets and enrollment passwords are eliminated by device certificates.
If you are curious on how such a scheme could work you may take a peek in section "Dual-use Device IDs" in:
http://webpki.org/papers/keygen2/secure-key-store.pdf

thanks
Anders