Re: [Rats] About current RATS drafts

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Fri, 01 November 2019 15:38 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 1A4B21201EA for <rats@ietfa.amsl.com>; Fri, 1 Nov 2019 08:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 xCwljggYmkrt for <rats@ietfa.amsl.com>; Fri, 1 Nov 2019 08:38:20 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 143A3120232 for <rats@ietf.org>; Fri, 1 Nov 2019 08:38:19 -0700 (PDT)
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 xA1FcGmc018726 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Fri, 1 Nov 2019 16:38:17 +0100
Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Fri, 1 Nov 2019 16:38:11 +0100
To: Laurence Lundblade <lgl@island-resort.com>
CC: H Y <yuuhei.hayashi@gmail.com>, <rats@ietf.org>
References: <CAA8pjUMnQ7defSFS8Wz6uw5V1ahiGZMUdSrgmwM6Bh25WN8Ohw@mail.gmail.com> <26A6D463-2635-456F-B0F9-78075B07FDC4@island-resort.com> <0a8eb26e-427d-2edb-e4b4-b0bf17b4075a@sit.fraunhofer.de> <71C1CBBD-74B8-4651-A146-BC4ACD5336AF@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <1fe80492-c242-ab64-cebc-b962e6046ac0@sit.fraunhofer.de>
Date: Fri, 1 Nov 2019 16:38:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <71C1CBBD-74B8-4651-A146-BC4ACD5336AF@island-resort.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.112.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/OiMLZBQiFmE7OZ1_P9gww1Aymak>
Subject: Re: [Rats] About current RATS drafts
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: Fri, 01 Nov 2019 15:38:23 -0000

Hi Laurence,

I'll map that to the terminology that is still consistent between the 
initial architecture I-D and Dave's condensed architecture I-D. Also a 
question at the end.

> The input to the verifier may be software measurements (TPM or EAT format).

That is the Attestation Evidence (that was the only thing I meant when 
talking about the "two primary focuses".

> The output of the verifier might be a Boolean that the measurements were correct.

That is (the most simple, but most certainly viable) the Attestation Result.

> If the verifier knows that the device will never send an attestation is the boot and debug state are not locked down, then the verifier can add those claims.

I do not fully follow you here, I am afraid. Which Claims can be added 
by the Verifer to what at which time? :) I assume you mean that the 
Attestation Result can include implicit assertions based on the 
attestation Provenance - expressed as Claims. I am not really sure, what 
type of claims you are implying, though.


Viele Grüße,

Henk


On 01.11.19 16:24, Laurence Lundblade wrote:
> Hi Henk,
> 
> good point.
> 
> Yes, EAT has been focused on 1) below. However it seems we might expand 
> EAT to 2) especially considering that 2) is not constrained by the TPM. 
>   I’ve added an issue <https://github.com/ietf-rats-wg/eat/issues/44> to 
> the EAT GitHub to track this possible work.
> 
> Here’s two examples:
> 
>     The input to the verifier may be software measurements (TPM or EAT
>     format). The output of the verifier might be a Boolean that the
>     measurements were correct.
> 
>     Some implicit claims might be made explicit. For example, if the
>     verifier knows that the device will never send an attestation is the
>     boot and debug state are not locked down, then the verifier can
>     add those claims.
> 
> 
> LL
> 
> 
>> On Nov 1, 2019, at 7:57 AM, Henk Birkholz 
>> <henk.birkholz@sit.fraunhofer.de 
>> <mailto:henk.birkholz@sit.fraunhofer.de>> wrote:
>>
>> Hi Laurence,
>>
>> good point. There are basically two primary focuses here, I think:
>>
>> 1.) Evidence that includes Trustworthy Claims about the Attester, and
>> 2.) Evidence that includes Claims about the Trustworthiness of the 
>> Attester.
>>
>> In 1.) you can put trust into the Veracity of Evidence due to the 
>> attestation Provenance, in 2.) you are given the decision basis for 
>> assessing the Trustworthiness/Integrity of the attestation Provenance.
>>
>> Laurence, please correct me if I am wrong, but the current EAT draft 
>> focuses on 1.). Is that correct?
>>
>> Viele Grüße,
>>
>> Henk
>>
>> On 01.11.19 15:25, Laurence Lundblade wrote:
>>> Hello,
>>> A frame up that works for me is to think about 1) the claims, the 
>>> attestation format and its details and 2) the transport / conveyance 
>>> and its details.
>>> In the TPM/TCG world the claims and attestation format is locked down 
>>> by what TPM chips do today. It is a set of registers that hold hash 
>>> values used to measure software.  In the EAT world, which typically 
>>> implements on fully functional CPUs, the claims and attestation 
>>> format is not at all locked down and our work is to define it (the 
>>> eat draft).
>>> A lot of the network and router folks have been putting TPMs into 
>>> their routers and now need a way to get the TPM output off the router 
>>> to the network management center. This world runs off of Yang 
>>> protocols. The main interest there is a very specific Yang-based way 
>>> to move TPM output. This is the yang, tuda and pubsub drafts.
>>> The EAT use cases are more about TEE’s and lining up with 
>>> end-user-application-oriented uses like FIDO and the Android key 
>>> store. They make use of all the existing transports used by 
>>> application protocol (mainly HTTP) so there’s no worry about defining 
>>> transport.
>>> I think a few of us see EAT as the more general and flexible 
>>> attestation format that will eventually replace the TPM format. 
>>> Because EAT can use CBOR and COSE which are carefully designed for 
>>> constrained devices there is some hope that it can go into TPM-like HW.
>>> The architecture draft is trying to tie the two together in a sort of 
>>> unified field theory. Seems possible, but hard to me.
>>> LL
>>>> On Nov 1, 2019, at 5:08 AM, H Y <yuuhei.hayashi@gmail.com 
>>>> <mailto:yuuhei.hayashi@gmail.com> <mailto:yuuhei.hayashi@gmail.com>> 
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I'm Yuhei Hayashi, network security researcher of NTT in Japan. I
>>>> learned about the existence of RATS WG at IETF 105.
>>>>
>>>> I'm interested in the work of RATS WG and I'm trying to understand it.
>>>> So, I'm firstly trying to understand which drafts contain the
>>>> standards listed in the charter.
>>>>
>>>> I will attach the result of organizing it from my own point of view.
>>>> I'm glad if you confirm that my understanding is correct, if possible.
>>>>
>>>> Thanks,
>>>> Yuhei
>>>> -- 
>>>> ----------------------------------
>>>> Yuuhei HAYASHI
>>>> yuuhei.hayashi@gmail.com <mailto:yuuhei.hayashi@gmail.com> 
>>>> <mailto:yuuhei.hayashi@gmail.com>
>>>> ----------------------------------
>>>> <RATS_drafts.pdf>_______________________________________________
>>>> RATS mailing list
>>>> RATS@ietf.org <mailto:RATS@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/rats
>>> _______________________________________________
>>> RATS mailing list
>>> RATS@ietf.org <mailto:RATS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>