Re: [Rats] Fwd: New Version Notification for draft-birkholz-rats-reference-interaction-model-03.txt

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 08 July 2020 14:14 UTC

Return-Path: <anders.rundgren.net@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 B620F3A0C6F for <rats@ietfa.amsl.com>; Wed, 8 Jul 2020 07:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 NkYCiiB1wN4u for <rats@ietfa.amsl.com>; Wed, 8 Jul 2020 07:14:09 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 42BCC3A0C19 for <rats@ietf.org>; Wed, 8 Jul 2020 07:13:53 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id w3so3343236wmi.4 for <rats@ietf.org>; Wed, 08 Jul 2020 07:13:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CAO5MW/U9j7XJKRt1HluEoRsUSycxaQEjFm4nSNrFqA=; b=h1tmUR1Jrrawwyr76mH98wp+kHk/rz2yDLElex8dSSVxgbvyr45OIdE8M/ii1WCEf2 s+T2AOFUjEYsvz4PG4pgxKgmAui/comNPR8MxFpeYZScJQle9C6rh4TOCzjSEnHW6n6/ UplYqvQ0tWlbnEWozR3c/2Eeg/q3Svg6QagFKXwXGTJxKpLpPu1i6cZvUq4oF5OrXF+m rI9B6KvArahF90D4HLWid260AmYZdayuOUwP+c5VGDovyBDLf62MknQj/FkjvyrUmXAx 7Xg5o/YmCdI1cMqfxliElXzs/og70OGlaYblZckMo3JawdVaDw8GXMfO3eEdVPLf+C58 e14A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CAO5MW/U9j7XJKRt1HluEoRsUSycxaQEjFm4nSNrFqA=; b=eho9kdJBGMKKbyPprQUCGwT3VepSw7WknAKsR/dZ7EnOF0K7KC9P9DVbmK8LAZ4unK +k8xipdFQOriWn0CqunxiUIj9R9zfD/PCAK4DQN2Wkr3wk/OpcbMBEoj4iODzu2i4//i jinepQgkzvQXmFPgCKSPyv4Ykpwk50qB0uoRp+6n3fZadmMAVs8sPK/UdJYWJXkFufxa /ennaPdeBd8AaVhl4/SjApVLr3xQNzSgm95at6G9yUJAG/gk/hsoxTx9auFvwXJhCl51 l722wUilviwOzSVLIyEVt02Eww8xjQ3LmTLV8SztaA6VS7Jko7pijYhbFns38DdHJz// mzrQ==
X-Gm-Message-State: AOAM531HojWuo8RQeno9OQj/WG2HO4jEorv6ewIuUGERc38EJ1VVZ6LT FHXqLGajHbj4QDmxhEEHg9Y=
X-Google-Smtp-Source: ABdhPJw/bX6ITIHDJAFyUQrXisvdOT4QbCZtQ8q2GIdwOOcSvLdDAEmJRKlD2J3pq0rLkTqYW/VvgQ==
X-Received: by 2002:a1c:1f54:: with SMTP id f81mr9495046wmf.4.1594217632259; Wed, 08 Jul 2020 07:13:52 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id a22sm6230405wmj.9.2020.07.08.07.13.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jul 2020 07:13:51 -0700 (PDT)
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>
Cc: Guy Fedorkow <gfedorkow@juniper.net>, Thomas Fossati <Thomas.Fossati@arm.com>
References: <159419048015.6220.17040386001147920084@ietfa.amsl.com> <56890b74-3b90-fe6f-720c-32f407dc312b@sit.fraunhofer.de> <041629bc-b2a9-fa01-9a0e-cacd783afc53@gmail.com> <c4ce79ca-5338-0aaf-be1d-3f49ec5f2899@sit.fraunhofer.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <0be11477-3456-49e1-15ae-a92b37b0389c@gmail.com>
Date: Wed, 8 Jul 2020 16:13:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <c4ce79ca-5338-0aaf-be1d-3f49ec5f2899@sit.fraunhofer.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/BmJWq6FmGlFey3j6vF6mbpAGeeI>
Subject: Re: [Rats] Fwd: New Version Notification for draft-birkholz-rats-reference-interaction-model-03.txt
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, 08 Jul 2020 14:14:16 -0000

On 2020-07-08 14:24, Henk Birkholz wrote:
> Hi Anders,

Hi Henk,

> 
> thanks for your reach-out :) As far as I know, session-based creation of
> evidence is map-able to every kind of interaction model. I'll quickly
> illustrate how I think that typically works. Please step in, if I am
> erring here.
> 
> Session-based remote attestation "bundles" a certain amount of
> "evidence-generating primitive operations" of an Attesting Environment
> in a way that corresponding results are packaged in relative large set
> of Claims collected over time - in one piece of evidence.

