Subject: Re: [Iotops] [Rats] 802.1AR device identity

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Mar 2021 21:27:10 +0100

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 <[email-masked]> 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 <[email-masked]> on behalf of Guy Fedorkow <gfedorkow=[email-masked]>
> Date: Wednesday, March 10, 2021 at 7:59 AM
> To: Laurence Lundblade <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 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/ <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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 10 Mar 2021 21:09:38 +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 <[email-masked]>
Date: Wednesday, March 10, 2021 at 12:27 PM
To: "Smith, Ned" <[email-masked]>
Cc: Guy Fedorkow <gfedorkow=[email-masked]>, Laurence Lundblade <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>
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?

Eliot

On 10 Mar 2021, at 20:02, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

-Ned
From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Guy Fedorkow <gfedorkow=[email-masked]<mailto:gfedorkow=[email-masked]>>
Date: Wednesday, March 10, 2021 at 7:59 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Rats] 802.1AR device identity

Hi Laurence,
https://1.ieee802.org/security/802-1ar/

Juniper Business Use Only
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Mar 2021 10:53:50 +0100

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).

Eliot

> On 10 Mar 2021, at 22:09, Smith, Ned <[email-masked]> wrote:
> 
>> On 10 Mar 2021, at 20:02, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of Guy Fedorkow <gfedorkow=[email-masked] <mailto:gfedorkow=[email-masked]>>
>> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 11 Mar 2021 16:16:47 +0000

See inline nms>.
From: Eliot Lear <[email-masked]>
Date: Thursday, March 11, 2021 at 1:54 AM
To: "Smith, Ned" <[email-masked]>
Cc: Guy Fedorkow <gfedorkow=[email-masked]>, Laurence Lundblade <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] 802.1AR device identity

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).
Nms> I’m not familiar with the FDO acronym (First Device Onboard?) or how the 802.1AR use case context for iDevID/LDevID relates to ledger based transfers. This feels like a deep topic that maybe should be a talk or slides that the RATS WG understands better?

Eliot

On 10 Mar 2021, at 22:09, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

From: Eliot Lear <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 10, 2021 at 12:27 PM
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Cc: Guy Fedorkow <gfedorkow=[email-masked]<mailto:gfedorkow=[email-masked]>>, Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
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?

Eliot

-Ned

Hi Laurence,

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 11 Mar 2021 11:00:14 -0800

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 <https://tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt> 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.

---

From: Ira McDonald <[email-masked]>
Date: Thu, 11 Mar 2021 14:13:24 -0500

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).

Cheers,
- Ira

On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <[email-masked]>
wrote:

> *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.
>
> 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.
>
> 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
> <https://tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt> 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.
>
> 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.
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Mar 2021 20:34:41 -0500

Eliot Lear <lear=[email-masked]> wrote:
    > Yeah, this is an issue that comes up from time to time.  How
    > “immutable” should that iDevID be?

I take the approach that the IDevID that was shipped from the factory can not
be replaced without a device recall.

(It could be that there are modes where another IDevID can be installed, but
the original would not be removed.  Whether this is an LDevID or IDevID is
open to intepretation)

    > 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?

Then, the device is broken.
I think you would certainly agree that this can be the only answer if the
software signing key is compromised, right?

    > Can one recover with an update?

Please define "dink" for me.  I know of only one definition from the school yard.
Does this mean remove? replace?

    > 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.

Can you give me an example of one of these attributes?
This sounds like the FIDO situation, from section 6.3 of (my) the usecase
document:

   According to [fidotechnote] FIDO uses attestation to make claims
   about the kind of device which is be used to enroll.  Keypairs are
   generated on a per-device _model_ basis, with a certificate having a
   trust chain that leads back to a well-known root certificate.  It is
   expected that as many as 100,000 devices in a production run would
   have the same public and private key pair.  One assumes that this is
   stored in a tamper-proof TPM so it is relatively difficult to get
   this key out.  The use of this key attests to the the device type,
   and the kind of protections for keys that the relying party may
   assume, not to the identity of the end user.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Mar 2021 09:22:44 +0100

[moving rats to bcc… continuing discussion on iotops]

Hi Michael,

> the original would not be removed.  Whether this is an LDevID or IDevID is

Yes.

> software signing key is compromised, right?

The device is vulnerable.  The question is whether a repair can be effected.

> Does this mean remove? replace?

Yes.

> Can you give me an example of one of these attributes?

Soooo…. Here’s an example:

Suppose I am a system integrator who needs to assemble a device out of constituent components that includes a particular software load.  I wish to claim to be the manufacturer of the device, as I am the one producing the final product.  I want to therefore provide the onboarding service.  That requires a change of URL for the MASA in BRSKI terms.  I may also wish to change the MUD-URL based on the software load.

The core question I am asking is this: we have attributes about the device I these certificates that really could be elsewhere.  But where?

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Sun, 14 Mar 2021 14:14:10 -0400

