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

[Ira McDonald <[e-mail]>]

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/

Cheers,
- Ira



On Thu, Mar 11, 2021 at 2:02 PM Laurence Lundblade <[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://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.
>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>