It is possible that you can characterize session-based remote attestations
like that but at least in my case the goal is different because it is only
about creating a secure session with an entity that has an attested quality.
The protected API is subsequently used for executing arbitrary secure
operations that for some reasons must be performed in a specific sequence.

This is pretty much a carbon copy of smart card provisioning where a session
is created based on an embedded key which indirectly provides attestation
(the card must be known).  The difference is that session-based remote
attestation does not presume a explicit knowledge of each trusted container.
The rollback feature is another enhancement.

It's not a big deal w.r.t. to the I-D, but it might be worth knowing anyway :)

Regards,
Anders

> 
> Some solutions call these bundles audit sessions. If these bundles
> constitute evidence that can represent past states, some solutions call
> the resulting evidence secure audit logs.
> 
> Looking at the referenced write-up [1], the audit approach seems to be
> combined with a roll-back feature. That is an implementation feature for
> remediation that is typically not directly in-scope of RATS. But - RATS
> of course play a vital role in assessing the need for & and the result
> of remediation procedures, as well as selecting appropriate remediation
> procedures in the first place (see TEEP).
> 
> In summary, my early feedback is that the illustrated Protected API can
> be mapped to all three interaction model - it was probably designed with
> CHARRA in mind. Maybe it is useful to note here that a subscription
> session is not the same thing as an audit session.
> 
> 
> Viele Grüße,
> 
> Henk
> 
> On 08.07.20 13:17, Anders Rundgren wrote:
>> On 2020-07-08 08:52, Henk Birkholz wrote:
>>> Hi list,
>>
>> Hi Henk,
>>
>>>
>>> this version of the reference interaction models I-D now includes the
>>> three main models that are used across several related documents:
>>>
>>> * challenge/response remote attestation (charra)
>>> * uni-directional remote attestation, and
>>> * streaming remote attestation
>>
>> This is great but I don't see that the session-based attestation
>> concept[1] used in Saturn[2,3], is covered by this I-D.
>>
>> Best regards,
>> Anders
>>
>> 1]
>> https://cyberphone.github.io/doc/research/session-based-remote-attestation.pdf
>>
>>
>> 2] https://cyberphone.github.io/openbankingwallet
>> 3] https://cyberphone.github.io/doc/security/keygen2.html
>>
>>>
>>> New diagrams for all three interaction models can be found in section 8:
>>>
>>>> https://datatracker.ietf.org/doc/html/draft-birkholz-rats-reference-interaction-model#section-8
>>>>
>>>
>>> As an attester's identity is vital to all interaction models in RATS --
>>> but also has severe implications -- we welcome Liqun and Chris as
>>> co-authors. They are experts for direct anonymous attestation (DAA) and
>>> remote attestation in general.
>>>
>>> An overview about DAA can be found in section 5:
>>>
>>>> https://datatracker.ietf.org/doc/html/draft-birkholz-rats-reference-interaction-model#section-5
>>>>
>>>
>>>
>>> Viele Grüße,
>>>
>>> Henk
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: New Version Notification for
>>> draft-birkholz-rats-reference-interaction-model-03.txt
>>> Date: Tue, 7 Jul 2020 23:41:20 -0700
>>> From: internet-drafts@ietf.org
>>> To: Liqun Chen <liqun.chen@surrey.ac.uk>uk>, Michael Eckel
>>> <michael.eckel@sit.fraunhofer.de>de>, Christopher Newton
>>> <cn0016@surrey.ac.uk>uk>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
>>>
>>>
>>> A new version of I-D,
>>> draft-birkholz-rats-reference-interaction-model-03.txt
>>> has been successfully submitted by Henk Birkholz and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-birkholz-rats-reference-interaction-model
>>> Revision:    03
>>> Title:        Reference Interaction Models for Remote Attestation
>>> Procedures
>>> Document date:    2020-07-08
>>> Group:        Individual Submission
>>> Pages:        22
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-birkholz-rats-reference-interaction-model-03.txt
>>>
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/
>>>
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-birkholz-rats-reference-interaction-model-03
>>>
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-birkholz-rats-reference-interaction-model
>>>
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-birkholz-rats-reference-interaction-model-03
>>>
>>>
>>> Abstract:
>>>       This document describes interaction models for remote attestation
>>>       procedures (RATS).  Three conveying mechanisms - Challenge/Response,
>>>       Uni-Directional, and Streaming Remote Attestation - are illustrated
>>>       and defined.  Analogously, a general overview about the information
>>>       elements typically used by corresponding conveyance protocols are
>>>       highlighted.  Privacy preserving conveyance of Evidence via Direct
>>>       Anonymous Attestation is elaborated on for each interaction model,
>>>       individually.
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>>
>>> _______________________________________________
>>> RATS mailing list
>>> RATS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rats
>>>
>>