Re: [Rats] 802.1AR device identity

"Smith, Ned" <ned.smith@intel.com> Wed, 21 April 2021 23:20 UTC

Return-Path: <ned.smith@intel.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 D303C3A3AE0; Wed, 21 Apr 2021 16:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.onmicrosoft.com
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 cKuKGT-FwXaw; Wed, 21 Apr 2021 16:19:58 -0700 (PDT)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2503A3ADF; Wed, 21 Apr 2021 16:19:57 -0700 (PDT)
IronPort-SDR: HZmrIYRVUhYZ6kErcd8f99pDltj8PTU440MK9QbMleQRCutwnaMTuH3a3PomrAg/N8HKisWUnr iUxW1XGGeI7A==
X-IronPort-AV: E=McAfee;i="6200,9189,9961"; a="192608540"
X-IronPort-AV: E=Sophos;i="5.82,241,1613462400"; d="scan'208,217";a="192608540"
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2021 16:19:56 -0700
IronPort-SDR: ZvqFwMIkxKI2CvUP85g3gbAzpS1qpSWHgMN/A1R6DPkfitp87wPJUQ5ovcseGtmM1wtJW4S7/L QuDqubCcDk7w==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.82,241,1613462400"; d="scan'208,217";a="455543460"
Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga002.fm.intel.com with ESMTP; 21 Apr 2021 16:19:55 -0700
Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 21 Apr 2021 16:19:55 -0700
Received: from orsmsx603.amr.corp.intel.com (10.22.229.16) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 21 Apr 2021 16:19:54 -0700
Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Wed, 21 Apr 2021 16:19:54 -0700
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.58) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Wed, 21 Apr 2021 16:19:54 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fUrI2LJyyTyQtAPcLMIc50NGnccok4G8AvMMYGmTpvV+/cy7kf6Ds3krFsBpLrcf0OfkDPXFabRdTlZsNpoQx5bTdPiUBVydmJWHPwzRHRaUYCyBri4hiCYHri7N/utmtspb6a+XEIPQsE+3G5TJKGn9mD3FY7SDpUp33TXVRTCxRB05fcvkmdPBHgUD3Pqx/Q0rX06hkQq/KSLCPPi0BfQafxSbtNGueBhfcfnHDyovoCAfYOX/ENEaFNLE/+FncF93SpQpDH7/dSzU00bOmV3Bm3XnkcVxeeCFI10sxJFfZPz/0Vj08xkBQvYALP/lGCsVx17NogdxpdFdMDVZyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1K853MsLQiPv5zGJxIs/3OAGfmADGwcC6ycWjzQPEKg=; b=WkVP481hjguDsWv2ZdX4RGZmICuaFVXrSBwTD3ZsqxCEvXmA88ZO28mGL5BWZFhilrtas+eKUtigKukw57i6VLE/ZXRhXqWzLQ7R0ycww2iL3Evgy3wvu1r+Kw4NVgPCHpQwQUphRQlEnei+mpIG8TurRvLts8hygb0DQWwNUUcmd+tnZCXFyhl3wIANnEEXaRdL5tCTksOoBlxUZbn+7lOdX3ueAIogpBTdCbQDfx11ur5ESleKWnpDEJHHieT6LAsUfirQaX4u6Ux1cpQUmYGRRuPShCnXhyrg4h9Q5EDSClr4bxT0KASqj1K/MKcydIP7/f8HIvqm7CqV8cDx2g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1K853MsLQiPv5zGJxIs/3OAGfmADGwcC6ycWjzQPEKg=; b=Hs3L4XmED12+mymC7krf/dyfGTvCck9YxbpNWo2M51A2LdjoLWFK2gjVA4ZamoShONOddmipO6RJPbCatyOspyu+TSKWw9RrQHeWUDCUquC7pzZQ71przLV2ogi7RhkL8xHCOwKf1pMoXvQc8T/enYC9lSybmJpWDYXiMdQUUeI=
Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by MW3PR11MB4556.namprd11.prod.outlook.com (2603:10b6:303:5b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Wed, 21 Apr 2021 23:19:53 +0000
Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::d1ed:e397:a61:aca2]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::d1ed:e397:a61:aca2%6]) with mapi id 15.20.4065.022; Wed, 21 Apr 2021 23:19:53 +0000
From: "Smith, Ned" <ned.smith@intel.com>
To: Russ Housley <housley@vigilsec.com>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
CC: Guy Fedorkow <gfedorkow@juniper.net>, 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>
Thread-Topic: [Rats] 802.1AR device identity
Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoCAAVufAP//5OOAgACzxwCAAAOuAIAXhE8AgArnz9CAGPKigIAAPVGAgASjCAA=
Date: Wed, 21 Apr 2021 23:19:53 +0000
Message-ID: <2118D1F3-849F-4238-A2AE-054FF67144FF@intel.com>
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> <92EF6820-3234-4458-B66A-7B7E6693CB76@vigilsec.com>
In-Reply-To: <92EF6820-3234-4458-B66A-7B7E6693CB76@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.48.21041102
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=intel.com;
x-originating-ip: [50.53.43.22]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1faa6252-6cef-4ff6-76ba-08d9051bf815
x-ms-traffictypediagnostic: MW3PR11MB4556:
x-microsoft-antispam-prvs: <MW3PR11MB4556523C3C6B4D725C80784EE5479@MW3PR11MB4556.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3b9XhcLiqyR9M59IrJI8tpbF1eCrpN7+P31bcMWpaTLV1dUhk0U1ZNLlzKx5VnlDydqL8+FVLNpcD4cZ69jLNvFAmZJ1AGT+r5oK51fu7fZMHkG9NrIGEBvqg/Zji592TBmN4ddCHxJbbLsYCNxfB4t9T9BjjsDJ72sUROyahUVxSgZRdSL4DAk+lC+yR1GE/Pi5zC6G517e+8n4xW5UwMyD/8GfxdJlT64TRWLwh4l6e7qYrSg8mQdPp4cr41Q0wz62pFZXFV75a1HNl99jsYT70acX3Dg8E5adhN1XemXhDsNRsloKWjEU6joCnmOWGHwnqE+XoENTH5cA+QDSjvQ9BEoUesIGyPUK7LN2AZjCHaZIw+PK1tOXxscUIR0MpfIO3Co95LNTvn//WkHF1hO5fJakbno8com7SovzKQ9qLfWiHH3cOCPq+WH8PwywNudNQxJ3ToNTInc+nOQFh+i7ibvBNbpX1q57f7D1iDue+oKIh44pr2uQvlIR6t0cXjFSWcZxxjpFr+WI84hAk3gCP5t3666iU0wXxXvJ3aqF6WeajS2Tlzo1mjpFd0f9oR/WF6JJkRZUwFX+UuFAPr8J/1287W8w3D2fkZ5YHUEb3EoXso061BxilhxtTZ0NQrs1CT6eTjA+ibjU0qpFIvSo6O/ANesMHoX9Jw7ctM4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5169.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(39860400002)(136003)(396003)(346002)(122000001)(33656002)(83380400001)(66946007)(8936002)(91956017)(26005)(54906003)(66476007)(5660300002)(86362001)(110136005)(38100700002)(6486002)(186003)(53546011)(8676002)(66556008)(2906002)(2616005)(71200400001)(64756008)(316002)(478600001)(6512007)(6506007)(36756003)(66446008)(4326008)(76116006)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?R2F1MjRSeU1Yb1l1YlVmbnpOenNLUmxmRnlCQ3R6VXJLZVNnU3RPazU4aEJT?= =?utf-8?B?eUNiR0czYWdWYmNVSkt1M20rS1pjVW5SWnc5K1grSG1HRW1MdU1IVjlpQWdw?= =?utf-8?B?SHRKa0RpVVBMakdndDNUNCtsRlVFR1l2aUxyemlXbUNReXJoV0F0S3lsZnBK?= =?utf-8?B?Qnlha0dHSXNzQzNhQmdwUDJKTVhvR1dMY0xUMmx0N1h2aEV5RjcwOWF0bzN1?= =?utf-8?B?U1ZZaTVWZ21TQ2E4bXkzWnlNWDIza3pIRlYzN09YTExPSnFJakp6aTk5T3VU?= =?utf-8?B?d2g1ckQxRWdBNXRoWHBmb21MOEtZODkyL3pSTnFNRWpDL3FFWGlHd0pYZ1hL?= =?utf-8?B?R1U0TkplR3kvVnBDRFAxeTY2L3hHNGNlRk45QjE2MzlzQnVWRTAvZ0hjblhm?= =?utf-8?B?UFBzM0ZGdVAxWTdubS96UFdtZngvYy95b2dVazV3Z1A2ZzdJcXc4cFhQcnFW?= =?utf-8?B?YmlUNWo2UUEycEdELzZ6bVJma2tvdTVHYjhNbjNpTjdmRlowS3pVdUtxczNi?= =?utf-8?B?QVErWlZCVUE1eVgwZmVnZ1I4cUVFSTJPNHcrNXlSRUxOTUlSanc2aWtIYXRC?= =?utf-8?B?NjZwcUJ2L2h0ZEFUNDQ4ajBQcXZFV3NoRWNjWjZCbU5KYXQ3aW4yb1ljQTZw?= =?utf-8?B?ZXBPQkZKSFVQUFYralZxTzd1Y2JCQmlZeStWY0lVRW52N0VVRzNFOTNLRERP?= =?utf-8?B?cDNxWlQwclpJZE03Wm5Od0dzTThJczFtSFY2RjRXVmE1RTNESVFCVjNuMzA0?= =?utf-8?B?djRwL2w4cXFQN0o1UkxUakMvditpUlFIcFlPcXFrdTdSc0xiOEdXNmdjU2xL?= =?utf-8?B?cXpVNlZNYUUrOW9BalFwRS9QT2tqNkttQ1QrR3ovU1krRjhLcVY0c3drSUlD?= =?utf-8?B?dzlOeW9MeUZzOFZFa1Q0Q3NWTWpWcjJSSGtVdWlYZVYxejAwV01BQTZvbjA5?= =?utf-8?B?NDF6SVU5TnJucXFtS08rTTNiOXNQN1JQT3hhRExXNk1TSUErbi82RHVSRnQ3?= =?utf-8?B?MnBiQVRvdDFxeXFTU21hdDAwMnpvMjZEdlVpZGllSDdKd3NhYzdNbk5uNzFO?= =?utf-8?B?R2dKeHp0SDBlcXpjOHZaVWpINU1qVmp3aVd5OU4vQ0pialhEMnQxSWVDcW9T?= =?utf-8?B?MXFFWmVHMW9KdTZzS0NGdm51UGlMTjVTeUcvN0M0VTZEMTN2Z1hoYndVMFp1?= =?utf-8?B?SU4zRUdUWjV3WkJST1JOcjVlbWhKcXNBb1QyQWJyZVRFTVRhYmtvWHRPUUZM?= =?utf-8?B?UHlybVVUL1c0c29OcUIvQlErSWx4TU05SkdNTkJnanZISmxmSmJ2QUVEWGox?= =?utf-8?B?VWFJakNneFZ0MUVpb2phdUwrTXZFdThuK2h6YkdkeEVxeit2NlQ2SzQyOHFI?= =?utf-8?B?VkQ4cU56YldVVzY5NUJ1VEtpeHQySG80d3FoYjJGa2FKcmp5NVNoZmI4MHhP?= =?utf-8?B?c2VjU29vNDc2MW9TcStqV2hTUUZKNE9zdDlnK1FpVmJQdnRFK3N5ejNON2NQ?= =?utf-8?B?Z01GSlArNzFBSmFkU05idDNUSHo1UGswNkZQeDlvWGVLS2V5UktBcHE0eXRp?= =?utf-8?B?UGR2aFZwelYyZzZvQWlUR2RTUzA1Nm1zVXBVcmttdFQzRjFmcUhzODRpVmhD?= =?utf-8?B?eTE2REdrVU9OZUZNeU5qc2lpK0JNaFBhRmNzRFJYeGdBRFBMSk03cnlGMk0x?= =?utf-8?B?SE0ySnFLc0RBMzlDeHBhK3lrQUYxOSs5cEZvL3NGNEl6ZnNDQ29qd2ZyUmc2?= =?utf-8?Q?Qaozg0A9axzR6BOhiU2hv6K4XjL7QydX8R8Y0kn?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_2118D1F3849F4238A2AE054FF67144FFintelcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5169.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1faa6252-6cef-4ff6-76ba-08d9051bf815
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 23:19:53.2504 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FZAigPEiqCe2okoZzENI9uxbgIQ0rNWDJB95KFfy8vNjqZTLdlOoOdGE9JPzT0kNmiI0tbtuG4VZWOimgN4V2g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4556
X-OriginatorOrg: intel.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/c0PfaKaCeEUUxaS3SD6Q97Hl94o>
Subject: Re: [Rats] 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: Wed, 21 Apr 2021 23:20:03 -0000

