Re: [kmip-comment] Re: KMIP & EKMI Credential Bootstrapping

[Robin Cover <robin@oasis-open.org>]

We appreciate all contributions to this KMIP TC Comment List -- please
keep them coming!

As to: http://lists.oasis-open.org/archives/kmip-comment/200906/msg00002.html

One detail in that posting (below) requires correction, lest someone be
misled. It was suggested that the KMIP TC could not consider or adopt
recommendations made in the posting(s) by Anders unless he: (a) joined
the KMIP TC, *OR* (b) signed the "Feedback License".

That is not accurate, although it's truthful in principle.  The TC
comment lists are set up to ensure that postings made to these lists
(and archived for public record) are indeed covered by the relevant
OASIS IPR policies (for patent and copyright).

One cannot post to a TC comment list without first subscribing, as explained
in the text for "Providing Feedback", via the link "Send A Comment"
http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=kmip

One step in the subscription process requires the subscriber to
confirm acceptance of the terms of the OASIS Feedback License:
by sending a Reply message to confirm subscription, the subscriber
clicks-through the agreement, effectively (by performative gesture)
ensuring that all comments posted to the TC comment list are
contributed under the terms of the license.  The message from
the ezmlm subscription manager will say:

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

Confirmation is necessary to verify your email address,
to assert your acceptance of the list's submission terms,
and to protect the list against spam.

By confirming your subscription request, you:

  a) acknowledge that your postings to the list will be
     publicly archived;
  b) agree to the terms of the OASIS Feedback License
     as printed below and located at:
     http://www.oasis-open.org/who/ipr/feedback_license.pdf

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

and the text of the Feedback License is printed in the message
to which the subscriber sends Reply.

So: Anders is already covered!

He is invited to join the KMIP TC, but his contributions to the TC
via the KMIP comment list can be considered (safely) without
his joining or sending in a literal/verbatim agreement.

Best wishes,

  - Robin

Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
Staff bio: http://www.oasis-open.org/who/staff.php#cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783


On Fri, 12 Jun 2009, Anders Rundgren wrote:

> 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