Re: [Rats] 802.1AR device identity

Eliot Lear <> Wed, 10 March 2021 20:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50AA83A1785; Wed, 10 Mar 2021 12:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.6
X-Spam-Status: No, score=-14.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, RCVD_IN_DNSWL_HI=-5, 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 heJf5gZQ6EFf; Wed, 10 Mar 2021 12:27:17 -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 B94703A1757; Wed, 10 Mar 2021 12:27:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=17889; q=dns/txt; s=iport; t=1615408037; x=1616617637; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=stvtBI/GVIA7Zn7OcEpn21DvPctihXz3osaHBlqV8LU=; b=NVS4M0Yiik4PgyuBAkvdTe7Obg3cEs6S1u7TLfDnEtsBL60cLPaVGBPi FTO4Qq+O25u0G68G6WOvtOEGmFlrMDLiR1UXKb91UZ4glT9s6Rltag4jE E7q6G8dOUoDiLNJU2yyYTECn0kjRd/AktQw2d5Bw/NqX4lp0w3YQWuXSn c=;
X-Files: signature.asc : 488
IronPort-HdrOrdr: A9a23:yYeVM6+O7wXRvs48DLRuk+BaI+orLtY04lQ7vn1ZYxY9SL36q+ mFmvMH2RjozAsAQX1Io7y9EYSJXH+0z/9IyKYLO7PKZmPbkUuuaLpv9I7zhwDnchefysd42b 17e6ZzTP38ZGIWse/f4A21V+kt28OG9qfAv4jj5kxgRw1rdK1shj0RYm2mO3Z7SwVcCZ0yGI D03LsjmxObZX8VYs6nb0NqY8H/obTw5fDbSC9DIxYm7QWU5AnYjILSIly/wgoUVS9JzPME92 XI+jaJgJmLgrWc1gLW0XPV4tBtvObZjvFHBMCKl6EuW1LRtjo=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,238,1610409600"; d="asc'?scan'208,217";a="34021563"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Mar 2021 20:27:12 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 12AKRBGR011445 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 Mar 2021 20:27:11 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_AFEF8D85-0447-4C98-87B1-F8A3799AE097"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 10 Mar 2021 21:27:10 +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: Wed, 10 Mar 2021 20:27:19 -0000

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.


> 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