Re: [Rats] Use case -> architecture document

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 15 October 2019 16:24 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 0E06A12012D for <rats@ietfa.amsl.com>; Tue, 15 Oct 2019 09:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 vtq4sFuQheuy for <rats@ietfa.amsl.com>; Tue, 15 Oct 2019 09:24:46 -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 B474612010F for <rats@ietf.org>; Tue, 15 Oct 2019 09:24:45 -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 x9FGOdtN028833 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 15 Oct 2019 18:24:40 +0200
Received: from [172.20.2.249] (199.243.96.171) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Tue, 15 Oct 2019 18:24:34 +0200
To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
CC: "rats@ietf.org" <rats@ietf.org>
References: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com> <CAHbuEH7WkqeyUW3sL5bdw5N25B6O7ZEF0Qkx03fE5c42Sd4M5w@mail.gmail.com> <b91baad2-2fc3-a5e4-6898-e2cddcda300d@sit.fraunhofer.de> <20191009145006.r2pjsoo6jxirah64@anna.jacobs.jacobs-university.de> <CAHbuEH6u-6GsJjK8s0eFQPLeSuGjPMgonhyQkmaeA6Q+rp42kA@mail.gmail.com> <9379d880-2b7e-6657-c547-b37bb7a9e466@sit.fraunhofer.de> <CAHbuEH7XfWgPT+=T-Za9Cw-5GRQj0_+WT3L+Kd4aPp6VvU9jAQ@mail.gmail.com> <MWHPR21MB078499E5D4A2A5E697924EC7A3900@MWHPR21MB0784.namprd21.prod.outlook.com> <20191015154500.ruv2ie36hsxfb3qq@anna.jacobs.jacobs-university.de>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <038f111c-0a80-bbc5-dd15-67af3746513f@sit.fraunhofer.de>
Date: Tue, 15 Oct 2019 18:24:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20191015154500.ruv2ie36hsxfb3qq@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [199.243.96.171]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/kB2eJEHNAknH1xQXuwdO8_BfKDA>
Subject: Re: [Rats] Use case -> architecture document
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: Tue, 15 Oct 2019 16:24:48 -0000

Hi Jürgen,

a quick reply on the most simple item (I hope):

> challenge response interaction

The authors decided to split solution references out of the architecture 
and at the moment reference interaction models are maintained here:

> https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/

We are working on the request to move information elements that are not 
Claims but used in the transfer protocols to this I-D, too.

There is also running code as a "proof of concept on freshness & 
veracity" for the nonce-based handshake to enable some hand-on experience:

> https://github.com/fraunhofersit/charra

The next steps are to include more interaction are to include additional 
interaction models for DICE, DAA & TUDA (and corresponding minimal sets 
of elements for network protocols).

Viele Grüße,

Henk

On 15.10.19 17:45, Schönwälder, Jürgen wrote:
> On Mon, Oct 14, 2019 at 11:01:04PM +0000, Dave Thaler wrote:
>>
>> As requested, I have written a document for the WG to consider, that
>> includes my architectural patterns work, plus some content pulled from
>> others' docs.  It's not complete (i.e., some stuff is not covered), but I do
>> hope it's readable by a general audience.
>>
> 
> This document is well readable and the use case examples seem to be
> about right (although it is not entirely clear for all of them how the
> architecture supports them). Dave's document defines fewer terms
> compared to Henk's document and I assume the WG needs to decide what
> the set of terms is that should be defined in the WG's architecture
> document.
> 
> Dave takes a minimalist approach, but then he introduces some terms
> later on in the document (e.g., Endorsement) that may actually belong
> into the terminology section.
> 
> If an Endorsement is a statement, why is it defined under Conceptual
> Messages? I assume messages may carry endorsements.  Perhaps the
> section title "Conceptual Messages" is a bit misleading?  Henk's
> document uses the term 'claim' (which does not really show up in
> Dave's document), as a superclass, i.e., Endorsements and Evidence are
> all forms of Claims (instead of 'Conceptual Messages'). Perhaps Dave's
> 'statements' used informally in the 'Conceptual Messages' section are
> Henk's 'claims' and we need to pick a term and then change the section
> title to 'Types of Claims' or 'Types of Statements' or something like
> that and we likely want to define the concept of a 'Claim' or
> 'Statement'.
> 
> Henk's architecture discusses 'Attestation Principles' that are not in
> Dave's proposal. I guess the WG needs to decide whether to include
> them or not. Are these important for understanding or guiding the RATS
> work?
> 
> I also like to mention that there are research papers where the remote
> attestation process is described more in the form of a challenge
> response interaction, where the verifier sends a specific challenge to
> a device and the device returns a response that is than evaluated by
> the verifier. An example is "compute a hash over certain memory areas
> within a certain time limit" and then the device returns the result
> and the verifier checks whether it is what is expected.  The time
> limit is used to control that an infected device can't reasonably
> forward the challenge to obtain an answer from an unaffected device
> that is then relayed back to the verifier. The question is whether the
> architecture includes models where a stimuli is used to trigger the
> production of a certain Evidence or whether this is left out of the
> architectural picture on purpose. For more details, see for example
> <doi.org/10.1145/2988546> (you will find a preprint if you search).
> 
> /js
> 
>