Re: [Suit] Reliably getting TEE properties

[Dave Thaler <[e-mail]>]

Adding SUIT WG and quoting Russ's related email on the SUIT list here:



> -----Original Message-----

> From: Suit <[e-mail]<mailto:[e-mail]>> On Behalf Of Russ Housley

> Sent: Friday, March 25, 2022 12:05 PM

> To: suit <[e-mail]<mailto:[e-mail]>>

> Subject: [Suit] SUIT-related Claims

>

> When we ran out of time at the end of the IETF 113 session, four options for
> handling SUIT-related claims were outlined.  The way forward may have an impact
> on RATS and TEEP as well as SUIT, so we should resolve this issue as promptly as
> possible.

>

> * Dave Thaler: There are four possible ways to use SUIT reports:

>            * (AS): Use SUIT report AS an evidence format instead of eat

>            * (IN): Use SUIT report encapsulated IN an eat (what is on Brendan's slide)

>            * (TO): Use SUIT report to translate claims TO an eat (e.g., what Brendan
> mentioned might do to translate info to attestation result fields)

>            * (WITH): Use SUIT report separate from (i.e., WITH) attestation, e.g., send in a message to a relying party where the message has both evidence and the suit report in separate parts of the message

> * Dave Thaler: Today in TEEP there is no requirement that a TEEP Agent must generate SUIT reports at boot time, only at Update time.  Should there be?  Requiring #1 or #2 would introduce such a requirement.

> * Dave Thaler: Should we add SUIT reports to the QueryResponse message in TEEP to allow #4?

>

> Please continue this discussion on the mailing list.



Original post to teep is below.



-----Original Message-----
From: TEEP <[e-mail]> On Behalf Of Dave Thaler
Sent: Thursday, March 24, 2022 7:26 AM
To: [e-mail]
Subject: [Teep] Reliably getting TEE properties



I just filed issue https://github.com/ietf-teep/teep-protocol/issues/189

based on thinking about the discussion Brendan and I were having at the tail end of the SUIT WG meeting today.



Currently evidence in the QueryResponse is an optional field, and the QueryRequest can specify the attestation bit to request it.  Since the evidence is not mandatory, the QueryResponse today has no reliable way to learn the device identifying information and TEE identifying information (to use the terms in the architecture draft), which seem critical to the task of being able to determine which Trusted Components to install in the TEE.



Options:

1. Make evidence mandatory in the QueryResponse and remove the attestation bit from data-items-requested
2. Make attestation mandatory but allow it to be either passed inside the TEEP protocol or in a transport protocol (e.g., HTTPS terminating inside the TEE as in model C of figure 5 in the architecture draft). The attestation bit shouldn't be needed in data-items-requested here either since an implementation could know whether the transport included it inside the TEE or not.

3. Make use of SUIT Reports in the QueryResponse mandatory and put the system information there. This means that a TAM would be able to access them without relying on a Verifier to put relevant claims in Attestation Results so could ease interop with more Verifiers.   The only downside I see is that today it is not a

requirement that SUIT Reports be generated at "boot" time (meaning start time for whatever components are relevant) on a TEEP device, and this option would make that a requirement.

4. Some hybrid that allows more than one of the above in implementations but only uses one in any particular message exchange.



I have to admit that I do see advantages in option 3 as noted above, and so I filed
https://github.com/ietf-teep/teep-protocol/pull/187
with what that might look like if we go that route though I temporarily made suit reports optional so it's technically option 4, but if we go with option 3, I will update to make them mandatory.



Looking for feedback from the WG and especially from other implementers.



Dave