[Iotops] assemblies and onboarding and 802.1AR device identity

[Michael Richardson <[e-mail]>]

Eliot Lear <[e-mail]> wrote:
    >>> I’d like to take that latter case off the table, but then we need to
    >>> seriously think about RATS or SUIT providing a standard protected TLV
    >>> list that deployments could receive through a standard interface.
    >>> These are attestations of a form, but they’re not really
    >>> measurements, as has been previously discussed here.
    >>
    >> Can you give me an example of one of these attributes?

    > Soooo…. Here’s an example:

    > Suppose I am a system integrator who needs to assemble a device out of
    > constituent components that includes a particular software load.  I
    > wish to claim to be the manufacturer of the device, as I am the one
    > producing the final product.  I want to therefore provide the
    > onboarding service.  That requires a change of URL for the MASA in
    > BRSKI terms.  I may also wish to change the MUD-URL based on the
    > software load.

    > The core question I am asking is this: we have attributes about the
    > device I these certificates that really could be elsewhere.  But where?

It seems clear that the assembler needs to create a new IDevID, and they need
to store it somewhere, and it needs to express itself rather than the
individual components.

It seems to me that if one can effect to load a particular software, then one
ought to have control via that software load of the onboarding and which
IDevID is expressed.

Remembering that we invented multitasking because CPUs were very expensive,
leading eventually to virtualization and containers, but that most of our
security issues are the result of sharing of resources, I suggest that maybe
the answer here is to stop sharing when doing an assembly.
The "control plane" CPU for the assembly doesn't have to actually do any of
the work other than coordination and onboarding.

That having a $3 ATMEGA MCU hold all of the desired upward (for onboarding of
the assembly) and downward (for keeping track of the onboard components)
might make the most sense.
I don't think that's a big cost for an assembler if the assembly is worth
thousands to fractions of millons.

(I come back to the bogie assembly for a railcar, which has got to be worth a
fair bit.  Also: airplanes and cars.
However, we should think about smaller assemblies as well, including things
like a desktop computer's CPUs, GPUs and MCUs in keyboards and hard disks.
Component stereo/AV systems in homes and in theatres.)

I'm not suggesting this MCU is an active Registrar, but rather, it's the
like it's the TPM/CA for a Registrar component that the assembler brings into
the do work stuff out.  A tool if you like.

So, it would store the credentials.   It's a superset of the KDC.
(insert storey about KDC that was drywalled in, but kept operating for years)

I would propose we think about the commonalities among onboarding solutions
(upward and downward), and probably we need to write a YANG module to explain
it all.   We should consider that one might use DPP to onboard the components
of an assembly, which then uses BRSKI to join a superior assembly, and that
superior assembly then uses FIDO-DO to be deployed.
We need to take into account Kerberos, OAUTH2/GNAP and ACE operational keys.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide