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

From: Guy Fedorkow <[email-masked]>
Date: Fri, 2 Apr 2021 17:05:13 +0000

Hi Laurence,
  I agree that IDevID is intended to persist through the device's lifetime, while LDevID is meant to represent the current owner.
  In TCG-land, an IDevID is not advised for signing attestation evidence; its role is limited to identity, providing proof of the supplier and the real-world identity of the device (i.e., serial number).
  With TPM1.2 it's actually not possible to use the IDevID to sign TPM attestation evidence, as a counter-measure to block spoofing by an attacker, so the TCG docs advise a separate attestation key with a binding that links them to the same TPM.  I think that's not actually necessary in TPM2, although the advice for separation remains.
  So in that context the sentence "[EAT] separates the signing scheme from the identification scheme" seems puzzling.

  But in the EAT environment, where there's no technological block to an attacker with access to the key to spoof an attestation result, I agree that the DevID could be used to sign an EAT token carrying attestation evidence.

  Let me know if I'm missing the point!
Thx
/guy

Juniper Business Use Only
From: Laurence Lundblade <[email-masked]>
Sent: Friday, March 26, 2021 2:21 PM
To: Ira McDonald <[email-masked]>
Cc: [email-masked]; Smith, Ned <[email-masked]>; Eliot Lear <[email-masked]>; Guy Fedorkow <[email-masked]>; [email-masked]
Subject: Re: [Rats] 802.1AR device identity

[External Email. Be cautious of content]

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]<mailto:[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
anything else from the whole IEEE 802 series that you need).

https://1.ieee802.org/security/802-1ar/<https://urldefense.com/v3/__https:/1.ieee802.org/security/802-1ar/__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31Q-lsLJs$>

Cheers,
- Ira

On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:
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://urldefense.com/v3/__https:/tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31d19M7lw$> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31_KoAAkI$>
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 13 Apr 2021 12:26:26 -0700

Thanks for the comments, Guy. Appreciate it.

Agreed that repurposing IDevID keys for EAT might be a bit weird and wrong, but it is still really useful to understand how they are intended to work and are actually used to help with the design of EAT.

802.1AR section 7.2.5 say the keys can be used for signing. Appendix B has it participating in an EAT-TLS session and gives some other very general use cases.  No matter what, the key has to be used to sign a nonce for proof of possession, so there is some signing of external data going on.

https://www.trustedcomputinggroup.org/wp-content/uploads/TPM_Keys_for_Platform_Identity_v1_0_r3_Final.pdf lists a whole bunch more use cases like IKE. Do these really get implemented? 

What are the popular and widely deployed use cases for IDevID?

I kind of want EAT to learn from IDevID here. To understand what IDevID is about so that EAT is more capable and fits in better with use cases.

LL

> On Apr 2, 2021, at 10:05 AM, Guy Fedorkow <[email-masked]> wrote:
> 
> Hi Laurence,
>   I agree that IDevID is intended to persist through the device’s lifetime, while LDevID is meant to represent the current owner.
>   With TPM1.2 it’s actually not possible to use the IDevID to sign TPM attestation evidence, as a counter-measure to block spoofing by an attacker, so the TCG docs advise a separate attestation key with a binding that links them to the same TPM.  I think that’s not actually necessary in TPM2, although the advice for separation remains.
>   So in that context the sentence “[EAT] separates the signing scheme from the identification scheme” seems puzzling.
>  
>   But in the EAT environment, where there’s no technological block to an attacker with access to the key to spoof an attestation result, I agree that the DevID could be used to sign an EAT token carrying attestation evidence.
>  
>   Let me know if I’m missing the point!
> Thx
> /guy
>  
>  
>  
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>> 
> To: Ira McDonald <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Smith, Ned <[email-masked] <mailto:[email-masked]>>; Eliot Lear <[email-masked] <mailto:[email-masked]>>; Guy Fedorkow <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> I’ve made a PR <https://github.com/ietf-rats-wg/eat/pull/101> that
> From reading 802.1AR, it’s pretty clear that IDevID is permanent. Here’s one sentence:
> On Mar 11, 2021, at 11:13 AM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Laurence,
>  
> https://1.ieee802.org/security/802-1ar/ <https://urldefense.com/v3/__https:/1.ieee802.org/security/802-1ar/__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31Q-lsLJs$>
>  
> Cheers,
> - Ira
>  
>  
>  
> On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <[email-masked] <mailto:[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.
>  
> 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). 
>  
> 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.
>  
>  
> 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.
>  
> I noticed that birkholz-rats-suit-claims <https://urldefense.com/v3/__https:/tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31d19M7lw$> 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.
>  
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31_KoAAkI$>
> [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: Fri, 16 Apr 2021 17:55:00 +0000

Device onboarding is probably the most prevalent use case for IDevID. But that is only a guess.

From: Laurence Lundblade <[email-masked]>
Date: Tuesday, April 13, 2021 at 12:26 PM
To: Guy Fedorkow <[email-masked]>
Cc: Ira McDonald <[email-masked]>, "[email-masked]" <[email-masked]>, "Smith, Ned" <[email-masked]>, Eliot Lear <[email-masked]>, "[email-masked]" <[email-masked]>, Henk Berkholz <[email-masked]>
Subject: Re: [Rats] 802.1AR device identity

LL

On Apr 2, 2021, at 10:05 AM, Guy Fedorkow <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Juniper Business Use Only
From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 26, 2021 2:21 PM
To: Ira McDonald <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Smith, Ned <[email-masked]<mailto:[email-masked]>>; Eliot Lear <[email-masked]<mailto:[email-masked]>>; Guy Fedorkow <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] 802.1AR device identity

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

