[Suit] draft-moran-suit-mud, EAT and MUD

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 14 June 2020 21:23 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE683A00B2; Sun, 14 Jun 2020 14:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.792
X-Spam-Level:
X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FgmbKOx7_2I; Sun, 14 Jun 2020 14:23:15 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8813A00B0; Sun, 14 Jun 2020 14:23:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E2065389FD; Sun, 14 Jun 2020 17:20:39 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fn1erizQuSpV; Sun, 14 Jun 2020 17:20:39 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 093F4389FB; Sun, 14 Jun 2020 17:20:39 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BBACD75F; Sun, 14 Jun 2020 17:23:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: draft-moran-suit-mud@ietf.org, suit@ietf.org
cc: Eliot Lear <lear@cisco.com>, opsawg@ietf.org, rats@ietf.org, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sun, 14 Jun 2020 17:23:11 -0400
Message-ID: <12373.1592169791@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/z0pU6ERSH1sapk15UM0fAGeoEvY>
Subject: [Suit] draft-moran-suit-mud, EAT and MUD
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jun 2020 21:23:18 -0000

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+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-