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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Jun 2020 10:25:36 +0000

Hi RATS architecture authors,

Could the authors of the use case explain the watchdog use case a bit more?

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?
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)?

Ciao
Hannes

From: RATS <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Tuesday, June 9, 2020 9:31 PM
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Use cases in draft-ietf-rats-architecture-04

Hi Ian,

can you provide a bit more details about what your domain is?

Ciao
Hannes

From: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 9, 2020 9:27 PM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Use cases in draft-ietf-rats-architecture-04

Just to add to that, the watchdog case is relevant in our domain

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Michael Richardson
Sent: Tuesday, June 09, 2020 22:00
To: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Use cases in draft-ietf-rats-architecture-04

Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
    > Regarding the hardware watchdog I just feel it is a made-up use
    > case. Is this something people actually want to use in practice?
    > Today's use of hardware watchdogs aim to deal with non-security use
    > cases (mostly dealing with crashing software).

We've heard from Enterprise people that this is important.
It's not a constrained case.

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, 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.
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.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 16 Jun 2020 14:04:12 +0000

Thanks for the feedback.  One reference we can add is
https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p62_Part1_Architecture_7july2020.pdf
section 43 (especially 43.3).

Dave

From: RATS <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Tuesday, June 16, 2020 3:26 AM
To: Hannes Tschofenig <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: [Rats] watchdog use case ... RE: Use cases in draft-ietf-rats-architecture-04

Ciao
Hannes

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Tuesday, June 9, 2020 9:31 PM
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Use cases in draft-ietf-rats-architecture-04

Hi Ian,

Ciao
Hannes

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jun 2020 16:19:40 -0400

> Could the authors of the use case explain the watchdog use case a bit

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 17 Jun 2020 12:17:00 +0000

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 <[email-masked]>
Sent: Tuesday, June 16, 2020 10:20 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: watchdog use case ... RE: [Rats] Use cases in draft-ietf-rats-architecture-04

    > Could the authors of the use case explain the watchdog use case a bit

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.

The Attester (secure enclave/TPM/etc.) collects Evidence as to health and sends this to a remote Verifier.

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.

    > attestation server (for example, pretending that network connectivity

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 <[email-masked]>, 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.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 17 Jun 2020 14:21:35 +0200

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:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 17 Jun 2020 12:33:51 +0000

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 <[email-masked]>
Sent: Wednesday, June 17, 2020 2:22 PM
To: Hannes Tschofenig <[email-masked]>; Michael Richardson <[email-masked]>
Cc: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
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:
> 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.
> "
>
> -= 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.
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 17 Jun 2020 08:44:06 -0400

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: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Wed, Jun 17, 2020 at 8:34 AM Hannes Tschofenig <[email-masked]>
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.
>
> 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
>
> > 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.
> > "
> >
> > 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.
> >
> >      > Could the authors of the use case explain the watchdog use case a
> bit
> >      > more?
> >
> > Sure.
> > 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.
> >
> > The arrangement is that of a deadman's switch: if the malware were to
> prevent the communication, then the watch dog would go off.
> >
> > --
> > -= 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.
> >
> 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.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 17 Jun 2020 14:47:01 +0200

Understood. Thx!

@list: If you can find the time, please check the use cases in the 
current architecture I-D via the following link and tell us, if one of 
them is confusing to you (positive feedback is of course also welcome!).

The use cases can be found in section 3 of the latest draft:

> https://tools.ietf.org/html/draft-ietf-rats-architecture-04#section-3

Viele Grüße,

Henk