LL

Hi Laurence,

Cheers,
- Ira

Some Solutions

Possible harmonization with other Device IDs?
I noticed that birkholz-rats-suit-claims<https://urldefense.com/v3/__https:/tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31d19M7lw$> 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.

LL

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 16 Apr 2021 20:22:08 +0200

There are uses of IDevID as crypto material for e.g. mutual authentication
of seecured connection, seemingly designed by folks who where not really
aware of the security properties. Aka: they are used for stuff that does not work.
I would ignore such uses (irrelevant).

For onboarding, one of the IMHO wisdoms developed in IEF WGs including
netconf and anima is that you want to avoid the need for ongoing use of
the IDevID by enrolling an LDevID during onboarding. Key exhaustion
being one reason, but also higher utility of LDevID, such as (can i call it)
attestation of who the owner of the device is (which IDevID does not say).

I am not on top of EATs. If all the attestation is "immutable", aka:
whatever the operator does (config, firmware changes), the vendor can
guarantee that the attestation result will not be impacted by the owner/operator,
then i think it is logically appropriate to use the IDevID. Key exhaustion
of the IDevID could be avoided by creating a new keypair/certificate
locally on the device/TPM and then just use the IDevID to sign that
secondary cert (as a local TA). Call the new cert an Attestation-IDevID ?

If the owner/operator can have an impact on the outcome of attestation,
it should logically (IMHO) be signed with an LDevID. If the device
does not want to support enrollment of LDevID, then hopefully expose
in the attestation very explicitly any operator impact on the attestation
result.

Cheers
  Toerless

On Fri, Apr 16, 2021 at 05:55:00PM +0000, Smith, Ned wrote:
>   I agree that IDevID is intended to persist through the device???s lifetime, while LDevID is meant to represent the current owner.
>   With TPM1.2 it???s actually not possible to use the IDevID to sign TPM attestation evidence, as a counter-measure to block spoofing by an attacker, so the TCG docs advise a separate attestation key with a binding that links them to the same TPM.  I think that???s not actually necessary in TPM2, although the advice for separation remains.
>   So in that context the sentence ???[EAT] separates the signing scheme from the identification scheme??? seems puzzling.
> 
>   But in the EAT environment, where there???s no technological block to an attacker with access to the key to spoof an attestation result, I agree that the DevID could be used to sign an EAT token carrying attestation evidence.
> 
>   Let me know if I???m missing the point!
> Thx
> /guy
> 
> 
> 
> I???ve made a PR<https://github.com/ietf-rats-wg/eat/pull/101> that
> From reading 802.1AR, it???s pretty clear that IDevID is permanent. Here???s one sentence:
> 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).
> 
> 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.
> 
> 
> 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.
> 
> I noticed that birkholz-rats-suit-claims<https://urldefense.com/v3/__https:/tools.ietf.org/id/draft-birkholz-rats-suit-claims-01.txt__;!!NEt6yMaO-gk!VIgfoJIZw6f-tQTWp0Sjo-VrLZQ-MpJRbtxsJaUCztshzqfy3ZhCgNP2Hn31d19M7lw$> 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.
> 
> 
> 

> -- 
> Iotops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iotops

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Apr 2021 12:49:22 -0400

> IDevID. But that is only a guess.

I hope it will be, but I don't think it is now.

