Re: [Iot-onboarding] [Mud] Some new stuff for mudmaker.org

[Michael Richardson <[e-mail]>]

Eliot Lear <lear=[e-mail]> wrote:
    > So there’s one aspect that my early draft glosses over.  Great.  You
    > have a URL, whatever it is.  The manufacturer is likely to want to
    > authenticate you.  What’s the tooling flow?  I think it’s something
    > like this:

    > MUD URL picked up by mud manager
    > Mud manager retrieves mud file, dispatches URL of the SBOM to an SBOM
    > consumer of some form that we’ll just call an SBOM manager for the
    > moment.
    > SBOM manager resolves URL first time.
    > It has no token to use.

Let me ask clarification question:
  1) SBOM manager is an operator mechanism.
  2) talks to Manufacturer's server to resolve SBOM link to content

Then:
  - so manufacturer needs login to get SBOM content?

Query:
  - why is the SBOM private?  Cereal boxes print the contents.  There was a
        lot of moaning about this in certain sectors, but it clearly has been
        a good thing.

  - if I agree that SBOM could be private, the operator isn't the only entity
    that needs to see the SBOM.  The auditor needs to see it too.

    > User must register.  Requires a browser interaction of some form,
    > presumably with OAUTH.  Perfectly reasonable when the SBOM lives in the
    > cloud.  OR Token is received out of band for this service, either from
    > the device itself, or from the manufacturer service if one is
    > registered through that (requires browser interaction).
    > There is a token. Authenticate with that and retrieve.

But, I'll go with your belief that the SBOM is private, and can only be
revealed to entities that can proove they own the device.

Presumably, the firmware updates will also be available only under the same
criteria.  It seems that this needs to be solved *anyway*.  Certainly, big
BFR vendors that I know, don't let me have updated firmware unless can show
them I have a maintenance agreement.  If we are going to do automated
remediation with firmware updates (using SUIT of course), then we need that
relationship already, and so I think it would make sense to use the same
interfaces.

Now, if you did the onboarding with BRSKI, you'd have a voucher from the
manufacturer pinning the domain registrar with the serial number, and that
could be proof of ownership.  One could use the voucher as proof of
ownership.

How one maps the certificate that is pinned (the domain registrar cert), to
the general organization is a non-obvious mapping, but I can see relatively
easy ways to map things.
Further, if the vendor has strong supply chain integration, then they already
know who their operators are.

But, in less supply chain integrations, the MASA can record the TLS Client
Certificate (and CA) used by the Registrar, and this can provide a way to
build the same kind of database of operators.

This does require that the manufacturer do some coordination, and maybe there
are issues with outsourcing the SBOM server.  This sounds like OAUTH2, but
based upon the TXAUTH BOF, maybe it's not enough to easily do that without a
human browser involved, but it still seems solvable to me.

    > I am thinking that when a token is received out of band for access to a
    > resource, that is a generic exchange that goes well beyond this use
    > case.  Carsten, Hannes, do you have views on any of this?

I also think that maybe the SBOM URL could have some token in it.
That seems pretty brittle though.

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