Re: [Rats] 802.1AR device identity

Ira McDonald <> Thu, 11 March 2021 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 630E73A0E1E; Thu, 11 Mar 2021 11:13:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V0wvC-OYwXMx; Thu, 11 Mar 2021 11:13:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 277393A0E1A; Thu, 11 Mar 2021 11:13:38 -0800 (PST)
Received: by with SMTP id p8so723604vki.7; Thu, 11 Mar 2021 11:13:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=adG6uzpbviDnP1EzUSUu63ppaq/APxuHaE8PTZk2J7Q=; b=ntLRAk/NT2zTR8hBaUMUzjOHtPNLDw0eqD3xQtWoIFvpv5HIxSTLLRBwMusNAOtbWs MOXwqYalbtdz+5tdC8GG2UKAFaEJx1E2Y0KNSIZhV507DUKkH/DSGIDiIshwfFp1CM+O c4q53UipVV72npWcM+J+HsFGYSHSSF1b7B5PNLN3lJb0NaTvDuYN1F3leZiLXbMKflil 1ad/wK8ymRSedqeSIyPkMRjT7l3MW1TEwqbzZPshzUsTbe0o8/VxBhu/6tI0W/VS8sNi Y0SMOH5MY5n4ydCIQtdb6IBjEXxtYB1E53YJEWgJnBOS7En3Bg8sW/BUgizYBrPScp51 1RQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=adG6uzpbviDnP1EzUSUu63ppaq/APxuHaE8PTZk2J7Q=; b=onRDBCa/JH2b0MGCS0k96NBFnoZS7ccWk2vUGKn2skzw3YVQFmeZaTLcJHQN6YdNmJ DFYVddvSfVl9sm3KE28kXGuRzgbX7GydV6OIssS6SGw/xq/4QR+ZJBbHLaYR3kk9rjg3 2UyTnfa/fcEdqtAAE5IzotWQMYDIzLxhfVYSheAQaVxJPWZqkmibGwfUTzqxLGhjrAYi UXWXVT2DUp5V51V68qN+aZKxLgCKLDMXBTQfLK1Fq4SoadJ+OPMags/QhDIKjRMpL8mJ PdMcwW/KPTry9t8YPPHsBPzgNFXcjEf1AZfhFmxcqTFl2riOIBqKa57rkKzDX25oTLqQ sIoQ==
X-Gm-Message-State: AOAM531nW0OHyn1H4xUMqQk9rnAKrX7anICWB7R5ULnPZZU7yulVcKR2 IZF9AFpzVamF6dmszAKj5KXdUtLmHZW6zYAR5XI=
X-Google-Smtp-Source: ABdhPJy4CPs4CmMCobjFfPHtEt4QAgZ0UPAj4wkZlPWscf+aNGKq+3SlLAb7iq/R10JOfZFERWa7HhrdpERXBXjsKVw=
X-Received: by 2002:a1f:50c5:: with SMTP id e188mr5880706vkb.19.1615490015295; Thu, 11 Mar 2021 11:13:35 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ira McDonald <>
Date: Thu, 11 Mar 2021 14:13:24 -0500
Message-ID: <>
To: Laurence Lundblade <>
Cc: "Smith, Ned" <>, "" <>, Guy Fedorkow <>, Eliot Lear <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000007ffbe305bd4794a7"
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 19:13:40 -0000

Hi Laurence,

Thanks to the wonderful *free* IEEE Get 802 program, you can go to this
link (from Guy earlier)
and create your own durable free Get 802 account and then download IEEE
802.1AR-2018 (and
anything else from the whole IEEE 802 series that you need).

- Ira

On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <>

> I want to unpack and unfold a few things here.
> *Permanence / Lifecycle / Privacy — *I think the main topic here is about
> when an ID changes relative to the lifecycle of the device and how this
> relates to privacy.
> *Compromise — *I think compromise due to algorithms being compromised or
> the device being owned or such is a separate topic. Discussion of it seems
> orthogonal, should go into security considerations and really comes down to
> certification in the end if you really want to lock it down.
> I’m not sure which is meant by “immutability” in the previous emails.
> My intent in the definition of UEID was that it is truly permanent. It
> doesn’t change at any time in the lifecycle of the device. This is the
> simplest case to describe. It is not at all privacy preserving for some use
> cases (e.g., mobile phone), but is OK for others (e.g., dumb sensor).
> I was thinking other folks might define other IDs for other use cases.
> Maybe the time has come to invent one or two of those and put them in EAT.
> *Some Solutions*
> One possibility is an SUEID, a semi-permanent UEID (maybe not use SPUIED).
> It is allowed to change in major events in the devices lifecycle such as
> events when ownership changes, the managing entity changes or on factory
> reset. I think this lines up with the way some MAC addresses are managed
> for privacy reasons. This line up is good because a UEID can be an IEEE MAC.
> An RP might receive an EAT with only an UEID, only an SPUEID or both. The
> RP can decide what they want to use.
> Another one is for the Attester to authenticate the Verifier and/or
> Relying Party and generate a distinct UEID or SUEID just for use by that
> RP. This is a solution to the privacy issue. I’ve actually done an
> implementation of this one.
> A related solution is to have a privacy proxy between the Attester and the
> Verifier that makes RP-specific UEIDs or SUEIDs.
> *Separation of ID from Attestation Key*
> An ID that is not signed is nearly useless because anyone can forge it so
> we’re always talking about some sort of signing.
> EAT intentionally separates the ID from the signing key. I haven’t read
> IDevID, but I don’t think it has this separation. The reason EAT separates
> them is to have a lot of flexibility to deal with the privacy and lifecycle
> issues that come up in real deployments for chip makers and complex supply
> chains.
> For example, FIDO uses group attestation keys to deal with the privacy
> issue. One key is put into 100,000 plus devices which makes it
> statistically not very useful for tracking users. Maybe the device
> manufacture uses this tactic for billions of devices. Then maybe a use case
> involving only millions of these devices needs a truly global ID and have
> the means to program it. This can work if the keys and IDs are separate.
> Or maybe the manufacturer changes signing schemes moving from a primitive
> MAC to EC-based pub key and onto some sort of DAA while maintaining the
> same scheme for device IDs.
> *Possible harmonization with other Device IDs?*
> I noticed that birkholz-rats-suit-claims
> <> mentions
> a device ID based on UUIDs. We should probably take a look at how this
> relates UEID. There’s probably others to check out. We probably want to re
> use a lot of the claims from Evidence in Attestation Results so they can be
> pass-through for the Verifier.
> Note also that UUIDs are obsolete now.
> LL
> P.S., Any suggestions on how to get access to IEEE IDevID? I’m not part of
> a big company. I tried joining IEEE once, but that wasn’t enough to get
> access.
> _______________________________________________
> RATS mailing list