I think that it is mostly used in desktop environments for NEA/Attestation.
In the mobile space, I'm not sure the built-in credentials that exist are quite IDevID.

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

---

From: Ash Wilson <[email-masked]>
Date: Sat, 17 Apr 2021 17:48:52 -0700

Joining the conversation a little late...

I think that while the IdevID was originally intended to be a life-long
birth certificate of sorts, improving the standard to allow certificate
rotation could be useful.

Keys become easier/cheaper to guess over time. Guessing the key will
eventually be easier and less expensive than compromising the TPM which
protects it. And not all implementations are created equal. For instance:
https://en.m.wikipedia.org/wiki/ROCA_vulnerability . If the certificate
can't be rotated, then even after a firmware update, you're stuck with a
vulnerable private key in a patched TPM.

Protocols exist to allow an entity to rotate its own certificate. If it
were possible to safely do so, wouldn't the security posture of a device be
improved by having some cryptographic agility for the identity's method for
proof-of-possession? Rotation frequency recommendations can be related to
the amount of time required to guess the private key. What if the device
could rotate its own key in a shorter period of time than an adversary
could guess it?

If the device's name is universally unique and the certificate is
discoverable using that name, then the certificate then becomes just a
means of proving possession of the name.

 A manufacturer could support the rotation of IdevID certificates through
an integration between the CA and the discovery mechanism.

Certificate rotation like this could work with DANE for client identity.

On Mon, Mar 15, 2021, 06:30 Guy Fedorkow <gfedorkow=
[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.
> /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
>
> 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?
>     > What if there are attributes in the cert that I want to
>     > dink and share with the deployment?
>
> 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.
>
>
> --

---

From: Eliot Lear <[email-masked]>
Date: Sun, 18 Apr 2021 15:51:51 +0200

Sorry for the delayed response:

> On 2 Apr 2021, at 19:05, Guy Fedorkow <[email-masked]> wrote:
> 
> Hi Laurence,

Yes, that was the original intent, and even the current intent.  And while that is necessary, it may not be sufficient for long supply chains where ownership passes from one to another.  The LDevID is an owner-assigned name, and so the question is this: when an owner goes to transfer, does it need to use the IDevID again or should it use the LDevID?  There are benefits and drawbacks to both, but if the LDevID is used, then it is used as the IDevID would have been as part of that transfer.  The nice thing about FDO is that it keeps an entire record of these sorts of transfers.

Eliot

---

From: Russ Housley <[email-masked]>
Date: Sun, 18 Apr 2021 13:31:19 -0400

> On Apr 18, 2021, at 9:51 AM, Eliot Lear <lear=[email-masked]> wrote:
> 
> Signed PGP part
>> On 2 Apr 2021, at 19:05, Guy Fedorkow <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Laurence,

I think it depends on whether the new owner trusts the issuer of the LDevID.  If so, then leveraging the existing LDevID may be straightforward.  If the new owner does not trust the issuer of the LDevID, then resetting the device to the factory default settings, which would include the IDevID, makes a lot of sense.

Russ

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 19 Apr 2021 12:24:00 +0000

Hi Laurence,

  I agree that onboarding is the most-obvious use-case.  Security-related configuration that should be applied only to specific identified devices is another use.

  I think of IDevID as the serial number plate the manufacturer etches into a laptop, while LDevID is the asset tag the corporate IT department or its outsourced supplier sticks on the laptop.

  If you’re using the laptop in the same corporate context, the asset tag number is the uniform identifier across the org, and that’s likely to be the right thing to use.  If you bought it on ebay, use the IDevID!

  But it seems clear 802.1AR wasn’t designed with the intent of tracking devices through a chain of owners.  For that you might want something like the TCG Platform Certificate.

  /guy

From: Eliot Lear <[email-masked]> 
Sent: Sunday, April 18, 2021 9:52 AM
To: Guy Fedorkow <[email-masked]>
Cc: Laurence Lundblade <[email-masked]>; Ira McDonald <[email-masked]>; [email-masked]; Smith, Ned <[email-masked]>; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Rats] 802.1AR device identity

	On 2 Apr 2021, at 19:05, Guy Fedorkow <[email-masked] <mailto:[email-masked]> > wrote:

	Hi Laurence,

Eliot

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 21 Apr 2021 23:19:53 +0000

It is reasonable, in the context of onboarding, where the owner isn’t a supply chain entity, but the network owner who is going to deploy / manage the device. Onboarding might involve separately evaluating the supply chain risk and any ‘owner’ that might be a supplier from onboarding processes that take a clean room approach that wipe clean / reset to mfg defaults.

