Re: [Rats] EAT claims needed by TEEP

[Laurence Lundblade <[e-mail]>]

I’m update the PR for thi <https://github.com/ietf-rats-wg/eat/pull/139>s a lot:

* It is for OEM’s to identify individual products, models and variants

* It is only required to be unique for a given OEM. It is the combo of OEM ID and class that globally identifies a product. This allows re use of internal product schemes, allows them to be very short and doesn’t require engaging with some global identification scheme (but an OEM can use a global scheme if they want).

* The receiver of this MUST treat this an an opaque binary byte string (This is the same as UEID). The receiver can only use this for lookup in a database and comparison for equality.

* The sender can base this off of OIDs, URLs, UUIDs, an RNG, internal product codes and so on, but they SHOULD make it not human-readable (hash or such).

* I really don’t think we want to identify that it is an OID, URI or such because it is more work for the receiver to decode and because we don’t want the receiver doing anything with the internal structure.

* Added examples (that check against the CDDL).

LL



> On Nov 12, 2021, at 8:46 AM, Laurence Lundblade <[e-mail]> wrote:
> 
> I’d like to articulate the larger frame up for identifying HW in EAT. The applicability is all HW, not just TEEs.
> 
> I think it is the concatenation of these three:
>    - OEM ID
>    - Model/Class
>    - Version
> 
> EAT draft 11 is missing model/class. It is good that TEEP brought this to our attention.
> 
> I have preference for “model” over “class”. Lots of things have model numbers (cars, TVs, phones…), and we know what is meant by a model number. The term “class" confused me and may confuse others (perhaps because there was little descriptive text or examples of real devices and “class" is usually for broad taxonomies like fruit vs vegetable).
> 
> I think the current proposal <https://github.com/ietf-rats-wg/eat/pull/139> of a byte string for model/class is fine. I don’t see the point of it being an OID or URL since it is not a global identifier.
> 
> I think having general HW identification split into three is useful because sometimes you care solely about OEM, sometimes you care right down to the version number.
> 
> The OEM ID must be a global identifier, but model and version are local to an OEM. Each OEM has their own model number scheme and that is fine. The product team for a particular model comes up with their version scheme, and that is fine. This seems parallels how the world mostly works for all sorts of HW.
> 
> The main thing a recipient does with an OEM ID and model is lookup them up in a database or compare them for equality, so we don’t need to specify any internal structure for a recipient to decode. The simpler they are, the better.
> 
> Version is different. We like comparing it for greater than and less than because there’s a good possibility that two versions of the hardware are compatible with some SW or such. Compatibility is less likely for models so lookup/equality is enough. To allow version comparison, EAT uses CoSWID version identifiers <https://www.ietf.org/archive/id/draft-ietf-sacm-coswid-19.html#name-version-scheme> which indicates how comparison works.
> 
> Another very useful thing here is to re use identifiers that already exist. In EAT the OEM is identified by existing OEM databases (PEN <https://en.wikipedia.org/wiki/Private_Enterprise_Number> or IEEE OUI <https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf>, aka MAC address) or a 16-byte random number (which can be a UUID). We want OEMs to be able to re-use their extant internal model and version number schemes, so they are both strings (and can also be UUIDs).
> 
> Here’s real examples:
> 
>    OEM: 49279 (PEN actually assigned to Tesla)
>    Model: “X"
>    Version “2.3.2” (CoSWID type 1, multipartnumeric)
> 
>    OEM: 00A0C6  (OUI assigned to Qualcomm)
>    Model: “Snapdragon 888”
>    Version: “23” (CoSWID type 4, decimal)
> 
>    OEM: D0D003 (OUI assigned to Samsung)
>    Model: 042aea10a0f14f2d391373599be69d53a7 (One-time randomly generated model ID for Samsung’s implementation of a particular ARM TEE)
>    Version: “1.3c” (CoSWID type 2, multipartnumeric+suffix)
> 
> By one-time generated, I mean that an RNG was run once off the device and written down to be used for years to identify the particular TEE model/class. If it is a UUID, then it isn’t generated on the device being attested to, but on some administrative laptop or such, written down and the same one used for years on millions of devices.
> 
> LL
> 
> 
> 
> 
>> On Nov 11, 2021, at 5:38 PM, Ira McDonald <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi,
>> 
>> +1 to Brendan's point about why "human-readable" strings are a *bad* idea for 
>> hardware type identifiers.  
>> 
>> +1 to Thomas and Jeremy's observations.
>> 
>> Cheers,
>> - Ira
>> 
>> Ira McDonald (Musician / Software Architect)
>> Chair - SAE Trust Anchors and Authentication TF
>> Co-Chair - TCG Trusted Mobility Solutions WG
>> Co-Chair - TCG Metadata Access Protocol SG
>> Chair - Linux Foundation Open Printing WG
>> Secretary - IEEE-ISTO Printer Working Group
>> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
>> IETF Designated Expert - IPP & Printer MIB
>> Blue Roof Music / High North Inc
>> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
>> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
>> mailto: [e-mail] <mailto:[e-mail]>
>> (permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434
>> 
>> 
>> On Thu, Nov 11, 2021 at 8:43 AM Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Thomas Fossati <[e-mail] <mailto:[e-mail]>> wrote:
>>     > Besides, it looks like we'd be creating a bad precedent because then one
>>     > could easily argue that *every* claim is possibly just a byte string or,
>>     > pushing this line of reasoning just a bit further, the whole claims-set
>>     > could be seen as one single gigantic opaque claim.
>> 
>> ! make me think about the multiple levels of "comment" that occured in the
>> JCL days, where commands were comments...
>> 
>> Brendan Moran <[e-mail] <mailto:[e-mail]>> wrote:
>>     > Strings are not the right choice for machine readable fields. There are
>>     > extremely good reasons not to use them. Please do not use strings for
>>     > model IDs.
>> 
>>     > When you have a string, it is inevitable that someone in marketing will
>>     > realise that it’s human-readable. The next step is that it must be
>>     > controlled to preserve brand image. When this happens, it is also
>>     > inevitable that *wildly incompatible hardware* with *the same function*
>>     > will be forced into the same “model number.”
>> 
>> This has happened multiple times out there.
>> Same box, same case, entirely different CPU inside.
>> 
>>     > By making model identification explicitly non-parseable by humans, we
>>     > prohibit its use as a controllable, human facing identifier. This
>>     > ensures that it has a better chance of being used correctly as a means
>>     > to distinguish between mutually incompatible versions.
>> 
>> !
>> 
>> mcr suggested>
>> 
>>   "There is no global scheme or format for this claim."
>>     ->
>>   "The format for this scheme will need to be specified within profiles that use it."
>> 
>> 
>> --
>> Michael Richardson <[e-mail] <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> 
>> 
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats