Re: [Rats] About (E)UID's

[Simon Frost <[e-mail]>]

The PSA Certification program doesn’t include any proofing on the identities but devices are expected to follow the PSA Security model in that they can be uniquely identified within their manufacturing and/or provisioning chain. The PSA attestation report (see https://tools.ietf.org/html/draft-tschofenig-rats-psa-token-04) includes a claim for the unique instance identity but also an implementation ID (claim) that identifies this manufacturer origin, quoted in the specs as identifying the immutable PSA Root of Trust for the implementation. There is a logical extension to use a group identity with an Implementation ID for use cases where an individual instance identity may not be appropriate.

I agree that there should have a UEID claim within the standard and also with the proposed bitlength representations.

I suggest we should change the description of the UEID claim to allow the standard to support more interpretations of what the locus of uniqueness might be to an implementation.

HTH
Simon

From: Laurence Lundblade <[e-mail]>
Sent: 08 February 2020 23:25
To: Smith, Ned <[e-mail]>
Cc: Simon Frost <[e-mail]>; Salz, Rich <[e-mail]>; [e-mail]
Subject: Re: [Rats] About (E)UID's

Responding to Simon, manufacturers only have to follow the the specification. They don’t have to cooperate beyond that.

I think the bottom line on UEID uniqueness is that we can’t do much better in an IETF standard. We have no means of enforcement in the IETF. Note that there are IMEI and MAC address options which have some good uniqueness characteristics. There’s lots of things in IETF standards that people can get wrong and we live with them.

To really have enforcement a certification program is needed. There is one covering EAT partly in PSA certified<https://www.psacertified.org>, though I don’t know if there are requirements on the UEID.

The PR I just merged allows lengths of 128, 192 and 256 bits. 8 byte increments should be enough and 192 bits is enough for all use scenarios.

The privacy issue is already mentioned in the draft.

I think we have to have UEID in the standard even though it may not used when privacy preservation is necessary. Note that the verifier could be the guarantor of privacy in some use cases and filter it out.

I think it is possible to design a system where UEIDs are unique per relying party if you strongly authenticate the relying party. That is complex to do and probably not for the first round.

LL





On Feb 7, 2020, at 9:50 PM, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:

It was noted in the meeting that globally unique identifiers have privacy implications. One technique for protecting privacy is to limit the use of a particular identifier to a specific domain. Use in a different domain uses a different identifier making it hard to correlate transactions from Domain A with transactions in Domain B. This is essential to systems designed for privacy.

The IEEE802.1AR defines the notion of an IDevID and LDevID where the device receives a different identity following onboarding. Issuance of an LDevID has been used to protect privacy because within the community of devices sharing the same local context, they don’t recognize the device in terms of its IDevID identity. Not unless there is a UEID that is shared between the IDevID and the various LDevID credentials.

If UEID is defined to be globally unique, then it can’t be required for use if privacy is also needed.

I suspect implementations will ignore the wording in the EAT spec that asserts the value is globally unique and encode a value that is unique enough for their purposes. If there is some service out there that assumes global uniqueness but discovers collisions, then it will be a business decision whether or not to accept them.

Otherwise, the conversation for UEID should revolve around whether or not there are large domains that need an identifier that is unique within its domain. Based on the analysis there is enough space in 128-bits to allow for a domain of all people in the world being a member of the domain each bringing 100 – 100,000 things and where the things can be shared and exchanged within the domain context. I’m not aware of a real world use case for that domain. Hence, 128-bits with the flexibility to make them larger seems right. I like the suggestion to allow larger values in 8-bit increments because it allows the domain (of use) to optimize the cost/benefit trade-offs.

-Ned

From: RATS <[e-mail]<mailto:[e-mail]>> on behalf of Simon Frost <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 7, 2020 at 8:15 AM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>, "Salz, Rich" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] About (E)UID's

> While not stated overtly in the draft, UEIDs are intended to be the sole identifier needed to universally identify a device.

I think there’s a problem with the expectation here. The current UEID test says.

UEID's must be universally and globally unique across manufacturers and countries.
  <snip>
No two products anywhere, even in completely different industries made by two different manufacturers in two different countries should have the same UEID (if they are not global and universal in this way, then relying parties receiving them will have to track other characteristics of the device to keep devices distinct between manufacturers).

How do we expect this to be realised in practice? It implies that all manufacturers must cooperate to guarantee there are no dups, which will quickly break down. I think the most that can be expected for a UEID is that it be unique to a manufacturer and that the bracketed part of the second sentence will apply (e.g. considering origination / OEMID) unless the relying party is aware that their use case is satisfied by a dedicated supply chain.

Note that the signing key may be able to derive the locus for this in some use cases, but not all – there are circumstances with unique keys per instance.

Thanks
Simon

From: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Sent: 07 February 2020 12:14
To: Salz, Rich <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] About (E)UID's

While not stated overtly in the draft, UEIDs are intended to be the sole identifier needed to universally identify a device. This is to make life easiest for the relying party. They do not have to combine it with any other claims to uniquely identify a device. (Maybe I should add text explaining this)

This makes life simpler for the device maker and for us, as we don’t have to specify any rules that say what combination of claims must be used to get proper global uniqueness and device maker doesn’t have to figure how some system for uniqueness.

Generally, interdependency between claims seems like something to avoid for the sake of simplicity.

I’m reluctant to rely on public keys for anything but signature verification because I think we must support a variety of signing schemes some of which don’t have a typical public key. One of these will be HMAC for which there is no pubic key. Another is likely to be ECDAA or such where the verification key material is a bit more complex than a public key.

The vendor is also allowed to change signing schemes and the means of creating UEIDs in their manufacturing process.


Also, as described in the draft, the UEID as defined is very permanent. It never changes over the life of the device. Some of the UEID options are based on identifiers that are specifically not to change with owner, IMEI for example.

LL







On Feb 6, 2020, at 4:34 PM, Salz, Rich <[e-mail]<mailto:[e-mail]>> wrote:

I made a proposal during yesterday’s interim about EUID’s and I want to explain it here in more detail to the whole WG. I have made some clarifications.

We need ID’s.  Laurence has done a lot of good analysis on how many bits an ID needs to be to accommodate various users, devices, etc.  The TL;DR is that 128bits seems good for the size for now and at least the short-term future.

I suggest that the UID stays at 128bits. But in order to compare UID’s, relying parties should consider an “expanded” UID, which includes the SHA2 signature of the public signing key. For most cases, the “small” UID of 128 bits is sufficient to put into data structures, transport on the wire, and so on. Applications which present “unsigned” UID’s should either include a “key context” element, containing the hash. If not present, receiving applications should consider treat the key-id part as the SHA2 hash of the single zero byte.

One feature of this, as pointed out on the call, is that when a device gets a new owner, the expanded UID changes.

Hope this is useful.

_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.