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

"Smith, Ned" <ned.smith@intel.com> Thu, 21 November 2019 04:07 UTC

Return-Path: <ned.smith@intel.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 2B72D120959 for <rats@ietfa.amsl.com>; Wed, 20 Nov 2019 20:07:10 -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 8YzbIRnF2KCS for <rats@ietfa.amsl.com>; Wed, 20 Nov 2019 20:07:08 -0800 (PST)
Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) (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 11544120944 for <rats@ietf.org>; Wed, 20 Nov 2019 20:07:08 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2019 20:07:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,224,1571727600"; d="scan'208,217";a="407055485"
Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga005.fm.intel.com with ESMTP; 20 Nov 2019 20:07:07 -0800
Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 20 Nov 2019 20:07:07 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX153.amr.corp.intel.com ([169.254.12.169]) with mapi id 14.03.0439.000; Wed, 20 Nov 2019 20:07:07 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: 答复: [Rats] 答复: Another RATS message flow model for consideration:
Thread-Index: AQHVoCEjYz3HXCcnak+MxQp16YN1Yw==
Date: Thu, 21 Nov 2019 04:07:07 +0000
Message-ID: <D40636FE-7472-4851-9A16-7618ADFA1545@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [10.252.139.205]
Content-Type: multipart/alternative; boundary="_000_D40636FE747248519A167618ADFA1545intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/1QU2k125IvLTOzOcrKQv20MsRek>
Subject: Re: [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 04:07:10 -0000

The security concern is partially raised by the previous paragraph, namely that the RP shouldn’t take action or consume data from an Attester before receiving and evaluating the attestation Evidence as the point of attestation is to lend credibility and veracity to the data. This is a generalization that could be invalidated by use case or deployment specific circumstances, but seems to make sense as a guiding principle. The consideration is that if the perception of added complexity causes implementers to ignore the expectation that data isn’t trustworthy until the source of the data (attested environment) has been attested then it is a security consideration. Data SHOULD be presumed to be untrusted until proven trustworthy.

From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
Date: Wednesday, November 20, 2019 at 6:31 PM
To: "Smith, Ned" <ned.smith@intel.com>, "rats@ietf.org" <rats@ietf.org>
Subject: 答复: [Rats] 答复: Another RATS message flow model for consideration:

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