Eliot Lear <[email-masked]> wrote:
    >>> These are attestations of a form, but they’re not really
    >>> measurements, as has been previously discussed here.
    >>

    > Suppose I am a system integrator who needs to assemble a device out of
    > constituent components that includes a particular software load.  I
    > wish to claim to be the manufacturer of the device, as I am the one
    > producing the final product.  I want to therefore provide the
    > onboarding service.  That requires a change of URL for the MASA in
    > BRSKI terms.  I may also wish to change the MUD-URL based on the
    > software load.

    > The core question I am asking is this: we have attributes about the
    > device I these certificates that really could be elsewhere.  But where?

It seems clear that the assembler needs to create a new IDevID, and they need
to store it somewhere, and it needs to express itself rather than the
individual components.

It seems to me that if one can effect to load a particular software, then one
ought to have control via that software load of the onboarding and which
IDevID is expressed.

Remembering that we invented multitasking because CPUs were very expensive,
leading eventually to virtualization and containers, but that most of our
security issues are the result of sharing of resources, I suggest that maybe
the answer here is to stop sharing when doing an assembly.
The "control plane" CPU for the assembly doesn't have to actually do any of
the work other than coordination and onboarding.

That having a $3 ATMEGA MCU hold all of the desired upward (for onboarding of
the assembly) and downward (for keeping track of the onboard components)
might make the most sense.
I don't think that's a big cost for an assembler if the assembly is worth
thousands to fractions of millons.

(I come back to the bogie assembly for a railcar, which has got to be worth a
fair bit.  Also: airplanes and cars.
However, we should think about smaller assemblies as well, including things
like a desktop computer's CPUs, GPUs and MCUs in keyboards and hard disks.
Component stereo/AV systems in homes and in theatres.)

I'm not suggesting this MCU is an active Registrar, but rather, it's the
like it's the TPM/CA for a Registrar component that the assembler brings into
the do work stuff out.  A tool if you like.

So, it would store the credentials.   It's a superset of the KDC.
(insert storey about KDC that was drywalled in, but kept operating for years)

I would propose we think about the commonalities among onboarding solutions
(upward and downward), and probably we need to write a YANG module to explain
it all.   We should consider that one might use DPP to onboard the components
of an assembly, which then uses BRSKI to join a superior assembly, and that
superior assembly then uses FIDO-DO to be deployed.
We need to take into account Kerberos, OAUTH2/GNAP and ACE operational keys.

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 15 Mar 2021 13:30:34 +0000

I agree with Michael.  The IDevID in my point of view is as permanent as the serial number on the box or the VIN on your car.  
I think DevID could have privacy implications in some applications, so within TCG there have been proposals to download the IDevID at the customer's discretion, but in that case, it would have to be linked to TPM's EK (another immutable key), so there's still only one possible IDevID ever for a box.
  As noted, LDevIDs can be made and destroyed at will.
/guy

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Saturday, March 13, 2021 8:35 PM
To: Eliot Lear <lear=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Rats] [Iotops] 802.1AR device identity

[External Email. Be cautious of content]

    > “immutable” should that iDevID be?

I take the approach that the IDevID that was shipped from the factory can not be replaced without a device recall.

(It could be that there are modes where another IDevID can be installed, but the original would not be removed.  Whether this is an LDevID or IDevID is open to intepretation)

Then, the device is broken.
I think you would certainly agree that this can be the only answer if the software signing key is compromised, right?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Mar 2021 11:01:28 -0400

Guy Fedorkow <[email-masked]> wrote:
    > I agree with Michael.  The IDevID in my point of view is as permanent
    > as the serial number on the box or the VIN on your car.  I think DevID
    > could have privacy implications in some applications, so within TCG
    > there have been proposals to download the IDevID at the customer's
    > discretion, but in that case, it would have to be linked to TPM's EK
    > (another immutable key), so there's still only one possible IDevID ever
    > for a box.  As noted, LDevIDs can be made and destroyed at will.

Perhaps you said it more precisely than I.
The private key must be immutable and heavily protected (TPM or secure
enclave, etc.).

In draft-selander-ace-ake-authz-02 we describe a mechanism where the contents
of the IDevID are in fact downloaded by correspondants (Registrar) from the
manufacturer, rather than being transmitted over a challenged network.

I guess this would allow the manufacturer to resign in some ways, and maybe
even present different certificates depending upon who is asking.  But, the
serial-number identity that the device has and the connection to the private
key is immutable.

BTW: in the above document we encrypt (with ECIES) the identity to the
manufacturer.  Eliot's concern about which network should a pledge try first,
given many choices, remains.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 26 Mar 2021 11:20:56 -0700

I got my copy of 802-1AR.

I’ve made a PR <https://github.com/ietf-rats-wg/eat/pull/101> that
   1) Adds an SUEID to EAT that is similar to LDevID in that it can change on device life-cycle events
   2) Adds a whole appendix discussing the relation of IDevID to EAT

From reading 802.1AR, it’s pretty clear that IDevID is permanent. Here’s one sentence:
These additional operations can include deletion of the IDevID certificate or IDevID key, which can be logically equivalent to decommissioning the device, 

802.1AR also provides for an LDevID that is less permanent in the ways that Giri seems to be asking for.

Please take a lot at the PR. It does a little compare and contrast between EAT and IDevID. I am interested in comments on it.

LL

> On Mar 11, 2021, at 11:13 AM, Ira McDonald <[email-masked]> wrote:
> 
> 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
> On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote: