IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 24 March 2020 21:47 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0063A12D3; Tue, 24 Mar 2020 14:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Hdtd1yEiLvnJ; Tue, 24 Mar 2020 14:47:08 -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 69D0B3A0EFB; Tue, 24 Mar 2020 14:47:08 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E75ED38982; Tue, 24 Mar 2020 17:45:43 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8D88816D; Tue, 24 Mar 2020 17:47:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "M. Ranganathan" <mranga@gmail.com>
cc: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, iot-onboarding@ietf.org, mud@ietf.org
In-Reply-To: <CAHiu4JPqXd2emEFCRK2dq0L6OFOcr-UdNkhJ2W+Cx5TUCLrprA@mail.gmail.com>
References: <0DE46278-4708-42B6-8DFF-A8BC67B23F7E@cisco.com> <CAHiu4JPqXd2emEFCRK2dq0L6OFOcr-UdNkhJ2W+Cx5TUCLrprA@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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-sha256"; protocol="application/pgp-signature"
Date: Tue, 24 Mar 2020 17:47:07 -0400
Message-ID: <17397.1585086427@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/w0pklYB7GBEDMcOYIIxagUpcCa0>
Subject: Re: [Mud] Some new stuff for mudmaker.org
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 21:47:11 -0000

M. Ranganathan <mranga@gmail.com> wrote:
    >> Hi everyone,
    >>
    >> As part of mudding, I’ve been talking to the SBOM people.  These are the
    >> folk who are looking to produce a software bill of materials for IOT
    >> devices.  The question: how to find it?  Well, MUD to the rescue.  I’ve
    >> added a very simple extension (no draft yet but working on it) that would
    >> describe just how to get the SBOM.
    >>
    >>
    > Less travel leads to more MIUDdling :-). There's always a silver lining.

    > I have a very basic question about the whole notion of mixing SBOM with
    > MUD. MUD was intended for network access control whereas SBOM is more for
    > ensuring software integrity. Should this be part of the MUD file or
    > included (for example) as a pointer in the device certificate so it can be
    > independent of MUD? Why include this as part of the MUD file?  I'd just
    > like to understand the motivation.

For the same reason that the MUD file pointer in the IDevID presents update
problems.  The SBOM is directly connected to the firmware revision, while the
IDevID ought to live across firmware versions (and be hard to replace).

So, a pointer in the MUD definition to the SBOM means that it doesn't have to
be communicated from the device to the network in another way.

It seems like a fine extension to MUD to me.



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email