> On Aug 9, 2019, at 11:16 AM, Michael Richardson <[email protected]> wrote:
>
>
> Kent Watsen <[email protected]> wrote:
>>> But, more interestingly, it can be used to update the trust anchors, to
>>> enable a resale/transfer of ownership!
>
>> But, seriously, no. It's expected that decommissioning will returned a
>> device back to its factory default state. No manufacturer will agree
>> that it is anything other than the state of the device when it was
>> manufactured. Anything other than that could be leveraged to mount an
>> attack. Change in ownership-assignment needs to occur through some
>> other means, of which there are many but, in the end, if the 2nd-owner
>> cares about the security (not just the convenience) of bootstrapping,
>> then they are strongly advised to purchase never before used
>> equipment.
>
> This is indeed the tussle the BRSKI document has been dealing with
> in its IESG review. If we can't change the trust anchors used to verify
> the voucher, then how can the device be onboarded after the MASA
> has gone away?
Oh, wait, my prior response wasn't wholly accurate.
The factory default state reflects zero remnants, but it doesn't necessarily
mean the same OS-version as the day the device left the factory. Many devices
don't have enough NV storage to keep the original OS forever, not to mention
that it would be rather silly as, better, would be to keep what's considered
the last known-good OS image (which may not be the same thing). Many devices
will effectively overwrite the previous OS image ("don't touch the power button
during install!") and thus what happens when pressing the "reset to factory
default" button is a reflection of what "factory default" means to the new OS
image. The good news is that new OS images can contain new CA certificates,
for authenticating well-known services (e.g., MASA, OVIS, etc.). What cannot
change is the IDevID certificate (LDevIDs are wiped).
Of course, all this assumes the manufacturer is still around to release OS
updates, but this is simply part of the business decision that customers need
to consider when purchasing equipment. The probability of a successful
bootstrap shortly after fresh purchase directly from the manufacturer is very
high, but lowers over time as risks around businesses going belly-up start to
creep in. A device sitting on a shelf for a decade, or devices bought on eBay,
may not bootstrap without an OS upgrade.
None of the above reflects how to support change in ownership, though. A
device reset to factory default has no "owner", just some trust anchors that
can be used to verify an entity claiming to be its owner. What backend
sale-channel integration or customer-handoff protocol might be used to support
change in ownership is out of scope.
> I don't understand how RFC8572 slipped through the IESG without resolving
> this.
Perhaps because BRSKI leads with ephemeral vouchers and hence the need for
online MASAs (with offline support tacked on the side), whereas SZTP leads with
optional use of vouchers but, when used, they're mostly non-ephemeral and
accessible at time or purchase (with ephemeral voucher support tacked on the
side). The shift in emphasis begs the question, so they're asking it. Still,
it seems more like a customer/business issue than something IESG should worry
about.
Kent
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
