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

From: Laurence Lundblade <[email-masked]>
Date: Tue, 1 Mar 2022 11:18:14 -0800

Hi Henk, Ned and the rest

> On Feb 24, 2022, at 1:48 PM, Laurence Lundblade <[email-masked]> wrote:
>> 
>> On Feb 24, 2022, at 1:03 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Laurence,
>> 
>> comments in-line.
>> 
>> On 24.02.22 21:43, Laurence Lundblade wrote:
>>> Reviewed all the EAT claims in the light of this discussion and would like to try for this distinction:
>>> _Claim Semantics_
>>> I think we can define semantics precisely for claims in a way that doesn’t vary by context.
>>> A UEID is always the UEID of the target device of the attestation. Same for SUEID, HW OEM ID, HW Model, HW Version, uptime, boot seed. Probably also SW name, version, manifests and evidence (CoWIDS).
>>> I believe we can clearly lock these definitions down in EAT in way that they are invariant by context.
>> 
>> Not sure how you intend to pull that off, but I am most definitely in favor of a simple solution. I'll stay tuned.
> 
> I haven’t done the fine-toothed comb review of all the claims yet for this, but will.

I have completed my review of EAT claims in relation to AE and AR. We can organize the EAT claims into four.

Token meta data
- iat, the creation time
- profile, 
- intended use
- cit, jti, a unique claim identifier

These are claims about the token, not the Attester. They can occur in either AE or AR. They only describe the token they occur in.

Claims about the Attester
- ueid, sueid
- OEM, model, version
- boot and debug state
- location
- SW names, manifests, evidence and SW evaluation results
- certification status
- submods
- (I’m leaving security level out of this discussion)

These claims can appear in either AE or AR and are always about the Attester.

From my review, I believe EAT clearly defines the *semantics* of these claims in a way that is neutral to their use in either AE or AR. There is no significant text that bind them to one or the other. 

There is intentionally no text in EAT that speaks to how secure or trustworthy any of these claims are. This is so they can be used in a wide range of use cases with varying security levels. 

I believe this largely puts to rest Henk’s objection about early allocation of claim keys. The EAT definitions are just of the semantics making them neutral to use context, security level and such.

Nonce
This is a special case. I think we all understand this.

Note that RATS architecture does suggest a nonce can go from the RP through the Verifier to the Attester and back again.

Formats for Keys
This EAT section doesn’t define any claims, just gives encoding recommendations.

I’ve made an EAT PR  <https://github.com/ietf-rats-wg/eat/pull/171/files>that makes sections for the claims as above. It is just a rearrangement with no changes to claim text. I think it helps clarify a lot.

I think this is a really valuable discussion that is making attestation better and more clear!

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 2 Mar 2022 17:41:32 +0000

Here is more thinking behind my "side question" below.

Section 3.24 is the 'swresult' claim, and introduces the term "attestation target".   Within an AR, one or many 'swresult' may be returned, each relating to an "attestation target or the submodule".

The 'swresult' has six values which can specify a sub-identity relating to the "attestation target or the submodule".  

   1 - all  

   2 - firmware

   3 - kernel

   4 - privileged

   5 - system-libs

   6 - partial

An implication of the sub-identity is that the RP policy language must evaluate this value before it can understand the sub-identity against which the claim is applied.  This will require a robust/complex parser if any automated actions are to result. 

Additional complexity will also exist if there is interplay between 'swresult' and the Software Manifests Claim (Section 3.22).   And there could be interplay with the Submodules claim as well (Section 3.25).

Could you describe any interplay intended/allowed between these claims?  Is any structure permittable with in AR?

Eric

From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Friday, February 25, 2022 6:56 PM
To: Laurence Lundblade <[email-masked]>; Henk Birkholz <[email-masked]>
Cc: [email-masked]; Smith, Ned <[email-masked]>
Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))

Hi Laurence,

From: Laurence Lundblade, February 25, 2022 3:55 PM

Trying for some examples. They are written in JSON without the JWT wrapper so they are easy to read.

First attestation evidence with a CoSWID measurement. The CoSWID is B64 wrapped CBOR. What’s important here is that there are measurements in the evidence, not the format or type of the measurements.

  {
       "OEMID" : "iUWt",
       "UEID" : "AZj1Ck/2wFhhyIYNE6Y4",
       "swevidence": “8sf7xls8kd99s8lc87sd…."
  }

Next, here’s attestation results. The representation of the result is in the EAT swresults claim, but they could be ar4si too. What’s important is that there are claims describing results of verification.

  {
       "OEMID" : "iUWt",
       "UEID" : "AZj1Ck/2wFhhyIYNE6Y4",
       "swresults" : [
            [
                "Trustus Verifications",
                "all",
                "fully-verified"
            ]
       ]
   }

