Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Eliot Lear <[e-mail]> wrote:
    > I think the simplest way to address the bulk of both Adam’s and
    > Warren’s concern is to require the device to emit via whatever
    > management interface exists, upon request, a voucher that it has signed
    > with its own iDevID.  It would have to be nonceless with perhaps a long
    > expiry, and that would cover a number of other use cases as well.  That
    > way if the manufacturer goes out of business, or if the owner wants to
    > transfer the device without manufacturer consent, there is a way
    > forward.

1) would it have a pinned-domain-cert for the new owner, or would it be
   some kind of wildcard/bearer voucher?

2) what would the management interface be, specifically, how would it be
   secured?

This would seem to cover the case where there is an orderly sale of equipment
From an owner who is still in business to a new owner who is ready to receive
the device.  In my experience buying used routing equipment, this is never
the case.

The best case is that equipment was removed from active service 6 to 10
months previously, stored somewhere until it was certain that no spares would
be required, and then sold on eBay directly to the buyer.

Creating this new voucher would require that the sellor spin the systems up,
hook them back onto some management interface (which effectively means going
through the onboarding process again, since their IP addresses will be wrong,
having been replaced), and then getting a voucher issued for the buyor's
domainID.   Is this ridiculous? No. Knowing that the systems boot (and
haven't rotted), and knowing that the old configurations have correctly wiped
is pretty good hygiene.

Often the systems are purchased by a used equipment broker, and having the
broker issue an intermediate (could be time limited) voucher to themselves
would be reasonable as they take the systems into their inventory.  In larger
sales, the broker could provide personnel to do the spin-up at the sellor's
location.

The sellor *could* generate that voucher themselves before the device is
taken offline, linking the voucher to a newly generated domain owner
keypair.  This effectively is now a bearer voucher.  At which point one could
consider some other kind of existing technology: a TLS session resumption
ticket (issued by the BRSKI client to the Registrar) might make more
sense. It has all the properties of a bearer voucher, and all the risks,
but is well established mechanism.

I would be happy to start a draft that explained this process.
It's something that I wish we have a SEC-AREA BRSKI WG to make sure we get
this right.

In the worst case, the reason the equipment is being sold is because the
sellor went into bankruptcy.  There is no sellor Registrar to invoke this
API.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-