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

Ira McDonald <blueroofmusic@gmail.com> Wed, 17 June 2020 12:44 UTC

Return-Path: <blueroofmusic@gmail.com>
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 493D33A077A for <rats@ietfa.amsl.com>; Wed, 17 Jun 2020 05:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GqV0EAiRi_lK for <rats@ietfa.amsl.com>; Wed, 17 Jun 2020 05:44:20 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592F43A0771 for <rats@ietf.org>; Wed, 17 Jun 2020 05:44:20 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id g129so1287494vsc.4 for <rats@ietf.org>; Wed, 17 Jun 2020 05:44:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dosU+zAoKmB42Qb4LYk7QX9PnVFnYDjt5ON365Cdb4A=; b=ud7WB08uUbNu5WeIw+ex1DoS7ahR6p0RBzzoXu8NWtU7NTrXV43h5B72BzSQyek7VQ MKSEhNfdmXlSIrwgwEnwNQjz3JW1JZj5hnZ+CxVb42rr7sMqS1drLr65P4wnkISL0v3B nrQSyFjPcAy+IMLwZsBLxAkoaUle4zySuYAA1QtyX7vPEcVGULvdtsOwQCusfXkUhQYE 21ZT7/kpm2pkWBcwPOaySbT1uplM5ggsC55BQAqB8DVwyJw/zQu7DI3LvgLRAgtd/z0D gSHTexzJ6tdjX7GIqqGlCYlaIPETtwliu87haj0LGK7R8FiykweIQpqOKsIWsTpBsIIx rzQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dosU+zAoKmB42Qb4LYk7QX9PnVFnYDjt5ON365Cdb4A=; b=Cqjf5oy2ash8ATK70ezyR/E3c4n51ejEJlKnDEo7S2ZqJLj2dQzQFe1q5iMPsFUych inc19skXLvZbKI6sCdoUvRbEhYZ3jAMmRupsE0SYkdMaWKMhvEDhiJcl3VBAT3BfRHEn 3kL65XZyrZZ3obdctYnsOecQChMylM2uo5/l1hyRZqYo6K8QXraTk6gBJEBzqImjKL21 HwBcNOnUeRnmi4JZcdlACyz1X4OOTZerY/CiqgHPDOuc/18DWUD17Nfn5p9bFEeEG8zS f8DzWAVRR9nTnA/Oht/Fm6wAe5jsV+qrkkZfvuBjQ7efcT3konCC3if8DAgCOFRpllsD gHKA==
X-Gm-Message-State: AOAM53341emlgTC+zuRzlIDtC5ojEie4EFjo9rNqMCge08f13D7EVnV5 E+BvCGOI1E8YZ7c4YST4NPKgfYGgo/rypoyJSVY=
X-Google-Smtp-Source: ABdhPJwYp4L0HiK01qJuxpfHSvCgekJwAb24IFFVynBiKCveNtL8ZqCXJSRCZF2xVfyvyQ3jY3Oz0BjyCxruTw1/Q5k=
X-Received: by 2002:a67:30d1:: with SMTP id w200mr5247089vsw.40.1592397859230; Wed, 17 Jun 2020 05:44:19 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <AM0PR08MB3716C8E22B305611D15B807AFA9A0@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Wed, 17 Jun 2020 08:44:06 -0400
Message-ID: <CAN40gSttSBxEt_0Lf1Ber4u6ZX4Lk5A9u3cDJ2v66cp00FshpA@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Ira McDonald <blueroofmusic@gmail.com>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Michael Richardson <mcr+ietf@sandelman.ca>, "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>, "rats@ietf.org" <rats@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bda16105a847041c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ay-7yb-JohayEBCr7Wg_41QKu7E>
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:44:23 -0000

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