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

Russ Housley <housley@vigilsec.com> Mon, 22 June 2020 14:21 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9F03A0D96 for <rats@ietfa.amsl.com>; Mon, 22 Jun 2020 07:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 RPMp1hCmB30U for <rats@ietfa.amsl.com>; Mon, 22 Jun 2020 07:21:33 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811AA3A0DAB for <rats@ietf.org>; Mon, 22 Jun 2020 07:21:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 036C4300B84 for <rats@ietf.org>; Mon, 22 Jun 2020 10:21:30 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id un91XW26BGKK for <rats@ietf.org>; Mon, 22 Jun 2020 10:21:27 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id C1849300A98; Mon, 22 Jun 2020 10:21:26 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <A82744C1-2D46-4F26-956D-CF0B88627967@vigilsec.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_9CA36E55-8400-47A1-B3C0-53B490A39E07"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Mon, 22 Jun 2020 10:21:27 -0400
In-Reply-To: <12373.1592169791@localhost>
Cc: draft-moran-suit-mud@ietf.org, suit <suit@ietf.org>, rats@ietf.org, opsawg@ietf.org, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Eliot Lear <lear@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <12373.1592169791@localhost>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/6r1lezI8QFTKRXJf33giLDKRK6c>
Subject: Re: [Rats] [Suit] draft-moran-suit-mud, EAT and MUD
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2020 14:21:36 -0000

I think that the best way forward is to ask SECDISPATCH.  I do not think SUIT is a bad answer, but we have a process to pick.

Russ


> On Jun 14, 2020, at 5:23 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 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>, Sandelman Software Works
> -= IPv6 IoT consulting =-