An mfg IDevID design might be such that tampering by supply chain ‘owners’ would be detected and hence trusting them isn’t really necessary. The end user / customer as ‘owner’ might only care about trusting the IDevID mfg or only trusting him/her self.

From: Russ Housley <[email-masked]>
Date: Sunday, April 18, 2021 at 10:31 AM
To: Eliot Lear <lear=[email-masked]>
Cc: Guy Fedorkow <[email-masked]>, "Smith, Ned" <[email-masked]>, Henk Berkholz <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Laurence Lundblade <[email-masked]>, Ira McDonald <[email-masked]>
Subject: Re: [Rats] 802.1AR device identity

On Apr 18, 2021, at 9:51 AM, Eliot Lear <lear=[email-masked]<mailto:lear=[email-masked]>> wrote:

Signed PGP part

On 2 Apr 2021, at 19:05, Guy Fedorkow <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

Russ

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 23 Apr 2021 11:16:14 -0700

Thanks for all the helpful responses and info here. 

I believe the discussion and comments received validate the EAT design of a UEID and an SUEID.

UEID
- Permanent. Set by device or chip manufacturer.
- Can’t be changed by subsequent owners or any in down-stream supply chain
- Akin to IDevID

SUEID
- Semi-permanent. Can be set by new owners of the device, down stream entities in the supply chain and so on
- Changed on major device lifecycle events
- Akin to LDevID

The current SUIED PR doesn’t allow multiple SUIED’s the way you can have multiple LDevIDs. I think EAT needs to allow multiple SUIEDs.

Option 1 — A simple array of SUEIDs. You can’t really tell one from another or who assigned them.

Option 2 — Each SUEID is a pair of the SUEID plus a string naming the entity that created it or naming a type of SEUID.

Option 3 ?

My understanding is that one LDevID is distinguished from another by the issuer in the LDevID certificate. EAT doesn’t have these separate certificates.

EAT can use the same attestation key to sign one UEID and many SUEIDs. EAT can also have separate attestation keys for each SUEID. It can be used to implement the IDevID/LDevID model and/or other models.

LL

> On Apr 21, 2021, at 4:19 PM, Smith, Ned <[email-masked]> wrote:
> 
>> On Apr 18, 2021, at 9:51 AM, Eliot Lear <lear=[email-masked] <mailto:lear=[email-masked]>> wrote:
>>  
>> Signed PGP part
> [email-masked]

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 23 Apr 2021 11:25:32 -0700

In the spirit of trying to understand use cases for UEID and SUEID I looked at SUIT device identifiers.

I also think we should consider SUIT’s device identifier here. It seems like a UEID or an SUEID could be used as the SUIT device-identifier or to derive the SUIT device-identifier. The description of SUIT’s device identifier is short, but I think all the EAT UEID types fulfills SUITs semantic requirements — uniquely identifying the device.

However, they differ in syntax and mechanics.

I consider UUID’s obsolete for many of the use cases they are applied to. These reasons are carefully described in Appendix B of EAT <https://tools.ietf.org/html/draft-ietf-rats-eat-09#appendix-B.2>. Basically with the wide availability of good crypto-quality RNG’s, the techniques UUID specifies are unnecessary and a burden.  I think SUIT device identifier is one of the use cases.

Also, UUID’s are confusing because not all types can be used for all use cases.

My suggestion to solve this would be to make SUIT device identifiers just byte strings that can be 128, 192 or 256 bits long. SUIT removes the UUID format requirement for device identifiers.

Then a type 1 UEID could just be used as is for a SUIT device identifier. 

Type 2 (MAC) and type 3 (IMEI) UEIDs could be run through a hash to make a SUIT device identifier.

If EAT were further along as a standard, I’d suggest SUIT just used UEID, but I don’t think we want SUIT to become dependent on EAT. What I’m proposing here gives a soft coupling.

LL

> On Apr 23, 2021, at 11:16 AM, Laurence Lundblade <[email-masked]> wrote:
> 
>> On Apr 21, 2021, at 4:19 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Russ Housley <[email-masked] <mailto:[email-masked]>>
>> To: Eliot Lear <lear=[email-masked] <mailto:lear=[email-masked]>>
>> Cc: Guy Fedorkow <[email-masked] <mailto:[email-masked]>>, "Smith, Ned" <[email-masked] <mailto:[email-masked]>>, Henk Berkholz <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Laurence Lundblade <[email-masked] <mailto:[email-masked]>>, Ira McDonald <[email-masked] <mailto:[email-masked]>>