[Rats] 答复: 答复: Another RATS message flow model for consideration:

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Thu, 21 November 2019 02:31 UTC

Return-Path: <frank.xialiang@huawei.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 399761208AA for <rats@ietfa.amsl.com>; Wed, 20 Nov 2019 18:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 YBgr-syiSwVp for <rats@ietfa.amsl.com>; Wed, 20 Nov 2019 18:31:52 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 76C3B120077 for <rats@ietf.org>; Wed, 20 Nov 2019 18:31:51 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D6B18DA160A11EFCF293; Thu, 21 Nov 2019 02:31:49 +0000 (GMT)
Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 21 Nov 2019 02:31:49 +0000
Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 21 Nov 2019 02:31:49 +0000
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 21 Nov 2019 02:31:48 +0000
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.140]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0439.000; Thu, 21 Nov 2019 10:31:44 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] 答复: Another RATS message flow model for consideration:
Thread-Index: AQHVnizNPQKKKNhUk0ik7vfZORuaAqeUpIsAgABCTkA=
Date: Thu, 21 Nov 2019 02:31:44 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13EA623D5@dggemm511-mbx.china.huawei.com>
References: <AE350A78-D48C-4183-BDEC-82DA4EE8A49F@intel.com> <13A31581-D28E-490F-9C09-1C356855A46E@intel.com>
In-Reply-To: <13A31581-D28E-490F-9C09-1C356855A46E@intel.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.44.23]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EA623D5dggemm511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/aQK-gk2BGxXenIPETiGGppCgqoM>
Subject: [Rats] 答复: 答复: Another RATS message flow model for consideration:
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: Thu, 21 Nov 2019 02:31:54 -0000

Hi Ned,
Thanks for the good insights, please see my responses inline for your 2 emails below:

发件人: Smith, Ned [mailto:ned.smith@intel.com]
发送时间: 2019年11月21日 6:19
收件人: Xialiang (Frank, Network Standard & Patent Dept) <frank.xialiang@huawei.com>; rats@ietf.org
主题: Re: [Rats] 答复: Another RATS message flow model for consideration:

Also, the https://datatracker.ietf.org/doc/draft-xia-rats-pubsub-model/ omits discussion of pub-sub between Verifier and Relying Parties. Presumably, there can be multiple relying parties that use a common verifier. The Attestation Results resulting from the interactions between Attesters and Verifier become pub-sub “topics” for subscription by Relying Parties.
[Frank]: good point. And that pub/sub maybe is not the netconf/yang based, can be other methods, like: atom, xmpp and http-based. We have not considered this point right now, it can be in this draft later or discuss in other draft if the WG are interested.

Some attention should be given to the use case and architectural models. Presumably, there is a dependency / ordering that relying party enforces over the data it obtains (subsequently?) from the Attester. Otherwise, acting on un-attested data could imply a weakness in the data flow model. For example, a Relying Party might expect to receive a publication of an Attestation Results topic as an additional condition when being notified about a data topic originating from the same attested environment.
[Frank]: there may  be. But I hope not as it will introduce complexity. If we really need to deal with it, a simple way is to leave it to the Relying Party with some cache mechanism.

The current draft doesn’t adequately addresses the security relevant considerations given a pub-sub deployment that incorporates attestation IMO.
[Frank]: sure, definitely will do it in the future iterations. Is there any big security issues in your mind now? I am always curious~~

-Ned

From: RATS <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>> on behalf of "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>
Date: Monday, November 18, 2019 at 8:25 AM
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>>, "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>
Subject: Re: [Rats] 答复: Another RATS message flow model for consideration:

This “architectural model” parallels the roles message flow. I think it could be viewed as a third model something like a pub-sub broker where Relying Parties subscribe to Verifier (broker) to receive Attestation Results and Attesters publish to Verifier (broker) when a change to the Evidence is found.
                [Frank]: it’s a use case and a very good one, thanks~~ And there can be more use cases. Another example is simply periodically request/response message flow between each pairs.

                B.R.
                Frank

A pub-sub model might treat Claims as pub-sub Topics that can be subscribed to or published to.

I get that some pub-sub architectures eliminate the broker as a distinct entity, but conceptually the model isn’t fundamentally different than if there were a central broker.

-Ned

From: RATS <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>> on behalf of "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>>
Date: Saturday, November 16, 2019 at 2:17 AM
To: "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>
Subject: [Rats] 答复: Another RATS message flow model for consideration:

Oops, Some fixes of the below text:


发件人: RATS [mailto:rats-bounces@ietf.org] 代表 Xialiang (Frank, Network Standard & Patent Dept)
发送时间: 2019年11月16日 18:13
收件人: rats@ietf.org<mailto:rats@ietf.org>
主题: [Rats] Another RATS message flow model for consideration:

Hi RATS architecture design team and all,
In addition to the current passport model and background check model. I think there is a third message flow model possibly for us to consider:
Attester < -------------------- > verifier < -------------------------------- > relying party
                               Evidence                              attestation results

The key point of the above model is that verifier has independent connection with attester and relying party respectively, and there are two independent message exchanges between the attester and verifier, between the verifier and the relying party. Of course, if needed, there can be some trigger condition and interaction between these two connections.
The relative advantage of the above model is simple, and each role only see what he needs to see, like: evidence is not seen by the relying party, attestation results is not seen by the attester.

I am wondering whether the architecture draft will consider it?

B.R.
Frank