Re: [Rats] Use case -> architecture document

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 16 October 2019 15:07 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 D068312095E for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 08:07:12 -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 8nmCixGx4uTd for <rats@ietfa.amsl.com>; Wed, 16 Oct 2019 08:07:09 -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 E3F35120935 for <rats@ietf.org>; Wed, 16 Oct 2019 08:07:08 -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 x9GF74Zg009943 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 16 Oct 2019 17:07:05 +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; Wed, 16 Oct 2019 17:06:59 +0200
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>
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> <18413.1571227622@dooku.sandelman.ca> <CAHbuEH6vTuJ-GuYfeEvUXFaFT-DeGv-c9NAAYyDFBFPWWSfbJQ@mail.gmail.com> <13312.1571236317@dooku.sandelman.ca> <CAHbuEH5Uw7AdeQSxg_Ty-AOe7vwtqGXDC_4YZWB8t_FEnwcmUA@mail.gmail.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <2a06c444-0a2a-d421-abe0-38ca4188f4f4@sit.fraunhofer.de>
Date: Wed, 16 Oct 2019 17:06:55 +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: <CAHbuEH5Uw7AdeQSxg_Ty-AOe7vwtqGXDC_4YZWB8t_FEnwcmUA@mail.gmail.com>
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/Odko3nreWFj01U9O9GqcTkoq3Js>
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: Wed, 16 Oct 2019 15:07:20 -0000

Hi Kathleen,
hi list,

there was an interesting follow-up on discussion how RFC4949 data origin 
authentication ("The corroboration that the source of data received is 
as claimed."), attestation provenance & device identity are strongly 
intertwined, but mean different things in the context of RATS (well, 
actually the example this was discussed on was a subset of RATS: the RIV 
use-case).

Another good example coming out of that discussion were the subtle 
difference between the RFC4949 term "fresh" ("Recently generated; not 
replayed from some earlier interaction of the protocol") evidence and 
the "freshness of evidence" (in contrast to "recentness of claim _and_ 
evidence creation"), which also mean quite different things.

Last example I want to provide as food of though from that discussion is 
"proof of possession" vs "proof of availability at a specific point in 
time" This differentiation is a quite important for DICE-based remote 
attestation procedures, where the persistence of an alias key and 
corresponding certificates for attestation can be significantly shorter 
than, e.g. an associated DevID [1]. The point being, the semantics 
around the terms are vital, but unfortunate also easily conflated, if 
not worded with precision in a bigger context.

The conclusion was to be very carefully about not conflating different 
things for the sake of simplicity, I think.

Viele Grüße,

Henk

[1] 
https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf

On 16.10.19 16:35, Kathleen Moriarty wrote:
> origin authentication