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

Hi Hannes,

This thread was useful.  I also thought (and still think) that the original
watchdog use case was obscure.  I note that no remote system will ever
be able to "force a reboot" in an attesting system infected w/ malware.
Only the Platform Manufacturer who has chose to wire the watchdog
timer to the reset line can achieve that (and it still won't obviously clear
out the malware).

I don't like the inclusion of this "and then a miracle happens" use case
in the already too tricky RATS Architecture.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted
Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: blueroofmusic@gmail.com
<blueroofmusic@gmail.com>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Wed, Jun 17, 2020 at 8:34 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com>
wrote:

> 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 <henk.birkholz@sit.fraunhofer.de>
> Sent: Wednesday, June 17, 2020 2:22 PM
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Michael Richardson <
> mcr+ietf@sandelman.ca>
> Cc: Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com>;
> rats@ietf.org
> 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 <mcr+ietf@sandelman.ca>
> > Sent: Tuesday, June 16, 2020 10:20 PM
> > To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> > Cc: Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com>;
> > rats@ietf.org
> > Subject: Re: watchdog use case ... RE: [Rats] Use cases in
> > draft-ietf-rats-architecture-04
> >
> >
> > Hannes Tschofenig <Hannes.Tschofenig@arm.com> 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 <mcr+IETF@sandelman.ca>, 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
> > RATS@ietf.org
> > 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.
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>