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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 17 June 2020 12:47 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E73A07A2 for <rats@ietfa.amsl.com>; Wed, 17 Jun 2020 05:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEmK8p8WXIYT for <rats@ietfa.amsl.com>; Wed, 17 Jun 2020 05:47:24 -0700 (PDT)
Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDCA3A079C for <rats@ietf.org>; Wed, 17 Jun 2020 05:47:22 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EaBgAdEOpe/xmnZsBmHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUoCgXmBHoEzCoQakGAlmhSBXwkLAQEBAQEBAQEBBgEBGAs?= =?us-ascii?q?KAgQBAQKBToJ1AoIcASQ4EwIQAQEGAQEBAQEGBAIChhcGJwxCFgGCfH4BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBFgJDVRIBAR0BAQEBAgEBASEPAQU2AgkFBwQJAhE?= =?us-ascii?q?BAwEBAQICJgICJyACBggGAQwBBQIBAYMiAYJcIAQLmm6bBHaBMoVRg1iBOga?= =?us-ascii?q?BDioBizyBDw8PgUw/JmsnDAOCWj6CXAEBAgGBHgkBEgEHAQFEgmiCYASOdYM?= =?us-ascii?q?soG4xWigHgViBBYEGBAuHKosUhUAFCh2CcDWIZYRtBo1rkR2BY4gqlCYCBAI?= =?us-ascii?q?JAhWBaoEJcE0kT4JpUBcCDVWJM4QiFxRuAQKHXYVEcgI1AgYBBwEBAwl8jHe?= =?us-ascii?q?BbAGBEAEB?=
X-IPAS-Result: =?us-ascii?q?A2EaBgAdEOpe/xmnZsBmHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UoCgXmBHoEzCoQakGAlmhSBXwkLAQEBAQEBAQEBBgEBGAsKAgQBAQKBToJ1A?= =?us-ascii?q?oIcASQ4EwIQAQEGAQEBAQEGBAIChhcGJwxCFgGCfH4BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBFgJDVRIBAR0BAQEBAgEBASEPAQU2AgkFBwQJAhEBAwEBAQICJgICJ?= =?us-ascii?q?yACBggGAQwBBQIBAYMiAYJcIAQLmm6bBHaBMoVRg1iBOgaBDioBizyBDw8Pg?= =?us-ascii?q?Uw/JmsnDAOCWj6CXAEBAgGBHgkBEgEHAQFEgmiCYASOdYMsoG4xWigHgViBB?= =?us-ascii?q?YEGBAuHKosUhUAFCh2CcDWIZYRtBo1rkR2BY4gqlCYCBAIJAhWBaoEJcE0kT?= =?us-ascii?q?4JpUBcCDVWJM4QiFxRuAQKHXYVEcgI1AgYBBwEBAwl8jHeBbAGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.73,522,1583190000"; d="scan'208";a="22512284"
Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 14:47:20 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqBwBtD+pe/1lIDI1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUoCgXkvbwNUMCwKhBqQYCWaFIFoCwEDAQEBAQEGAQEYCwo?= =?us-ascii?q?CBAEBgVCCdQKCGgIkOBMCEAEBBQEBAQIBBgRthS4GJwxCFgGFGQEBAQECAQE?= =?us-ascii?q?BIQ8BBTYCCQUHBAkCEQEDAQEBAgImAgInIAIGCAYBDAEFAgEBgyIBglwkC5p?= =?us-ascii?q?smwR2gTKFUYNYgToGgQ4qAYs8gQ8PD4FMPyZrJwwDglo+glwBAQIBgR4JARI?= =?us-ascii?q?BBwEBRIJogmAEjnWDLKBuMVooB4FYgQWBBgQLhyqLFIVABQodgnA1iGWEbQa?= =?us-ascii?q?Na5EdgWOIKpQmAgQCCQIVgWoiZnBNJE+CaVAXAg1ViTOEIhcUbgECh12FREE?= =?us-ascii?q?xAjUCBgEHAQEDCXyMd4FsAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.73,522,1583190000"; d="scan'208";a="84344065"
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 14:47:14 +0200
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 05HCl74f017428 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 17 Jun 2020 14:47:07 +0200
Received: from [192.168.16.50] (79.234.115.101) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 17 Jun 2020 14:47:03 +0200
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" <rats@ietf.org>
References: <AM0PR08MB3716A2C59320D3FB8D403FADFA9D0@AM0PR08MB3716.eurprd08.prod.outlook.com> <12088.1592338780@localhost> <AM0PR08MB3716F8C518E0CDF43FA23D40FA9A0@AM0PR08MB3716.eurprd08.prod.outlook.com> <53a1c6c3-5e85-cb04-b10b-e0d8d5b5ded5@sit.fraunhofer.de> <AM0PR08MB3716C8E22B305611D15B807AFA9A0@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <8ce9aea4-0e0c-6358-920a-4abfe596bfd0@sit.fraunhofer.de>
Date: Wed, 17 Jun 2020 14:47:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <AM0PR08MB3716C8E22B305611D15B807AFA9A0@AM0PR08MB3716.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.115.101]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/LMqKwwnrKO12g_IRGgDC9yFRF6I>
Subject: Re: [Rats] watchdog use case ... RE: Use cases in draft-ietf-rats-architecture-04
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 12:47:27 -0000

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

On 17.06.20 14:33, Hannes Tschofenig 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>om>; Michael Richardson <mcr+ietf@sandelman.ca>
> Cc: Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com>om>; 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>om>;
>> 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>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.
>