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

[Toerless Eckert <[e-mail]>]

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:
> Device onboarding is probably the most prevalent use case for IDevID. But that is only a guess.
> 
> From: Laurence Lundblade <[e-mail]>
> Date: Tuesday, April 13, 2021 at 12:26 PM
> To: Guy Fedorkow <[e-mail]>
> Cc: Ira McDonald <[e-mail]>, "[e-mail]" <[e-mail]>, "Smith, Ned" <[e-mail]>, Eliot Lear <[e-mail]>, "[e-mail]" <[e-mail]>, Henk Berkholz <[e-mail]>
> Subject: Re: [Rats] 802.1AR device identity
> 
> 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 <[e-mail]<mailto:[e-mail]>> 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.
>   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 <[e-mail]<mailto:[e-mail]>>
> Sent: Friday, March 26, 2021 2:21 PM
> To: Ira McDonald <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; Smith, Ned <[e-mail]<mailto:[e-mail]>>; Eliot Lear <[e-mail]<mailto:[e-mail]>>; Guy Fedorkow <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats
> 

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


-- 
---
[e-mail]