<eric>  I hadn’t noticed "Trustus Verifications" in EAT before. This term first appears in EAT v11 Appendix A.6.  I think it is the name of an example Verifier?   If that is the case, shouldn't you have the Verifier making the assertion to span/sign *all* the Attestation Results which it is asserting?  I.e., the signature and identity need to be on the outside of all the Attestation Results asserted. For example, the UEID does not necessarily prove the make and manufacturer of the Attester.  These verifying any such claims should also be signed by the same Verifier as it will affect the treatment below by the RP policy.   (Unless that information has been previously asserted and cached.)  

Side question: can the swresult claim vary in scope of software evaluated?  I.e., can it sometimes be used for one element of code in one context, but the entire system in another?  I thought I saw slides in an earlier IETF that showed individual files could have a "swresult".  In that case it would be necessary to define structures for the domain of software which applied for a particular AR.  (E.g., when "6-partial" is asserted.)

I don't think the two points above are academic as the RP needs to be able to parse the AR received with sufficient assuredness that it can apply the appropriate policy.  Scanning for claim names within a JSON blob will not get you there.

The RP knows that they are getting attestation results because they accessed the Verifier API that only provides attestation results. They know that it’s not attestation evidence because that API doesn’t provide attestation evidence. 

If we wanted to be doubly sure there’s no mix up with conceptual messages, then we could invent a MessageType claim.

    {

       "OEMID" : "iUWt",
       "UEID" : "AZj1Ck/2wFhhyIYNE6Y4",
       "swevidence": “8sf7xls8kd99s8lc87sd….”
       “MessageType” : “Attestation Evidence"
  }

and

    {

       "OEMID" : "iUWt",
       "UEID" : "AZj1Ck/2wFhhyIYNE6Y4",
       "swresults" : [
            [
                "Trustus Verifications",
                "all",
                "fully-verified"
            ]
       ]
       “MessageType” : “Attestation Results"
  }

EAT doesn’t have an a MessageType claim now. It can still be the format for attestation results even if it doesn’t have an explicit indicator of conceptual message.

<eric> A MessageType might be a good idea, whether it is a claim or simply something which indicates it was generated by a Verifier about an Attester.   

Building on that I am a believer in simplicity, and that only a very few new things need be asserted by a Verifier.  (I.e., the Verifier should generate very little new claim/information.  But that it can certainly copy claims originally from an Attester and include them within the signed AR the inputs behind the conclusions which it is actually vouching for.) 

Eric

I hope that shows why there is no contradiction.

To go further, if a Verifier received an evidence EAT with the swresults or ar4si claims, it should kick it out in error.

Similarly, if the RP received an EAT with the swevidence claim, it should kick it out in error, or ignore the claim, or error out because there was no swresults or ar4si claims.

Maybe there are some use cases where it is easy to mix up EATs that are attestation results with ones that are attestation evidence. If so, then we probably would want to define a MessageType claim.

LL

 

On Feb 24, 2022, at 1:58 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]> > wrote:

Hi Laurence,

it is starting to get late on my side of the globe that is close to... a disconcerting event.

So I am gonna focus on just two related items for now:

See - when you say this:

EAT defines a few claims that are oriented to Attestation Results (swresults, DLOAs) and as I said above, I think EAT is a good format to express AR. Others even agree with me.

and you also say this:

EAT doesn’t have anything that indicates conceptual message.

then you are confusing the heck out of me, because that is literally contradicting yourself (I think) and I do not know how to deal with that today anymore :-) No offense, I am just tired (by many things).

Please align your Claims with just one intended conceptual message they should appear in. Or find another cool solution that facilitates that. Or please clearly elaborate how that is not totally confusing to the consuming roles of conceptual messages more, so we can have a targeted discussion.

Viele Grüße,

Henk

On 24.02.22 22:48, Laurence Lundblade wrote:

On Feb 24, 2022, at 1:03 PM, Henk Birkholz <[email-masked] <mailto:[email-masked]> > wrote:

Hi Laurence,

comments in-line.

I haven’t done the fine-toothed comb review of all the claims yet for this, but will.
Would be really helpful if others also did a review of the claims for any possible variance in semantics between results and evidence. :-)

_Claim Trustworthiness_
Each of the above-mentioned claims may be more or less trustworthy depending on how the Attester and Verifier are implemented.
A UEID always identifies the target device, but may be very easy to attack and for some Attesters and not for others. Ease of attack is roughly the same as trustworthiness.
Similarly, a location may be easier to spoof on some device and with some Verifiers than others. Maybe the Android location debug is enabled, maybe the location comes from TrustZone. Maybe the Verifier does a sanity check based on cellular triangulation. But the location claim is still the location of the device, the semantics haven’t changed.
Every claim has varying trust. There is no such thing as a perfectly trustable claim that can never be attacked.
Just because the trust in a claim varies doesn’t mean its semantics are variable. We can still lock down semantics.
I believe EAT should NOT define claim trustworthiness. It should steer very far away from trustworthiness.

I agree with respect to Evidence. The policies for appraisal of Evidence might yield a different picture, though. To build on you example, certain Endorsements for a type of Attester might inform a Verifier via corresponding policy not to take an UEID at face value, as the Attester is known to be spoof-able. That's a policy decision and therefore any statements about that topic must originate from the Verifier and only belong into Attestation Results.

Yes, other RATS documents may define trustworthiness characteristics of claims, claims about trustworthiness and such to go into Attestation Results. Most EAT claim definitions will be neutral about trustworthiness. That doesn’t mean that EAT can’t be used as a format for encoding, securing and conveying Attestation Results. More below.
(Also, the UEID and every other claim is always spoofable in every implementation and for both Evidence and Results. It’s just a matter of degree.)

_EAT Meta Data_
Some claims are EAT meta data and not about the device: profile and intended use. These are fine in either evidence or results as they always refer to the EAT they immediately occur in.

Are these intended to be used to distinguish conceptional messages, too? I am under the impression that the I-D does not say anything about that, but maybe I am reading it wrong.

EAT doesn’t have anything that indicates conceptual message. Seems like you will always know by context and it is not necessary, but maybe we want to add something?

_Nonce_
This is an interesting one. Multiple nonces are allowed in EAT. As and RP, you can always tell which is the nonce you sent because you remember it. You may not know if the nonce went all the way to the device and was signed in Evidence. Maybe some more thinking and text is needed here.

Why should a Relying Party send a nonce to an Attester? Or is the Verifier intended to re-use that nonce for its own challenge-response remote attestation interaction? I assume that "the device" is "the Attester", but I cannot be sure. Also, neither the Background-Check model, nor the Passport model initiate retrieval via the Relying Party directly, but that might be a simplification issue and not a problem.

I admit I haven’t thought that all through. Lots of other people were very interested nonces so I didn’t think I needed to. Note that EAT does allow for multiple nonces. Happy to defer on this one.

Driving a wedge between claim semantics and claim trustworthiness, I don’t see a need to use name spaces or such in EAT to distinguish a claim in evidence from a claim in results.
 - The claim has the same semantics whether they are in evidence or results
 - EAT is silent about their trustworthiness because there is no practical way to characterize it
Almost all EAT claims will not have a definition that is conditional on the context. If an EAT claim does vary by context, there is probably something wrong with its conception or definition.

I wonder why the trustworthiness issue is coming up again and again, while that is contained to Attestation Results and I think we agree that it is not covered by the EAT I-D.

I see EAT as a base format for both Evidence and Results. It has the necessary characteristics to represent Results well. Fewer formats in RATS are is better.
Lots of claims will be defined for EAT outside of the EAT document. I expect many of them to be for Attention Results.

Yet, the differentiation between Claims in different conceptual messages ("conditional on context") remains to be bit of a neglected topic.

Just wrote did some analysis of claims in regards to this and wrote a thoughtful and helpful message about it. I have promised further review. Maybe we should have figured that out six months ago, but that doesn’t mean it is currently neglected.

In the meantime, I start to be under impression that that is the actual, real problem with the Claim definitions between -09 and -11(12).

I really don’t see a big problem here. Maybe some wording adjustments are needed in light of this, but I don’t think there is general problem.  Most EAT claims are just definitions of semantics and always have been.
Maybe after -09 you realized that I intended EAT to used for Attestation Results?

(There are also claims that define attestation results; we can discuss them in another thread).

Now I am confused. All the Claims discussed are not for Attestation Results? I am surely missing something here.

EAT defines a few claims that are oriented to Attestation Results (swresults, DLOAs) and as I said above, I think EAT is a good format to express AR. Others even agree with me.
LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 21 Mar 2022 11:21:11 +0100

Per a conversation with Henk in Vienna I have updated the PR <https://github.com/ietf-rats-wg/eat/pull/171/files> to say that anything in Attestation Results is subject to Verifier processing and Policy. For example, a UEID in Evidence that forwarded (not passed through) in Results is subject to the Verifier processing and Policy. The RP must understand this policy to know how to trust and treat the UEID in Results.

This seems like a very good resolution to me.

Appreciate the discussion.

LL

> On Mar 1, 2022, at 8:18 PM, Laurence Lundblade <[email-masked]> wrote:
> 
>> On Feb 24, 2022, at 1:48 PM, Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
>>>