It is reasonable, in the context of onboarding, where the owner isn’t a supply chain entity, but the network owner who is going to deploy / manage the device. Onboarding might involve separately evaluating the supply chain risk and any ‘owner’ that might be a supplier from onboarding processes that take a clean room approach that wipe clean / reset to mfg defaults.

An mfg IDevID design might be such that tampering by supply chain ‘owners’ would be detected and hence trusting them isn’t really necessary. The end user / customer as ‘owner’ might only care about trusting the IDevID mfg or only trusting him/her self.

From: Russ Housley <housley@vigilsec.com>
Date: Sunday, April 18, 2021 at 10:31 AM
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
Cc: Guy Fedorkow <gfedorkow@juniper.net>et>, "Smith, Ned" <ned.smith@intel.com>om>, Henk Berkholz <henk.birkholz@sit.fraunhofer.de>de>, "iotops@ietf.org" <iotops@ietf.org>rg>, "rats@ietf.org" <rats@ietf.org>rg>, Laurence Lundblade <lgl@island-resort.com>om>, Ira McDonald <blueroofmusic@gmail.com>
Subject: Re: [Rats] 802.1AR device identity




On Apr 18, 2021, at 9:51 AM, Eliot Lear <lear=40cisco.com@dmarc.ietf.org<mailto: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