IETF Logo Mail Archive

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

Russ Housley <housley@vigilsec.com> Sun, 18 April 2021 17:40 UTC

Return-Path: <housley@vigilsec.com>
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 E78F73A20F2 for <iotops@ietfa.amsl.com>; Sun, 18 Apr 2021 10:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Lhw8kQX76vaL for <iotops@ietfa.amsl.com>; Sun, 18 Apr 2021 10:40:10 -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 9498D3A20F0 for <iotops@ietf.org>; Sun, 18 Apr 2021 10:40:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 16A1C300BE6 for <iotops@ietf.org>; Sun, 18 Apr 2021 13:31:23 -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 DwbIh3SjE3-n for <iotops@ietf.org>; Sun, 18 Apr 2021 13:31:19 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id EA932300232; Sun, 18 Apr 2021 13:31:18 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <92EF6820-3234-4458-B66A-7B7E6693CB76@vigilsec.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_D2BEF9E2-B8A5-427A-85B1-52680F2B2525"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Sun, 18 Apr 2021 13:31:19 -0400
In-Reply-To: <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com>
Cc: Guy Fedorkow <gfedorkow@juniper.net>, "Smith, Ned" <ned.smith@intel.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "iotops@ietf.org" <iotops@ietf.org>, "rats@ietf.org" <rats@ietf.org>, Laurence Lundblade <lgl@island-resort.com>, Ira McDonald <blueroofmusic@gmail.com>
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
References: <D197C29D-95C4-4696-BE22-703E14DFFE35@intel.com> <E0971364-E3AD-40C6-A08A-A0BA7E64D18F@cisco.com> <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com> <957A467D-4FE4-4031-98D2-6936D014A37C@cisco.com> <62FFA122-047E-468C-A2DD-5A0E4E8EAF74@intel.com> <9EE53DF3-17AD-495D-9BE7-C15B92EF6B99@island-resort.com> <CAN40gSsCbjpVuCQwsWWjGwfL=cARHcAa0ZPsm+sk8H=9_otZUw@mail.gmail.com> <3593A760-335F-40AF-AC43-7E2D7A1EFF7B@island-resort.com> <BLAPR05MB7378A9F73457513AC951F82FBA7A9@BLAPR05MB7378.namprd05.prod.outlook.com> <07EAF7BF-1595-448D-9164-3903E15C5A50@cisco.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/6a_qkqYVEuBRczA2EExGKViKuQY>
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: Sun, 18 Apr 2021 17:40:16 -0000


> On Apr 18, 2021, at 9:51 AM, Eliot Lear <lear=40cisco.com@dmarc.ietf.org> wrote:
> 
> Signed PGP part
> Sorry for the delayed response:
> 
>> On 2 Apr 2021, at 19:05, Guy Fedorkow <gfedorkow@juniper.net <mailto:gfedorkow@juniper.net>> wrote:
>> 
>> Hi Laurence,
>>   I agree that IDevID is intended to persist through the device’s lifetime, while LDevID is meant to represent the current owner.
> 
> Yes, that was the original intent, and even the current intent.  And while that is necessary, it may not be sufficient for long supply chains where ownership passes from one to another.  The LDevID is an owner-assigned name, and so the question is this: when an owner goes to transfer, does it need to use the IDevID again or should it use the LDevID?  There are benefits and drawbacks to both, but if the LDevID is used, then it is used as the IDevID would have been as part of that transfer.  The nice thing about FDO is that it keeps an entire record of these sorts of transfers.

I think it depends on whether the new owner trusts the issuer of the LDevID.  If so, then leveraging the existing LDevID may be straightforward.  If the new owner does not trust the issuer of the LDevID, then resetting the device to the factory default settings, which would include the IDevID, makes a lot of sense.

Russ

v2.23.0 | Report a Bug | By Email