Re: [Rats] UEID comments (was Re: Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152)))

["Smith, Ned" <[e-mail]>]

My comments in green font. -Ned

From: Laurence Lundblade <[e-mail]>
Date: Tuesday, February 22, 2022 at 10:29 AM
To: "Smith, Ned" <[e-mail]>
Cc: Henk Berkholz <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: UEID comments (was Re: Same claim in Evidence and Results (was Re: [Rats] Second attempt at early allocation of CWT Labels (PR #152)))

Hi Ned,

Forking this discussion to focus on the UEID issues.


On Feb 21, 2022, at 12:22 PM, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:

(not as chair)
Laurence,
I wasn't advocating for limiting the scope of certain claims to a specific conceptual message. I'm suggesting that for a claim to be fully defined its definition should consider what the claim means in each conceptual message context.

For example, a computer that consists of a main board, cpu complex and nic / radio might have 3 UEIDs. Each component would be considered a 'device' by its manufacturer hence the requirement that only one UEID be used can be met. However, upon integration of these components, there are 3 UEIDs in the computer that could be reported in evidence. However, one of them will be considered the unique identifier for the computer from the perspective of identifying and authenticating the computer to a Verifier. Possibly the OEM would assert the OEM provided UEID is the computer identity or alternatively, the NIC UEID would be used considering it could be the logical endpoint of a secure connection.

This is just a simple example, but it highlights that context matters.

The EAT text "(Note that while devices with multiple network interfaces have multiple MAC addresses, there is only one UEID for a device)" if interpreted as normative could have profound impact on the supply chain if "device" is interpreted as "computer", in the above example, as it would require all the component vendors to remove their use of UEIDs. But in the context of the Verifier producing attestation results, the UEID that was used to establish the secure channel over which the computer was authenticated and appraised, then that UEID would likely be the right identifier to represent to the Relying Party - since that was the identifier that had the attestation credential.


There are issues like this for every claim in an EAT that is used to represent a composite device, not just UEIDs.
There could be clearer language about what constitutes a device, composite device, entity or a sub-module. I’ll use ‘entity’ to mean any of the above.  There are multiple structures that can represent the set of claims that belong to an entity.  For example, a token (CWT/JWT), UCCS or a submod could be used for the same or different entities.

But the language used to describe the claim (in some cases) implies a particular scope. I just picked on UEID as an example. Debug and hardware version are others as well. Since scope is defined by the entity that asserts the claims, it would be better to describe claims using terminology that doesn’t assume scope IMHO.

These composite device issues arise whether the EAT is Attestation Results or Evidence too. It is perfectly OK for some EATs to pass the deep structure of a complex device to a RP and for others to only pass a summary to the RP.

We’re not going to create any kind of protocol or system definition language here in RATS that can describe all composite devices. All we can do is provide basic constructs. Submods is the main construct for that.

Attestation systems based on EAT will vary widely. We can’t expect an attestation system that fully represents a complex mobile phone to also do small high-value IoT devices. Even on a mobile phone, there could be multiple implementations of EAT for different use cases that the mobile phone supports. Perhaps one for FIDO, one for the Android key store, several for content protection in different content handling apps...

There are other apparent contradictions in the UEID definition that require context to sort out. In the context of this wording "Several types are allowed to accommodate different industries and different manufacturing processes" it seems the intended context is Endorser / RVP.

All claims can be discussed from the manufacturer’s view separately from the consumer’s view. Someone has to generate them and someone has to consume them. Discussing the manufacturer’s view separately doesn’t imply semantics vary depending on who consumes them.
I guess I disagree. Someone implementing the spec wears the hat of one of the roles. It will be confusing if the descriptions randomly  switch hats.
The three types of UEID are from the manufacturer view only.
This then means the claims are asserted from an Endorser or RVP perspective. However, if the identifier was used to construct an identity (meaning the device could authenticate the identifier) then it is also a claim from the point of view of the device (entity).

Here are 4 examples:

(1)     a device might have an IMEI (UEID-A) and a type 1 random UEID (UEID-B). UEID-B is used in a device-id certificate while UEID-A is a value that exists in a NIC (and for the purposes of this example, doesn’t have an exposed interface to the code that is authenticating using UEID-B). A secure session between Verifier and Entity-B uses the certificate to associate UEID-B to entity-B. The UEID-B might not exist on the device at all. But the device is asserting UEID-B by using the private key of the certificate that contains UEID-B. Hence, there is both a mfg and a device perspective.

(2)     UEID-A exists on the device, but doesn’t appear in any evidence that entity-B generates. However, it could be included in a manifest or as an attribute to the certificate stating that the device (containing entity-A) has UEID-A. This is an endorsement since it doesn’t appear in evidence or a certificate. The fact that UEID-A exists on the device (even though the value wasn’t reported) means there is a device perspective.

(3)     Entity-A has an attesting environment that collects UEID-A as evidence. It isn’t used to authenticate the channel to the verifier so from the verifier’s perspective it isn’t an identity. From the device’s perspective it is evidence. This means the verifier should have a reference value claim for UEID-A, otherwise, it isn’t going to pass appraisal. This is a device perspective.

(4)     As a variation on (3), instead of including UEID-A in Evidence. It is included in a protocol data unit for a management interface that dumps configuration data. It isn’t endorsement or RV because it wasn’t signed by an Endorser / RVP. It isn’t evidence because it wasn’t signed by an Attesting Environment. But it did come from the device (entity), hence there’s a device perspective.


While another line "The consumer (the Relying Party) of a UEID MUST treat a UEID as a completely opaque string of bytes and not make any use of its internal structure." strongly implies Relying Party context.

If we make the text “The consumer (e.g., the Verifier or the RP) of a UEID…” then the text is fine. It is a minor adjustment to the text.

The text still holds. The consumer, be it the Verify or the RP, still treats the UEID exactly the same. There is no variance by context for UEID.
Since verifier and RP are supposed to treat UEID as opaque, there is nothing they can (should) do other than check binary equivalence. That means they only care about the number of bytes and byte order convention. Everything in the UEID type tables should be regarded as informative. But since the typing exists and the language for how the various types of UEIDs are constructed exists, it seems to contradict the idea that UEID values are opaque. It appears the normative language is aimed at manufacturers (Endorsers or RVPs), but there is no way to verify these properties are valid. A description of the properties in a document isn’t enforcement.


The type 2 UEID indicates the Endorser / RVP identity is included: "This makes use of the IEEE company identification registry." A type 2 UEID could be used to avoid having to use a separate vendor identity claim. But if the relying party must treat it as opaque, then something has to supply a vendor identity claim in some other way. Possibly, the Verifier extracts the vendor ID from the UEID and recasts it in some other form?

The separate vendor ID claims exists. It is the HW OEM ID. The document mentions this explicitly. There is no issue here.
The issue is that the draft requires a type 2 UEID to include a manufacturer identifier. If it isn’t used (at the end of the day) why put it in the document? It should at least be marked as informative.



Another apparent contradiction is:
"Device manufacturers are allowed to change from one type of UEID to another anytime they want."
And
"The UEID is permanent. It never change for a given device / entity."

If a manufacturer changes the device identity, say because they re-manufactured the device after deployment by retiring an embedded key that possibly has worn out or was compromised, and therefore wanted to give the device a new identity. Then it is unclear which of these statements normatively applies. Possibly, the first statement applies in the context of Endorsement / Reference Values while the second statement applies in the context of Evidence collection (where an observed change in UEID would be a red flag if it changed from one attestation event to the next).

There is no contradiction here.

A manufacturer can’t change the UEID of a device once it is made, but it can switch to a new type of UEID for new devices it makes in the future.
A manufacture can change a UEID value. Writing text in a document doesn’t enforce the behavior described in the text.
But this wasn’t my point above. There are valid use cases for changing the identity of an entity from the manufacturers perspective. However, changing a device identity from the entity’s perspective is an indication that an unauthorized change was made to an identifier.

IMO, given the EAT authors were not intending to describe Endorsement / RVP perspectives or requirements, it makes sense to revisit the text that describes claims from a manufacturers perspective.

I filed an issue <https://github.com/ietf-rats-wg/eat/issues/170> to clarify this.




It might make sense for EAT draft to clarify that "the claims definitions focus on an encoding. Their use in conceptual messages may introduce additional semantics."
Including a caveat like this would make the scope of the EAT draft clearer and possibly easier to make progress toward RFC.

BTW: I noticed the definition of type 3 UEID refers to "SVN" but doesn't (apparently?) define it.

SVN is defined by 3GPP. It is part of the IMEI encoding thing like the Luhn check. While you can’t easily get the 3GPP document referenced, you can see it here https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity.

LL






Thx,
Ned


On 2/19/22, 6:15 PM, "Laurence Lundblade" <[e-mail]<mailto:[e-mail]>> wrote:

   Branching the thread away from early allocation...

   I’d like to understand the motivation and principles behind restricting claims to either evidence or results.

   Maybe you can describe some principles that govern when a claim can be in evidence and when it can be in results?

   What about claims like GPS location or UEID that originate in the Attester and often need to end up at the RP? How would those be handled?


   This seems to be really about allowed Verifier behavior. It seems that if certain types of claims can only be in evidence and other only in results, then you are starting to narrow Verifier behavior. A change to RATS architecture?

   Is there anything wrong with a pure passthrough Verifier. One that only verifies the signature? I can’t think of anything wrong with that and I think it is allowed by the descriptions in RATS architecture.

   Maybe some examples of claims that are evidence-only and results-only?

   LL



On Feb 18, 2022, at 6:00 AM, Henk Birkholz <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ned,

I'd agree with the notion that "the same claim in different conceptual messages" requires separate definitions for each conceptual messages. Alternatively, Claims could be explicitly restricted to one type of conceptual messages. This is the reason why I am so cautious about early allocation recently, as I afraid their definition has to change in the future in order to address the issue.

In essence, the fashion the Claim's semantic scope is specified today has to change, I think.

And even if that would be cleared, I am missing a clear way how to express which type of conceptual message an EAT is supposed to represent.
   ...