Re: [Rats] 802.1AR device identity

Eliot Lear <> Thu, 11 March 2021 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 236E03A1779; Thu, 11 Mar 2021 01:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d0m_haZip5nU; Thu, 11 Mar 2021 01:53:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4527F3A1776; Thu, 11 Mar 2021 01:53:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=29519; q=dns/txt; s=iport; t=1615456437; x=1616666037; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=sJ3fNxfV4FagEqfeOLbgFFly6pxuHX3VHA2tPSZwuJs=; b=UfgxzrVpF2jtW/Rqu6GqpQLLsAqF95dRSbLhlhajNh6w4woFYolZE78a j6q0afbcR7vZ5rNVQCcUFiiI8FAhQkdsSKK9ZJ0VTpyL8yWJx2jTrZ72e aNV2xMADWj4uZEDY1LBA1Q9yyyVlE6ROXIez9eArv15uKvnUsgmrdZKkT k=;
X-Files: signature.asc : 488
IronPort-HdrOrdr: A9a23:Mj9f3650wwua/3u/VAPXwErXdLJzesId70hD6mlaQ3VuA6+lvu qpm+kW0gKxtSYJVBgb9eyoFaGcTRrnlKJdzpIWOd6ZNjXOmGztF4166Jun/juIIU3D38pQz7 1pfaQ7KNCYNzVHpOL75AX9LNo62tmA98mT6tv29HtmQQF0Z6wI1W4QYTqzKUF4SBJLApA0Dv Onl696jgC9cncaZNnTPBc4dtXEzue79q7OUFojDx4j5BLmt0LN1JfKVz6FwxwZTzRDhZAl/G StqX2e2oyT99em1xTby2jfq65zpeKk4N5CCMuQ4/JlTQnRtg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,240,1610409600"; d="asc'?scan'208,217";a="34101684"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Mar 2021 09:53:52 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 12B9rp78011181 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Mar 2021 09:53:52 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_79471D38-9C62-4BF9-9EF9-593971C924D1"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Thu, 11 Mar 2021 10:53:50 +0100
In-Reply-To: <>
Cc: Guy Fedorkow <>, Laurence Lundblade <>, "" <>, "" <>
To: "Smith, Ned" <>
References: <> <> <>
X-Mailer: Apple Mail (2.3654.
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [Rats] 802.1AR device identity
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Mar 2021 09:54:00 -0000

Thanks, Ned.  My point really was to talk about the impetus for making an iDevID change.  There’s one more obvious one that I didn’t mention.  If you want to make use of tools like ANIMA BRSKI / RFC 8366 to transition from iDevID -> lDevID and you have a supply chain to manage, monkeying with what is called the iDevID in those transactions might help.  A better approach might be to integrate FDO (ledger based transfers).


> On 10 Mar 2021, at 22:09, Smith, Ned <> wrote:
> 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 <>
> Date: Wednesday, March 10, 2021 at 12:27 PM
> To: "Smith, Ned" <>
> Cc: Guy Fedorkow <>rg>, Laurence Lundblade <>om>, "" <>rg>, <>
> 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 < <>> 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 < <>> on behalf of Guy Fedorkow < <>>
>> Date: Wednesday, March 10, 2021 at 7:59 AM
>> To: Laurence Lundblade < <>>
>> Cc: " <>" < <>>
>> 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:
>> <>
>>   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
>> <>
>> <>