Subject: [Emu] Fwd: New Version Notification for draft-lear-brski-pop-00.txt

From: Eliot Lear <[email-masked]>
Date: Sat, 20 Oct 2018 16:42:24 +0200

As promised, here is a draft that attempts to wangle BRSKI to allow for
proof of possession tests.  This is very early work and intended for
discussion at this point during OPSAWG and at the side meeting we have
scheduled for Tuesday night.  If people like what they see, we can
discuss in more detail in Prague.

This draft includes three specific test types, one of which may come out
Real Soon:

 1. The registrar has obtained proof of possession and provides that
    proof to the MASA.  This solves a wireless case.
 2. The registrar has obtained proof of possession and, rather than
    providing proof to the MASA, provides proof to the pledge (two-party
    instead of three).
 3. The registrar tells the MASA, “Trust Me!  Really!” in its best Joe
    Isuzu voice*.  (This may be redundant, which is why it may come out.)

Discussion points:

  * The basis of all of this work is really that Max, Michael, and Kent
    did a bang up job by coming up with the voucher concept, and so
    let's all agree PLEASE that no matter how we slice it, a voucher
    request needs to be generated, and a voucher response needs to be
    delivered.  The means for proof, and even the identity returned, can
    be stretched.
  * Should we stretch further, and include different keying material
    objects?  I'm CCing EAP folk because that is a big fat question for
    them.

Eliot

* See https://www.youtube.com/watch?v=mR361ASrMew

Subject: New Version Notification for draft-lear-brski-pop-00.txt
From: <[email-masked]>
To: Eliot Lear <[email-masked]>, Owen Friel <[email-masked]>
Date: Sat, 20 Oct 2018 07:30:01 -0700

A new version of I-D, draft-lear-brski-pop-00.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:		draft-lear-brski-pop
Revision:	00
Title:		Proof of Possession to Devices for Onboarding
Document date:	2018-10-20
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-lear-brski-pop-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lear-brski-pop/
Htmlized:       https://tools.ietf.org/html/draft-lear-brski-pop-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lear-brski-pop

Abstract:
   This memo specifies a RESTful interface for local deployments to
   demonstrate proof of possession to a device or to a manufacturer
   authorized signing authority (MASA).  This covers the case where a
   MASA would not otherwise have knowledge of where a device is
   deployed, or when a MASA may not be required.  Such knowledge is
   important to onboard certain classes of devices, such as those on
   IEEE 802.11 networks.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Oct 2018 14:15:04 -0400

Eliot, thanks for this document. If nothing else, it means that
we BRSKI authors can deal with some review comments by pointing to "future
work" :-)

(A)"request-voucher-with-possession" <-- what about intent to traffic? :-)
  (for those that don't get the joke:
  https://criminal.findlaw.com/criminal-charges/possession-with-the-intent-to-distribute.html )

if leaf out-of-band-claim to be set by the PLEDGE?
I think it is set by the Registar?

The document sadly ends too soon...

You say it is trying to do a few things.
  1) deal with middle value pledge,
     (and low-value pledges in very congested places)
     where an out-of-band supply-chain integration is unavailable,
     and the MASA has a any-registar policy for the device.

  2) provide a ship-and-forget mechanism.

It seems that the cryptographic POP mechanism is an ends to accomplish a
means, rather than a core goal of the protocol.    The Pledge already can
sign it's voucher-request, and since it includes the Registrar's key when it
does a proximity assertion, it's pretty good proof of possession for the
*Registrar*, but it might provide inadequate assurance to the MASA of it's
freshness.   If the MASA could provide a nonce for the pledge to sign
(requiring another round trip, and even more online assurance), that would
provide even more proof.

Given that you pushed this out before today's cutoff, I am not upset
that there is so few details.  I am suspecting that in your thinking that you
created the three objects, and realized that could accomplish
"ship-and-forget" using a combination of them?

I also wonder if cryptographic-POP is being confused with "proof of
ownership", which I think is what you really want to accomplish.

If one assumes some machine readable (QR) code that comes with the product,
then there are a few things one can do to differently.  One of the things
that I have thought a lot about is that one uses the printed code in the
Registrar to establish a relationship with the MASA.  That is, one creates
the supply-chain-integration by using the QR code with some zero-knowledge
proof (I think that PAKE is the latest one) to establish that one is the
legitimate Registrar for the product.  One can do this as *any time*
(some mumble about the lifetime of the CA of the Registrar's key), and
the product will be enrolled correctly at any future time.

About my joke (A) above, I think that ship-and-forget is an interesting
goal, and in particular, if also may enable desireable "traffic"ing.  That
is, if the manufacturer can transfer the product to my ownership without any
online interaction, then presumably, I can also *resell* the device to
you using the same lack-of-interaction?

====

   > In addition, some manufacturers may prefer not to require the
   > existence of a MASA.  In these circumstances proof of possession to
   > the device is required.

I would prefer that we split this into a different draft.

I am very concerned that ship-and-forget is not a desireable property
in the IoT space.  It essentially means that the manufacturer has no further
interest in providing any kind of updates for the device.    I have serious
cybersecurity concerns about such devices being out there (sitting unpatched
and untracked in a warehouse somewhere), as well as significant environmental
concerns about devices designed to die like this.

I am trying to think of devices where this makes sense.  I come up with a few
things: single-use medical devices (like bandages, syringes, etc.),
prophylactics and other single-use sex toys,  things you eat, and some
variety of devices that might be called "spy craft".  In each case, I'm
having difficulty knowing what the "smart" aspect of the product is, other
than simply tracking it's existence and current stocking location. A smart
package containing a dumb device is a good idea, but it seems like something
that would be better recycled, and in any case, it's not ship-and-forget
for the packaging.

So this is why I think that splitting ship-and-forget mechanism into another
document would let us treat it better.  In particular, I want to know who is
going to deploy using such mechanisms, and if they are at the table now.
I guess I shall add a slide to my ANIMA BRSKI stack about this in an attempt
to get feedback.

I suspect that there is a category of devices that some think of being
ship-and-forget which might actually be ship-to-holding-company.
Holding company leases to end user for period of time.  End user identity
is never communicated back, and might be very much pseudonymous.
I'm thinking about car-rentals, hotel rooms (full of devices), ...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Oct 2018 20:44:19 +0200

[Christian, read down a ways]

> I think it is set by the Registar?

In all cases, any out of band claim has to be collected by the
Registrar.  It is possible that having received such a claim from the
Registrar, the pledge forwards it along to the MASA.

> The document sadly ends too soon...

Gosh.  You want it all at once, don' you?!  Become an editor ;-)
>      and the MASA has a any-registar policy for the device.

Yes.
>   2) provide a ship-and-forget mechanism.

Yes.
> means, rather than a core goal of the protocol.

I never employ hashes just for fun ;-)

>     The Pledge already can
> freshness.

I think this covers the Joe Isuzu case that can fall out of the draft,
and maybe one other.  The fundamental issue with the others is that the
Pledge needs some reason to believe that it is really on the correct
network.  Proof of possession can come in several forms, depending on
the device, but we're assuming that there's no user input to the device
available (e.g., no buttons, to touch screen, etc).  It could also be
that the Pledge really doesn't want to validate proof of possession by
itself.  In that case, there's no reason for the pledge to even know the
proof of possession.

>    If the MASA could provide a nonce for the pledge to sign

That's part of the thinking, yes.

> ownership", which I think is what you really want to accomplish.

We can have that discussion .
> the product will be enrolled correctly at any future time.

Good point.  One possible thought in terms of the evolution of this work
would be “More stuff you can do with vouchers” with a plethora of
documented uses.  Or we might want to spawn a few more drafts.  Again,
worth discussion.

> you using the same lack-of-interaction?

Yes.  In fact that is a goal that I think both Christian and Randy have
motivated.  I would want to explore a bit whether or not to split out
ship and forget, but I would rather we tried to solve for that problem
because it really is here (see below).
> concerns about devices designed to die like this.

It could also be the case that the device is intended to be deployed in
disconnected environments.  I also think it's going to be a little while
before certain classes of manufacturers will seriously be able to run an
online MASA.  And I would like them to at least be able to consume a
voucher, even if we need different sorts of transfer approaches.

> I'm thinking about car-rentals, hotel rooms (full of devices), ...

Let's discuss further.  Looking forward to the Tuesday 6:00pm Side meeting.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Oct 2018 15:54:34 -0400

{cutting CC of people, and we need to pick a WG list to discuss this on?}

    > itself.  In that case, there's no reason for the pledge to even know the

https://en.wikipedia.org/wiki/Joe_Isuzu  ... I asked google, and I'm not
quite sure I get the connection.

    > voucher, even if we need different sorts of transfer approaches.

It's not enough to say that they are going to be deployed in disconnected
environments.  It's that they one wants to drop-ship them from the
*manufacturers* warehouse to the disconnected location.

When one thinks about drop-ship to a disconnected location, one tends to
think about containers of humanitarian AID going out the back of a aircraft
(C-2, Hercules, etc.) with a parachute.   If anything, that situation is
probably *NOT* the case we are thinking about, because in that case the kit
would have already gone through the owner's warehouse (whether the owner is
a UN aid agency, some FEMA equivalent).  The entire kit could have been
onboarded (wirelessly) as it went *onto* the aircraft, or could even occur
as late as when it's on the aircraft.

And you said, "online MASA", when it could well be that it's an offline
MASA.  If you buy enough product, the manufacturer could well just put
a custom trust anchor in and give you the private key.  That's essentially
what happens in Industrial 4.0 802.15.4 deployments today.

So I'm saying, let's not invent a problem before we understand who actually
has the problem.... and make sure that the people who can solve the problem
are at our table.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Oct 2018 13:26:40 +0200

Hi Michael,

> quite sure I get the connection.

Sorry- this was a reference to an earlier message.  There is a mode in
which the MASA is acting based on its relationship with the registrar. 
The punch line with Joe Isuzu was “Trust me!”
> *manufacturers* warehouse to the disconnected location.

There are quite a number of use cases where connectivity may be an issue:

  * A secure building, where Internet access is limited, and even
    carrying in a USB stick is problematic.  This can range from a
    military installation to a pharmaceutical laboratory, to certain
    departments of financial institutions.
  * It could simply be an order of operations matter, where the device
    has arrived in advance of Internet connectivity but still wants to
    function (think fire suppression systems).

You may say, “but onboard them advance of their deployment”.  That may
or may not be practicable.

> as late as when it's on the aircraft.

I think we're get a better feel for some of this as time goes on, but
one could imagine components sitting in a drawer for five years. 
> what happens in Industrial 4.0 802.15.4 deployments today.

I certainly know manufacturers who do that, and they mostly hate it,
because it requires custom builds.

> has the problem.... and make sure that the people who can solve the problem

This sounds like an EXCELLENT conversation for the next few weeks.

Eliot

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima