Re: [Rats] watchdog use case ... RE: Use cases in draft-ietf-rats-architecture-04

[Hannes Tschofenig <[e-mail]>]

Hi Henk,

It is quite possible that I was the only person who did not understood this use case and the rest of group was puzzled about me not understanding it. Ian was the other person commenting and understood it as well.

Now I get it and I am happy.

Ciao
Hannes

-----Original Message-----
From: Henk Birkholz <[e-mail]>
Sent: Wednesday, June 17, 2020 2:22 PM
To: Hannes Tschofenig <[e-mail]>; Michael Richardson <[e-mail]>
Cc: Oliver, Ian (Nokia - FI/Espoo) <[e-mail]>; [e-mail]
Subject: Re: [Rats] watchdog use case ... RE: Use cases in draft-ietf-rats-architecture-04

Hi Hannes,

the fact remains that the corresponding use case text alone was not enough to get you exited (I am glad that you are now *g*). Are you in a position to maybe provide a proposal how to rephrase the use case description in a way that would have helped you from the very start?

Viele Grüße,

Henk

On 17.06.20 14:17, Hannes Tschofenig wrote:
> Hi Michael,
>
> thanks for the reference to the TCG "Authenticated Countdown Timer" spec. I have not seen that spec before.
>
> It says:
>
> "
> A typical example for the use of an ACT is as a watchdog timer that
> will cause a platform reset when the timer reaches zero (expires). In
> a system using an ACT, a periodic platform action outside the TPM
> indicates that the timeout should be set anew using
> TPM2_ACT_SetTimeout(). The most common reason why timeout is not set
> anew is that the local system is not behaving properly because of some type of corruption (either inadvertent or malicious). The intent of the timer is that, in the absence of a properly authorized timeout extension, the platform would be reset, putting it back into a known state with the expectation that the corruption can be removed.
> "
>
> Thanks for the description of a possible message flow. This makes much more sense to me now.
>
> In fact, we have the building blocks to get this working already when you combine the EAT token (for the attestation), the CWT for authorization (as mentioned in the TPM spec above), and SUIT (for the update of the software that is needed to fix the system). When we look at TEEP then we actually see these building blocks combined to get this use case working via a standardized protocol.
>
> Now I am excited about this and maybe someone in the RATS/TEEP group wants to prototype it.
>
> Ciao
> Hannes
>
> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Tuesday, June 16, 2020 10:20 PM
> To: Hannes Tschofenig <[e-mail]>
> Cc: Oliver, Ian (Nokia - FI/Espoo) <[e-mail]>;
> [e-mail]
> Subject: Re: watchdog use case ... RE: [Rats] Use cases in
> draft-ietf-rats-architecture-04
>
>
> Hannes Tschofenig <[e-mail]> wrote:
>      > Could the authors of the use case explain the watchdog use case a bit
>      > more?
>
> Sure.
> Dave's reference to the TCG "Authenticated Countdown Timer" is rather detailed, but perhaps misses the forest for the trees.
> Perhaps I can be a bit more concise.
> Ian, please let us know if this describes your situation as well.
>
>      > I do not understand how this is supposed to work. How is the device
>      > allowed to reboot when it sends attestation information to a remote
>      > server?
>
> There are usual three parties: Attester, Verifier, Relying Party.
>
> The Attester (secure enclave/TPM/etc.) collects Evidence as to health and sends this to a remote Verifier.
>
> The Verify creates an Attestation Result as normal.
>
> But, in the case, the Relying Party is the Watch Dog timer in the TPM/secure enclave itself.  So the Attestation Results are returned to the PC, and provided to the enclave.
>
> If the watch dog does not receive regular, and fresh, Attestation Results as to the systems' health, then it forces a reboot.
>
>      > If malware prevents the device from rebooting, as the text indicates,
>      > why doesn't that malware also prevent the interaction with the
>      > attestation server (for example, pretending that network connectivity
>      > is down)?
>
> The arrangement is that of a deadman's switch: if the malware were to prevent the communication, then the watch dog would go off.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.