Re: [Rats] 802.1AR device identity

"Smith, Ned" <ned.smith@intel.com> Wed, 10 March 2021 21:09 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 03AA93A182A; Wed, 10 Mar 2021 13:09:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 PveWPOW6Y9qC; Wed, 10 Mar 2021 13:09:42 -0800 (PST)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 CFEA43A1829; Wed, 10 Mar 2021 13:09:41 -0800 (PST)
IronPort-SDR: nzYTyCFxqF+DpMtOUTHcD2mUcD8jyczU0ppVG2xjvaTUGqN/MtpSZYvjFgau05r6El5eiWyL+K KaNkP2oJIo6Q==
X-IronPort-AV: E=McAfee;i="6000,8403,9919"; a="188663844"
X-IronPort-AV: E=Sophos;i="5.81,238,1610438400"; d="scan'208,217";a="188663844"
Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 13:09:40 -0800
IronPort-SDR: 0f7HCGPmOHlqHQ/+uudqFaAUuQN2/tP7KlNVY029OY6O2Qn2lXVn0vMM/udlIIxNpO+SndsPpo 4+ROZc4G9oYg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.81,238,1610438400"; d="scan'208,217";a="386775268"
Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga002.jf.intel.com with ESMTP; 10 Mar 2021 13:09:40 -0800
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, 10 Mar 2021 13:09:39 -0800
Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) 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 via Frontend Transport; Wed, 10 Mar 2021 13:09:39 -0800
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.175) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Wed, 10 Mar 2021 13:09:39 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TF+aHGuZ27gqrLf5NTDmNBadwCeyVvzX0Ct40id8blLJowwUoOp3UOCLAzUUdDKvMoQu7B0Svt0TFHiI1xv8lKUdl1zREWuEraPLFe+GWWAfkUllXsbBwA0TXXohjqtpiADHI34xGtDQAjjoxyPqwMiBGHU0XSbAeKmbeJflY038XxeCopfjz37YSYWw3hj7r45dMPPjhloV4SCgY7oDBB+i/KqRFem6vhDNeoX6IswefiSAKm/WUeTlBfXUmHggXzDnrw2xOehTQqTjRGJlThTlsFj3wQts/aPZ4nGOnaxVtUOGX4gPwmtWeKDeEcuVh8ez/jwbdC4vgnkT6gSsHw==
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=5aQeoOLY6X5zRZDGVMPr+K49QDgRsfP+S+70X3j4wnA=; b=BiwJtKeazxOhsZbzA4oDqCE3BfuqY4yr/j61h6xqJjeK5Q5ac+uB7GK3u3duaMrePI/3h2T/HLBH4CUPl+TQbmQScX1M5PVJ7q3omZHj5dMAJiqig8Y7v7SVJPcsypLOaZqqDZNVRm3IOVoR41oUx6q8578Nr0xQeGY4CQqgJ3hyZHQ9nJkkqzy8EvLT6v6baJnqZ9tzEE9XfOesX1Xnv7BvjO3FsY3FzCSz11Mxr+Ie3o/DtNUmU/0HYijWKNNCtausYrLV6VtROsYKA34Yajo164kd5NZkxlbnkDxlCI8699YzPRp6D6i4ptzJ7FvnGlHEamVt3PVmapL57HRSeQ==
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=5aQeoOLY6X5zRZDGVMPr+K49QDgRsfP+S+70X3j4wnA=; b=TvCFoVGI6/Pu+/4+x0/dIsjayEeVPzOYW5F7ZvPubc8F2deOfVJy0OUtvyY3ItKhO2yKaeGoSqWF6DnD1cBXr2/+UMwdkf4nVZODJq6KgYwOzu8pW9Y9YlL1ZeSRB9q8Zo/yUHriWW2+6A4xzW93O7xaaVu76VUDkRHgqXKGabM=
Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by MWHPR1101MB2350.namprd11.prod.outlook.com (2603:10b6:300:75::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Wed, 10 Mar 2021 21:09:38 +0000
Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::b424:905d:3819:d9f0]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::b424:905d:3819:d9f0%3]) with mapi id 15.20.3912.030; Wed, 10 Mar 2021 21:09:38 +0000
From: "Smith, Ned" <ned.smith@intel.com>
To: Eliot Lear <lear@cisco.com>
CC: Guy Fedorkow <gfedorkow=40juniper.net@dmarc.ietf.org>, Laurence Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>, "iotops@ietf.org" <iotops@ietf.org>
Thread-Topic: [Rats] 802.1AR device identity
Thread-Index: AQHXFd/v8NyDidhntUK49t5dagx8x6p9q74A//+FwoA=
Date: Wed, 10 Mar 2021 21:09:38 +0000
Message-ID: <0C1A8AE6-E6C3-4AF9-9E4F-5841FB450BE3@intel.com>
References: <D197C29D-95C4-4696-BE22-703E14DFFE35@intel.com> <E0971364-E3AD-40C6-A08A-A0BA7E64D18F@cisco.com>
In-Reply-To: <E0971364-E3AD-40C6-A08A-A0BA7E64D18F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.46.21021202
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.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: 9d21b11f-4607-419e-fabe-08d8e408d0e2
x-ms-traffictypediagnostic: MWHPR1101MB2350:
x-microsoft-antispam-prvs: <MWHPR1101MB2350140A763FF4E3834D0FB7E5919@MWHPR1101MB2350.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cxaZ+9oJl7ZEbbFCdOZIiLmjvYUjcvGzRUmWb5+RaW4zbdgsTf4HeyZDCzDIKzTwtX3VPB3FtrCMo2WUEs/TYngsU6U2eII9/VwfweadZ5gB5mZxrHFLcj7KrGptnkJoo9+ABVPWmFkIRhisGbt0+rb4ZY4SF5H/+pPpedmC26WGfjK2ypK/CU6JLfuivW6elyD5Ovv4HBw/cL0M9lJibRLQFv4icfXcU9O5qZWlbbA5QHoNu/JJEKXL+C7BHuCAXnCYkBSgt+4NbzxdWrlm9Eu60cIdr6HqA/7tRN9EUyWX2dH73b4s0ZKRQucju3AS16eBTKtrvYT8UQ0lC+y+DYlhA56qRmv0UBWEiKrhm/BxCHZqCjdcOF00ccK/Ai7WvES1+Lwjd+uMEk+Sp2iVCmfxQPLmbR12hQzXFUEUykaSxlMf/BVEV+7KeiXbpBwd0AuF6Tuk7YVo/IB26H86u76dX+peme1W8QN5T7hKpdwulvcBblNkdsjI3zR+LwiGCYBhFuzpScjQlftGGcNgO9rrzR3z0gn0dFRHuMvg+PFaItUVCgloLBV3URihHKTncDJ+RdbqENAS7HLO9hg/NHSt/hmdqWNO0ftvLpkAaNsauO5rtKNrU4lU7+yqMxdLwCYX2sUcf4Xr3GQ87GM0vg==
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:(39860400002)(396003)(376002)(346002)(136003)(366004)(6916009)(66946007)(66556008)(66476007)(66446008)(186003)(76116006)(6512007)(8936002)(6486002)(71200400001)(478600001)(4326008)(64756008)(2906002)(36756003)(53546011)(6506007)(33656002)(316002)(8676002)(83380400001)(966005)(54906003)(2616005)(86362001)(26005)(166002)(5660300002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?R3o4RDZiSFhhYUFSaTdvLzZWczM0bW1HY1ByNGNkTWVEVGRYNHVHQ3BLSkxM?= =?utf-8?B?WmhaUmNpd1NQQXdHREZ2MTBkNFdjUC9UektXdmhqYnllRklrK3JJRlZNWVdU?= =?utf-8?B?ZVZFQUFRNUQ0TGlsQzdQUG1TUmU2V2FWdVl1NmxmZ2Z4eVpBK3l2clh0amlT?= =?utf-8?B?emJUempTWWU0K0xWQ3Q4Njl4aUd0bWJQNGRFR1hEOUtmSU1xQU90cVorMWdC?= =?utf-8?B?ZjB0OFZjNVVZcWpPTllyNjVwek1adEcxdlhOUGN3YVVmcEd6UGJIMzZ2T0lT?= =?utf-8?B?aEZvbGRRazhrRVhDYzdwQnc1WEVGRVNiWkJmY3hyNVNtYXd6RndrZWVscWI0?= =?utf-8?B?ajRNbDAvc3ZQUGx6YS9tTjduZlQxMWdmRklQY2J4U0gxVHlmSDJoMng3aXNs?= =?utf-8?B?cE44Wm5EeGw2TXZpK1ROYVJ1eFg4SDNkK0VTU0VFWEloTHZpaVRNWER5ek1W?= =?utf-8?B?N2lQSk5XSGsyTUNtYzdyWkxWeVE4b0dtT1diNGhHUHkzNXFiVTZaZDhreUM0?= =?utf-8?B?NnBYWlJYN3A5N1huTWVvZXVjalFnc2liZXVKWmpHdFdoVldiK01qQ0l5b3RR?= =?utf-8?B?TFpqZS9iTjV3RGdwQlJvaUxrekNaMzZQMytsRmdKb044dXc5cmxvTTg3UTBq?= =?utf-8?B?OGxvS0VNK1p0WHRzYWhEKzBXRFNUZDJkeTYvYk55dE5pVXcrU0tPbVZReTRv?= =?utf-8?B?TUM0ZWh6OEY3VUYrY2Vxd0VmTTI2eTBIeERFL01ndlVzMHVLSE1KTGo4OEM3?= =?utf-8?B?YUVQRllGeHRYZDRhUW1BUzZVZ3padjhtL3B2aEhXRHF3b3BKbGNFdW5UaU9r?= =?utf-8?B?YlZIQTZVOWl5VTZRenhncGRWTXBoSTFzbU4xZ0VkVklqWnVTS2lENE1LRFhC?= =?utf-8?B?cm42UGNmTUg3bnpSOVpBSTR1UktOdmx1a0NWTGd6VEdkZ0U4MTZheE13Q3VE?= =?utf-8?B?a3dNcWRCWXhDNUw2SUg5bjY5bVNPeUh0dlUwNTRjWS91RUI1K3BHWHk0YU5w?= =?utf-8?B?WDlkN0dFK3hwT3VsRWdlQlF2QzZ3RWF5cDcyRVI0cGRScEc4S3BCT2NjZFZr?= =?utf-8?B?NlQxY3lZdzRLK3FHK1p3eXRSUU5yM1NDRm0rNkMxTk01TDNaMmVUUU9aSUpE?= =?utf-8?B?TzVPWENpdUVQa2o1QjdDQWxJUXlielY3VUpYRVVacWdmeFkwZHhreC9IU0l3?= =?utf-8?B?QmJKV1pvZUhqN2dTcnpVZmdzZ0xNRWtnQzAxVUR2T09WTTM3ZS9RZVR4d0Jx?= =?utf-8?B?N1lPS1B2NGRTSmRGNnJDenVCeXJuc3ArL0duTmdGV04yK2Voc2Y5d2tiOTRq?= =?utf-8?B?Q2FIT1E5R0hHeWN1L09HMjkrMERWTEJXS3hoVTNFZ0FUeno0cXpJdmdkVjEx?= =?utf-8?B?UDlKSDZMSy9acW1QZnZHRVE0MXJrWk13SzF2QmpGTGFUdURzYVJJeUVtbHo3?= =?utf-8?B?Z1RZWkUraUQvY1ZoYzg0dkFYSmc1V25CVlU3VXpWYVpNZWVLYUVUdEtIMUY0?= =?utf-8?B?OG1EWHJyakovRXdJWmV5MUpvbENGNFQrM0lmeHF3M2xtZURSTkVRQzQyUHVN?= =?utf-8?B?MnZPTitEZTdDNmpLdEs3SDdxMElWUmwvdUVMa0d5NmxVR0EydjhLV01velRH?= =?utf-8?B?azVsOWd6TEhWajVpUjBJbEJSUXhmRmVrcXJlMXY0SDlNSm5wa3dtVDdQUXFz?= =?utf-8?B?MVUyMndDclhPVzNQdjQwNHFGcXRXSFB3QmRYMVMxODJHMWJTZlV1Tm1kdU5S?= =?utf-8?Q?T2l3k4C6rTF49vdhQcgsS5rhxZpd82qzn1pq6Fk?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_0C1A8AE6E6C34AF99E4F5841FB450BE3intelcom_"
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: 9d21b11f-4607-419e-fabe-08d8e408d0e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2021 21:09:38.8053 (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: l4riY7WfBCwY9nNkWJxdO6aY19GHuKKgTGC21AainVwWXRn3/bazzf5pHUN0up2GA3dEWJBJ4x1KebiClarMrQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2350
X-OriginatorOrg: intel.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/o_E2_Vbl1KEOuUZARtJJDazKuds>
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, 10 Mar 2021 21:09:45 -0000

Regarding “a standard protected TLV list  that deployments could receive through a standard interface.  These are attestations of a form”

The TLV list is a statement made by a manufacturer about the recoverability of device / device ID. We might call them Vendor Assertions for now.

The RATS Arch describes Endorsements which are “statements about the integrity of the signing capability”. It isn’t clear to me that mutability/immutability of an IdevID key is covered under the definition for Endorsements. The architecture didn’t define terminology for Vendor Assertions that don’t fit the definition for Endorsements or Reference Values.

Bringing this back to the original thread. The vendor is likely the most authoritative entity to make assertions about the mutability/immutability properties of the IDevID (key). If a standard tries to codify it in a specification it tends to suffer from ambiguity or it defines an implementation. (both have compliance challenges)

Hence, a reasonable way forward is for vendors to make claims about IDevID mutability properties. Providing the community with a vocabulary for making such claims is probably the best facilitation a standard could do.

From: Eliot Lear <lear@cisco.com>
Date: Wednesday, March 10, 2021 at 12:27 PM
To: "Smith, Ned" <ned.smith@intel.com>
Cc: Guy Fedorkow <gfedorkow=40juniper.net@dmarc.ietf.org>rg>, Laurence Lundblade <lgl@island-resort.com>om>, "rats@ietf.org" <rats@ietf.org>rg>, <iotops@ietf.org>
Subject: Re: [Rats] 802.1AR device identity

Yeah, this is an issue that comes up from time to time.  How “immutable” should that iDevID be?  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?  Can one recover with an update?
·         What if there are attributes in the cert that I want to dink and share with the deployment?

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.

Eliot



On 10 Mar 2021, at 20:02, Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>> wrote:

The 802.1AR spec doesn’t AFAIK require IDevIDs that can’t change. But not curtain. Is says things like:
A
device’s DevID module stores each of its DevID secrets securely and supports signing operations that prove
possession of the secret (and thus that the device is the subject of the associated DevID certificate), while
ensuring that the secret remains confidential so the device cannot be impersonated by others.
An Initial Device Identifier (IDevID) provided by a device’s supplier can be supplemented by one or more
Local Device Identifiers (LDevIDs), each using an existing or a freshly generated secret, facilitating
enrollment (provisioning of authentication and authorization credentials to authenticated devices) by a local
network administrator.

A device with DevID capability incorporates a globally unique manufacturer provided Initial Device
Identifier (IDevID), stored in a way that protects it from modification.

LDevIDs can also be used as the sole identifier (by disabling the IDevID) to
assure the privacy of the user of a DevID and the equipment in which it is installed.

-Ned
From: RATS <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>> on behalf of Guy Fedorkow <gfedorkow=40juniper.net@dmarc.ietf.org<mailto:gfedorkow=40juniper.net@dmarc.ietf.org>>
Date: Wednesday, March 10, 2021 at 7:59 AM
To: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Cc: "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>
Subject: [Rats] 802.1AR device identity

Hi Laurence,
  We talked about device identity on the RATS call today.
  For RIV, we’re relying on this IEEE spec:
https://1.ieee802.org/security/802-1ar/
  That spec defines Initial and Local Device Identities.  Initial DevID is set by the manufacturer and can’t be changed or replaced, while the Local DevID can be set and erased by the owner of the gear.
  The spec doesn’t address deciding which identity to use for any specific application, but the intent clearly is to allow the owner to use the manufacturer-supplied identity to install an owner-specific identity in a device, and erase the owner-specific identity leaving the manufacturer identity in place when the device is decommissioned.

  Many different specs must have examined this problem, but of course it never hurts to re-use some of these ideas where possible.
  Thx
/guy



Juniper Business Use Only
_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats