Re: [Rats] [Iotops] 802.1AR device identity

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 14 March 2021 01:34 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 8660B3A1557; Sat, 13 Mar 2021 17:34:46 -0800 (PST)
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 Znlp6wpISspH; Sat, 13 Mar 2021 17:34:44 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1376F3A1558; Sat, 13 Mar 2021 17:34:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9ED8238A02; Sat, 13 Mar 2021 20:39:59 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dj4I918SAU71; Sat, 13 Mar 2021 20:39:59 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EE97738A01; Sat, 13 Mar 2021 20:39:58 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0543E8F5; Sat, 13 Mar 2021 20:34:42 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, "rats@ietf.org" <rats@ietf.org>, iotops@ietf.org
In-Reply-To: <E0971364-E3AD-40C6-A08A-A0BA7E64D18F@cisco.com>
References: <D197C29D-95C4-4696-BE22-703E14DFFE35@intel.com> <E0971364-E3AD-40C6-A08A-A0BA7E64D18F@cisco.com>
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: Sat, 13 Mar 2021 20:34:41 -0500
Message-ID: <22167.1615685681@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/GPtdJFvHz5ZMl_oBXWLSgRuvXFM>
Subject: Re: [Rats] [Iotops] 802.1AR device identity
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: Sun, 14 Mar 2021 01:34:47 -0000

Eliot Lear <lear=40cisco.com@dmarc.ietf.org> wrote:
    > Yeah, this is an issue that comes up from time to time.  How
    > “immutable” should that iDevID be?

I take the approach that the IDevID that was shipped from the factory can not
be replaced without a device recall.

(It could be that there are modes where another IDevID can be installed, but
the original would not be removed.  Whether this is an LDevID or IDevID is
open to intepretation)

    > I’ve had this thought in two
    > different contexts: What if the signature algorithm, CA, or private key
    > used to protect the iDevID has been compromised?

Then, the device is broken.
I think you would certainly agree that this can be the only answer if the
software signing key is compromised, right?

    > Can one recover with an update?
    > What if there are attributes in the cert that I want to
    > dink and share with the deployment?

Please define "dink" for me.  I know of only one definition from the school yard.
Does this mean remove? replace?

    > I’d like to take that latter case off the table, but then we need to
    > seriously think about RATS or SUIT providing a standard protected TLV
    > list that deployments could receive through a standard interface.
    > These are attestations of a form, but they’re not really measurements,
    > as has been previously discussed here.

Can you give me an example of one of these attributes?
This sounds like the FIDO situation, from section 6.3 of (my) the usecase
document:

   According to [fidotechnote] FIDO uses attestation to make claims
   about the kind of device which is be used to enroll.  Keypairs are
   generated on a per-device _model_ basis, with a certificate having a
   trust chain that leads back to a well-known root certificate.  It is
   expected that as many as 100,000 devices in a production run would
   have the same public and private key pair.  One assumes that this is
   stored in a tamper-proof TPM so it is relatively difficult to get
   this key out.  The use of this key attests to the the device type,
   and the kind of protections for keys that the relying party may
   assume, not to the identity of the end user.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide