Subject: Re: [Rats] Attestation Results for Connectivity (was RE: RATS Digest, Vol 35, Issue 24)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 27 Apr 2021 12:13:10 +0000

Hi Ian,

From: RATS <[email-masked]> On Behalf Of Oliver, Ian (Nokia -
FI/Espoo)
Sent: Tuesday, April 27, 2021 2:21 AM
To: [email-masked]
Subject: Re: [Rats] RATS Digest, Vol 35, Issue 24

Hi,

very quick comments from me and also aid my (mis)understanding

[DT7]: I'd argue that each Attesting Environment (e.g., each OS or firmware
vendor) might similarly support a different set of claims so this is not
unique to hardware chips.
[EV7]: We can change 'hardware chip' to 'Attesting Environment'.

Agree with this as hardware chip implies, eg: TPM, whereas "attesting
environment" allows for a much broader implementation, eg: container etc.

Works for me.

[DT9]: Does this mean that the Verifier can authenticate both the hardware
and the firmware? 
[EV9]: In draft-voit-rats-trustworthy-path-routing, we broke out hardware
and firmware.  However I was unable to find a real case where a customer
might be good with the hardware being ok, but they were not ok with the
firmware being not ok.   So from the perspective of the Relying Party +
Verifier B, if Verifier A finds any issue here, then flag it.   In general,
it is useful to collapse failure states where the Relying Party + Verifier
will take the same action no matter what.

>From most practical perspectives F/W==H/W as the latter comes with implicit
trust

Agree.  This is why (from the perspective of the Relying Party) it is safe
to collapse them when we are simply making an affirming or detracting claim.

 

[DT12]: executables != files. Some executables can be dynamically downloaded
and installed without ever being stored as files. (Javascript code running
in a browser is one example, but there are many more, including ones running
natively, not in an interpreter) 
[EV12] Good catch.  Will change 'file' to 'executable'.

Is there a reason for restricting this just to executable items?

Not really.  How about "code, script, and/or files"?

Thanks for your thoughts,
Eric 

t.

Ian

  _____  

From: RATS <[email-masked] <mailto:[email-masked]> > on behalf
of [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> >
Sent: 27 April 2021 02:48
To: [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >
Subject: RATS Digest, Vol 35, Issue 24 

Send RATS mailing list submissions to
        [email-masked] <mailto:[email-masked]> 

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/rats
or, via email, send a message with subject or body 'help' to
        [email-masked] <mailto:[email-masked]> 

You can reach the person managing the list at
        [email-masked] <mailto:[email-masked]> 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of RATS digest..."

---

From: Dave Thaler <[email-masked]>
Date: Tue, 27 Apr 2021 13:56:18 +0000

[...]
[DT9]: Does this mean that the Verifier can authenticate both the hardware and the firmware?
[EV9]: In draft-voit-rats-trustworthy-path-routing, we broke out hardware and firmware.  However I was unable to find a real case where a customer might be good with the hardware being ok, but they were not ok with the firmware being not ok.   So from the perspective of the Relying Party + Verifier B, if Verifier A finds any issue here, then flag it.   In general, it is useful to collapse failure states where the Relying Party + Verifier will take the same action no matter what.

>From most practical perspectives F/W==H/W as the latter comes with implicit trust

Agree.  This is why (from the perspective of the Relying Party) it is safe to collapse them when we are simply making an affirming or detracting claim.

Taking that argument, it would imply the same for all layers of the evidence.
E.g., the bootloader, the OS kernel, the application communicating with the Relying Party.
So why would you stop at firmware?

Also a separate point: the TAM in TEEP is an example of a Relying Party that needs to know, if the software/firmware is not in compliance, which component(s) are the ones out of compliance, since it's the remediation server that needs to force an update of said components.

Dave

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 27 Apr 2021 14:32:55 +0000

From: Dave Thaler, April 27, 2021 9:56 AM

[.]

trust

 

Taking that argument, it would imply the same for all layers of the
evidence.

E.g., the bootloader, the OS kernel, the application communicating with the
Relying Party.
So why would you stop at firmware?

<Eric> I think it is up to the Relying Party to determine what elements they
might actually choose to differentiate.  Initially with
draft-voit-rats-trustworthy-path-routing, I had separated hardware from
firmware.  But I simply found nobody who had an Appraisal Policy for
Attestation Results who ever wanted a differentiating level of granularity
as part of the link layer establishment phase.     Per your comment below,
the draft progresses, then we absolutely should explore the right
granularity here.  

Also a separate point: the TAM in TEEP is an example of a Relying Party that
needs to know, if the software/firmware is not in compliance, which
component(s) are the ones out of compliance, since it's the remediation
server that needs to force an update of said components.

<Eric> I am good with whatever breakout the WG is appropriate.   I do think
we should differentiate between admission control actions which are relevant
for the link, and remediation efforts.  The remediation server will likely
need a lot more detail than we would want to continuously send over EAP.

Eric

Dave