Re: [Rats] 答复: 答复: New RATS Architecture document

Michael Eckel <michael.eckel@sit.fraunhofer.de> Wed, 18 September 2019 14:19 UTC

Return-Path: <michael.eckel@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 3782612011C for <rats@ietfa.amsl.com>; Wed, 18 Sep 2019 07:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 u-kasIdaPpTu for <rats@ietfa.amsl.com>; Wed, 18 Sep 2019 07:18:56 -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 53CCC120099 for <rats@ietf.org>; Wed, 18 Sep 2019 07:18:55 -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 x8IEIjXl002367 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 18 Sep 2019 16:18:46 +0200
Received: from [141.12.89.53] (141.12.89.53) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 18 Sep 2019 16:18:40 +0200
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
CC: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>
References: <7d05116f-12aa-5dd7-81ac-6bd01630b1bc@sit.fraunhofer.de> <C02846B1344F344EB4FAA6FA7AF481F13E8F8575@dggemm511-mbx.china.huawei.com>
From: Michael Eckel <michael.eckel@sit.fraunhofer.de>
Message-ID: <dcacb7a7-9b59-b941-134b-98f3248b1265@sit.fraunhofer.de>
Date: Wed, 18 Sep 2019 16:18:40 +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: <C02846B1344F344EB4FAA6FA7AF481F13E8F8575@dggemm511-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------37AB3875CF79EF9CC40F51C2"
Content-Language: en-US
X-Originating-IP: [141.12.89.53]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/ZX2FZ10PSJFDQN9D5QkQDf4nYss>
Subject: Re: [Rats] 答复: 答复: New RATS 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, 18 Sep 2019 14:19:00 -0000

Hi Frank,

you are totally right in terms of replay attacks. I was talking about
reLay attacks (e.g. Asokan attack), not about rePLay attacks.

