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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 15 March 2021 15:01 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2C03A1368; Mon, 15 Mar 2021 08:01:34 -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 8Uv3d4AzjbVZ; Mon, 15 Mar 2021 08:01:32 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5063D3A1365; Mon, 15 Mar 2021 08:01:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 38435389A5; Mon, 15 Mar 2021 11:06:52 -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 9rejm-ijLn8y; Mon, 15 Mar 2021 11:06:51 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A5393389A1; Mon, 15 Mar 2021 11:06:51 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CACD38F8; Mon, 15 Mar 2021 11:01:28 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Guy Fedorkow <gfedorkow@juniper.net>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, "rats@ietf.org" <rats@ietf.org>, "iotops@ietf.org" <iotops@ietf.org>
In-Reply-To: <BLAPR05MB737820F60EB1379958A79D5DBA6C9@BLAPR05MB7378.namprd05.prod.outlook.com>
References: <D197C29D-95C4-4696-BE22-703E14DFFE35@intel.com> <E0971364-E3AD-40C6-A08A-A0BA7E64D18F@cisco.com> <22167.1615685681@localhost> <BLAPR05MB737820F60EB1379958A79D5DBA6C9@BLAPR05MB7378.namprd05.prod.outlook.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: Mon, 15 Mar 2021 11:01:28 -0400
Message-ID: <22549.1615820488@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/RNImJPY32yqHe058aWoNlOLRBqM>
Subject: Re: [Iotops] [Rats] 802.1AR device identity
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Mar 2021 15:01:34 -0000

Guy Fedorkow <gfedorkow@juniper.net> wrote:
    > I agree with Michael.  The IDevID in my point of view is as permanent
    > as the serial number on the box or the VIN on your car.  I think DevID
    > could have privacy implications in some applications, so within TCG
    > there have been proposals to download the IDevID at the customer's
    > discretion, but in that case, it would have to be linked to TPM's EK
    > (another immutable key), so there's still only one possible IDevID ever
    > for a box.  As noted, LDevIDs can be made and destroyed at will.

Perhaps you said it more precisely than I.
The private key must be immutable and heavily protected (TPM or secure
enclave, etc.).

In draft-selander-ace-ake-authz-02 we describe a mechanism where the contents
of the IDevID are in fact downloaded by correspondants (Registrar) from the
manufacturer, rather than being transmitted over a challenged network.

I guess this would allow the manufacturer to resign in some ways, and maybe
even present different certificates depending upon who is asking.  But, the
serial-number identity that the device has and the connection to the private
key is immutable.

BTW: in the above document we encrypt (with ECIES) the identity to the
manufacturer.  Eliot's concern about which network should a pledge try first,
given many choices, remains.

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