Subject: [Rats] Comparing Verifier generated software ARs (was: Same claim in Evidence and Results)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 7 Mar 2022 14:39:00 +0000

At IETF 113, I am hoping to include a slide which compares EAT and ar4si generated AR claims related to software.  Below is my summary view.  Thoughts/comments/corrections anyone?

(Sorry for the HTML format of the table below.  It makes for easier reading.   If you don't use an HTML reader, I have attached a JPG of the same table.)

 

Trustworthiness Claim (AR4SI)

EAT claim

Criteria

‘executables’

‘file-system’

‘swresults’

Attestation target

All runtime software/object loaded into Attester memory

A Verifier specified set of directories within the Attester file system

A Verifier specified set of software and/or multiple sets of software modules (firmware?)

Encodable states

Seven

Five

Six.  Might need to encode more than one (e.g., Firmware & Kernel).

Vendor extensible

Yes

No

Claim consistency

Common claim generalizations across Verifier generated AR:  

(Affirming, Warning, Contraindicated, None)

No generalized claim abstractions across generated AR claims

RP claim interpretation

Claim always references the full attestation target

Claim references either attestation target or submodule(s).  An RP parser must understand context within structured message.

Purpose

Only encodes information likely to be actioned by RP

Can encode both actionable information as well as supplementary information for debug logs

Encodings supported

Transport independent

JSON, CBOR

Thanks,

Eric

From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Wednesday, March 2, 2022 12:42 PM
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Same claim in Evidence and Results (was Re: Second attempt at early allocation of CWT Labels (PR #152))

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: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Mar 2022 17:48:05 -0800

Hi Eric,

This is only a narrow response on encoding for now. I will try to work through more over time.

Transport Independence:
        EAT: yes — there is nothing to restrict EAT to JSON and CBOR
        AR4SI: yes

Information Model:
        EAT: Uses CDDL and some prose
        AR4SI: Uses English prose

Serialization Support:
       EAT: Ready to go with CBOR and JSON, others can be added
       AR4SI: None. Further standards worked need to create an interoperable protocol

I have similar thoughts about the characterization of other things in the table.

I hope we can find synthesis between EAT as AR and AR4SI. Don’t think comparison like this means mutual exclusion. 

On the AR general topic, I want to be sure everyone is aware of this PR <https://github.com/ietf-rats-wg/eat/pull/143/files> for EAT for a super simple overall attestation result. I’ve mentioned it before, but I think it was confused with swresults.

LL

> On Mar 7, 2022, at 6:39 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Eric Voit (evoit)
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 20 Mar 2022 09:03:32 +0100

A few more comments on this.

Attestation Target — swresults should be renamed Measurement Results and generalized to represent results of measurements of anything that is measured. The current objectives could be expanded to mean executables, file system, config… to do with root, privileged, all,.... I am not a fan of separating out the measurement of the executables from the file system for the RP because the RP has to know the system architecture to know what that means.

Encodable states — AR4SI states seems to need interpretation by the RP that depends on knowledge of the target system architecture. For example, the meaning of executables:affirming + filesystem:warning might vary from Linux to Riot to JavaCard. Swresults has an “all” objective which is probably the only one of great use as that is clear and straight forward to the RP.

Claim Consistency — swresults has a generalization of “fail”, “indeterminate”, “full”, “partial”,... so “no” is an incorrect assessment.

Purpose — An RP might run a machine learning risk engine in which case they want all the data they can get.

I’m open to modifications to EAT for this. I’m not sure where all this ends up. Have a few framing slides and hoping for good discussion at 113.

LL

> On Mar 7, 2022, at 3:39 PM, Eric Voit (evoit) <[email-masked]> wrote:
>