Hi, I read draft-moran-suit-mud today. It would naturally fall into a MUD WG if we had that. As it is, I have no idea where to discuss this, and thus another shotgun. I gather the mailman deletes my Reply-To suggestions.
I feel that this document should be adopted and the details filed in, but I
have no idea what WG it belongs in given the current state of things.
{It totally fits into the IoT lifecycle security WG I had proposed}
I knew it was around since it was talked about at the Hackathon a bunch, but
I hadn't read the result until today.
If you use Hypothesis my comments are at:
https://hyp.is/go?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-moran-suit-mud-00.html&group=__world__
I'm not sure what that does if you don't have the plugin installed.
I'd prefer to write them as a pull request since they are mostly suggestions
on fixing some wording rather than any kind of substantive request for
changes.
Substantive comments:
"At the time of onboarding, devices report their manifest in use to the MUD
manager."
so I think that we will need to detail this!!!
When using an IDevID based onboarding system (BRSKI/BRSKI-TEEP/BRSKI-AE or
EAP-NOOB with some certificate based system) then the MUD certificate OID is
available.
But, that's not the manifest of the software currently running, and it would
not be reasonable to embed that into the IDevID for the reasons I explain at:
https://datatracker.ietf.org/doc/html/draft-richardson-opsawg-mud-acceptable-urls-00#section-2
More interesting is that you are requesting:
Each time a device is updated, rebooted, or otherwise substantially
changed, it will execute an attestation.
Among other claims in the Entity Attestation Token (EAT)
[I-D.ietf-rats-eat], the device will report its software digest(s),
configuration digest(s), primary manifest URI, and primary manifest
digest to the MUD manager.
Well, that attestation is actually ideal for use during onboarding as well.
It seems to me that the path of trust should go like:
1) (Manufacturer IDevID PKI) -> IDevID.
2) IDevID -> "generic" MUD file (signed by key from Manufacturer PKI <%>)
3) MUD file -> identifies key that signs firmware manifests
4) SUIT MANIFEST -> "specific" (per version) MUD file
I had previous suggested that the SBOM be attached to the per-version MUD
file, but I am not so sure anymore.
Note that the EAT described above would be *Evidence* (not Attestation
Results), per the architecture. It would be signed by the IDevID in <2>.
Finally, if you didn't see my message to secdispatch about IDevID.
https://mailarchive.ietf.org/arch/msg/secdispatch/Hqe1lHG2wnW_9NxJLazEYbmGYN0/
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