Open CIT (https://github.com/opencit) for example is doing that, too.

Best regards,
Michael

Fraunhofer SIT
*Michael Eckel*
Cyber Security Researcher
📧 michael.eckel@sit.fraunhofer.de <mailtomichael.eckel@sit.fraunhofer.de>
🕿 +49 6151 869-221 <tel:+496151869221>

Fraunhofer Institute for Secure Information Technology SIT
🏭 Cyber-physical Systems Security
🏠 Rheinstraße 75, 64295 Darmstadt, Germany
🌍 sit.fraunhofer.de <https://sit.fraunhofer.de/>

Member of CRISP

On 18.09.19 04:21, Xialiang (Frank, Network Standard & Patent Dept) wrote:
> But the nonce itself without IP  address can protect against replay attack already. Right?
> I understand this method is just for verifying the same Attester address, right? The Attester authentication can do the same job too.
>
> In summary, I don’t see very clear benefit for this method.
>
>
> This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
>
> 发件人: RATS [mailto:rats-bounces@ietf.org] 代表 Michael Eckel
> 发送时间: 2019年9月17日 20:31
> 收件人: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
> 抄送: rats@ietf.org
> 主题: Re: [Rats] 答复: New RATS Architecture document
>
>
> Hi Frank,
>
> just to reply to your comment on Section 5. The approach of replacing the first four bytes with the 4 bytes IPv4 address is to counter (some flavors of) relay attacks. The Attester replaces these 4 bytes with its IP address and the Verifier in a verification process does the same with the IP address of the Attester that it sent the attestation request to. Verification will be successful only if the IP addresses are the same.
>
> Thanks,
> Michael
> --
> [Fraunhofer SIT]
> Michael Eckel
> Cyber Security Researcher
> 📧 michael.eckel@sit.fraunhofer.de<mailtomichael.eckel@sit.fraunhofer.de>
> 🕿 +49 6151 869-221<tel:+496151869221>
>
> Fraunhofer Institute for Secure Information Technology SIT
> 🏭 Cyber-physical Systems Security
> 🏠 Rheinstraße 75, 64295 Darmstadt, Germany
> 🌍 sit.fraunhofer.de<https://sit.fraunhofer.de/>
>
> [Member of CRISP]
>
>
>
> Hi Henk, other draft authors,
>
> Thanks for the efforts for largely simplifying this new version, which looks much more clear and understandable.
>
>
>
> I have reviewed the draft through and have some comments as below:
>
> Section 1.1
>
> 1. should "message digest" be "MAC"?
>
> 2. nit. s/A corresponding attestation provisioning workflow uses trustworthiness Claims/ A corresponding attestation provisioning workflow uses Reference Claims/
>
> 3. the Endorsements definition in Section 4.3.2 seems to be more correct than the one in this section, but still be a little abstract. Is my understanding right: an example of Endorsements is manufacturer's CA?
>
> 4. In general, the overlapping exists for the RATS messages' definition in this section and section 4.3.2. Please combine them into one.
>
>
>
> Section 3
>
> The last sentence emphasis on the "change". Can you clarify what kind of change it is? The change of the Evidence with time or the change between Evidence and KGV? The former seems to be too narrow, the latter is better.
>
>
>
> Section 3.2
>
> Although I can understand, but some contents in it are not straightforward, like: " recursive trustworthiness properties and the need for termination. " and others. I suggest to re-write them using other well-known text such as: trust chain, root of trust, etc.
>
>
>
> Section 4.2
>
> 1. Freshness is only for replay attack? No any time freshness meaning?
>
> 2. for the principle of Identity, do you consider the privacy protection issue: run remote attestation without revealing the device's identity?
>
> 3. Some confusing terminologies: does Provenance equal to source authentication? does Veracity equal to integrity protection? Validity seems to be like Freshness, right?
>
>
>
> Section 5
>
> I don't get your point why the last four bytes of a challenge nonce are replaced by the IPv4 address-value of the Attester in its response. Can you clarify?
>
>
>
>
>
> B.R.
>
> Frank
>
>
>
>
>
> -----邮件原件-----
>
> 发件人: RATS [mailto:rats-bounces@ietf.org] 代表 Henk Birkholz
>
> 发送时间: 2019年9月10日 21:13
>
> 收件人: rats@ietf.org<mailto:rats@ietf.org>
>
> 主题: [Rats] New RATS Architecture document
>
>
>
> Hi all,
>
>
>
> we created a fully revised architecture document that maps and represents the state of the current discussion and the material presented at the last IETF meeting.
>
>
>
> The current Editor's version can be found here:
>
>
>
>> https://ietf-rats.github.io/draft-birkholz-rats-architecture/draft-bir
>> kholz-rats-architecture.html
>
>
> We will submit a new version the day after the RATS virtual interim.
>
>
>
> TL;DR
>
> Below you can find a list of essential changes & a list of action items still to be addressed.
>
>
>
>
>
> This version of the RATS Architecture document:
>
>
>
> * does not define or uses the terms "root(s) of trust" (RoT) or "Trust
>
> Anchor" (TA) at the moment. (Note: It is a fact that the Asserter Role
>
> _is_ a TA for the Verifier Role and that an Attester Role _could_ rely
>
> on RoTs. But - this content will not go into the main body of this
>
> document),
>
>
>
> * does define RATS Roles, Messages, and Principals formerly known as
>
> "Actors" (borrowing heavily from ABLP),
>
>
>
> * provides an even more "base" interaction model diagram for the RATS
>
> Roles than presented in the last IETF meeting slide deck:
>
>
>
>> https://datatracker.ietf.org/meeting/105/materials/slides-105-rats-sessb-rats-architecture-interaction-model-challange-response-yang-module-information-module-00.pdf
>
>
> * introduces a framework for "level of confidence" in the
>
> trustworthiness of an Attester and the endorsement of the protection
>
> characteristics of its "Attesting Computing Context", allowing for other
>
> entities to use this framework and fill it with, e.g., openly defined
>
> levels of confidence metrics,
>
>
>
> * is not based on the primitive of "trust" but the concept of
>
> "trustworthiness" as illustrated by the RATS charter,
>
>
>
> * simplifies the definitions of Attester and Verifier that seemed to
>
> have caused some unfortunate confusion following the proposal of Giri
>
> and starting with commonly-accepted definitions and then justify why
>
> they may need to be modified,
>
>
>
> * differentiates between the Attesting Computing Environment and the
>
> Attested Computing Environment better, which both are components of an
>
> Attester,
>
>
>
> * uses the "Claim" concept as a building block to compose Evidence,
>
> Known-Good-Values and Endorsements. Conversely, the "Assertion" concept
>
> is dropped in this proposal (as initially suggested by Laurence, IIRC?).
>
> (Note: this was done to simplify the discussion about the information
>
> model. Please also note: Due to the {J|C}WT definition of "Claim", a
>
> key/value pair is implied, which is already a data model decision and
>
> not mandated by an information model), and
>
>
>
> * analogously, now uses the term Known-Good-Values instead of
>
> Attestation Assertions.
>
>
>
>
>
> For future versions the authors intent:
>
>
>
> * to elaborate on the use of RATS Principals, including more exemplary
>
> diagrams of RATS Role composition and interaction between RATS
>
> Principals based on the use case document (and by that address a unified
>
> mapping to TEEP, RIV, and models that use EAT),
>
>
>
> * to shift some of the focus on technical-trust as proposed by Thomas.
>
> (the Endorsements provided by an Asserter are a first step into that
>
> direction),
>
>
>
> * still not to define the roots of trust terms nor invent new words for
>
> them :) But - start to reference them on a minimal level and define a
>
> base set of primitives they can provide in order to describe what they
>
> actually are and can do in the context of RATS as proposed by Ira, Simon
>
> and Thomas,
>
>
>
> * to introduce and define a concise scope for layered attestation,
>
> addressing, e.g., the staging of Computing Environments and the
>
> (un-)availability of an Attesting Computing Environment at certain
>
> points of time, or, another example given, addressing the
>
> differentiation of an attested boot sequence of an Attester and an
>
> Attester running TEEs or rich systems for years,
>
>
>
> * to address the change of Roles of a Principal over time as proposed by
>
> Ian,
>
>
>
> * to move the remaining architectural sections in the EAT draft into the
>
> RATS Architecture draft, and
>
>
>
> * to shift some of the focus on the out-of-band trust establishment in
>
> order to illustrate a coherent RATS ecosystem (e.g. the provisioning of
>
> key material is not include in the "base diagram" anymore for now - this
>
> will be more elaborated on in future section of the architecture).
>
>
>
>
>
> Viele Grüße,
>
>
>
> Henk
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> RATS mailing list
>
> RATS@ietf.org<mailto:RATS@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/rats
>
>   *   [Rats] New RATS Architecture document<https://mailarchive.ietf.org/arch/msg/rats/wSGCnW6oAveg6EXC7BuEC1UVBvE>  Henk Birkholz
>   *   Re: [Rats] New RATS Architecture document<https://mailarchive.ietf.org/arch/msg/rats/ATlF1dyQTPLBU62-uD7pBnZfwaA>  Giridhar Mandyam
>   *   Re: [Rats] New RATS Architecture document<https://mailarchive.ietf.org/arch/msg/rats/MMYVbA0RnARJyNCs9ujZi5H85Ms>  Laurence Lundblade
>   *   Re: [Rats] New RATS Architecture document<https://mailarchive.ietf.org/arch/msg/rats/mZYSW1fWfBNa5-g6iLRqvQkuk1g>  Simon Frost
>   *   Re: [Rats] New RATS Architecture document<https://mailarchive.ietf.org/arch/msg/rats/NmoL5MaM6urrz21Z3DvQH9ileW8>  Henk Birkholz
>   *   [Rats] 答复: New RATS Architecture document<https://mailarchive.ietf.org/arch/msg/rats/7EM4bPJowc4FhrvUkDkSW_0_ZBU>  Xialiang (Frank, Network Standard & Patent Dept)