Eliot Lear <[email protected]> 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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
