Re: [Rats] Two types of secure attestation

[Laurence Lundblade <[e-mail]>]

> On Dec 3, 2019, at 12:14 PM, Smith, Ned <[e-mail]> wrote:
>> Verified Boot:
>> ·         Attesting Env (aka Root of Trust) is the RTV.
>> ·         Attested Env executes: --- Component(A) and becomes Attesting Env for --- Component(B) etc… 
>> o    For each stage of the boot process the Attesting Env Measures Attested Env; Attesting Env performs the Verifier Role and Relying Party Roles (as described above for Measured Boot). These are local Verfiers / Relying Parties. 
>  
> Conceptually and technically, I understand this frame up and its generality.
>  
> However, I think the spirit of work in RATS is that the verifier and relying party are not local. The spirit of the definition of relying party is that is separate from the device OEM, for example a bank or an enterprise, that wants to know about device.
> [nms] Agree that the spirit of RATS is that Verifier is remote e.g. “Remote ATtestation procedureS”. However, the architecture should allow for (and not artificially constrain) RATS Roles to be only remote since there are common scenarios that aren’t remote.

No artificial constraints seems OK as long as it doesn’t involve any discussion time in the WG. We already have quite a lot to figure out and shouldn’t burn time on it.  My read is that is well outside the charter. 



> ...
>  
> Since this is IETF, we should make the IP-based network protocols our focus.
> [nms] And interoperable claims structures.

Yes, interoperable claims carried over IP-based networks. 


>   
> Here’s how I’d make some sense of the use cases for these in RATS
>> Verified Boot only
>>  
>> The OEM of the device controls the SW on it. The end user does not. The OEM provisions attestation key material that is only accessible when Verified Boot succeeds. This is classic EAT.
>> [nms] The Attester claims that a particular boot sequence occurred, possibly without explicitly identifying which software was used? It is up to the claim definition to define what it means to report the ending state of a verified boot. This claim is an attestation in every sense of the word.
>>  
>> Measure Boot only
>> The end user can install whatever SW they want. The OEM doesn’t control it. A remote Boot Measurement is sent as an attestation to the remote Verifier and on to the remote Relying Party. That Relying Party decides if they trust the device by comparing to known-good-values.
>> [nms] +1
>>  
>> Verified Boot + Measured Boot
>> The OEM controls SW on the device. The end user does not. Attestation can be performed either EAT style or Measured Boot style or both at the same time. If Measured Boot style, then a TPM is probably needed and adds to the BoM cost. If EAT style, the extra BoM cost is in the key set up and a little SW and HW to prevent the keys use when Verified Boot fails. If both, then both BoM cost additions.
>> [nms] DICE is probably a good example of hybrid of verified + measured boot. I don’t think it makes sense to stereotype RATS claims in terms of a particular RoT. Systems with TPM can also implement all of the above forms.
>  
> I think we want to support all three in RATS.
>                [nms] Agree, but it may not be in the form of a single claim. It might make sense to use multiple claims. Possibly there should be profiles for how a set of claims might be needed to support one of the above three boot options?

I’m not even sure there’s agreement that it should be in the same signed attestation messages. So far that YANG module gives the format for signing TPM output and that’s all it can sign. The EAT draft says how to sign other forms of attestation and we’re not so far defining claims where it carries TPM or TPM-like output.

LL