[Rats] 答复: Composite Evidence

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Thu, 23 January 2020 07:53 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 9F60412016E for <rats@ietfa.amsl.com>; Wed, 22 Jan 2020 23:53:42 -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 Am7NIVG2ICey for <rats@ietfa.amsl.com>; Wed, 22 Jan 2020 23:53:40 -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 5F384120111 for <rats@ietf.org>; Wed, 22 Jan 2020 23:53:40 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 87067A25593D95A23AA8; Thu, 23 Jan 2020 07:53:37 +0000 (GMT)
Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 23 Jan 2020 07:53:37 +0000
Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 23 Jan 2020 07:53:37 +0000
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 23 Jan 2020 07:53:36 +0000
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.173]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0439.000; Thu, 23 Jan 2020 15:53:30 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "Smith, Ned" <ned.smith@intel.com>, "Eric Voit (evoit)" <evoit@cisco.com>, "Birkholz, Henk" <henk.birkholz@sit.fraunhofer.de>, Michael Richardson <mcr+ietf@sandelman.ca>, Dave Thaler <dthaler@microsoft.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Composite Evidence
Thread-Index: AdXRgB49sEcLGXWTRbyFhaWoEjRAwwAD+4eAAAwyENA=
Date: Thu, 23 Jan 2020 07:53:29 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13EB9F171@dggemm511-mbx.china.huawei.com>
References: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com> <582E844D-48C1-44CA-A94E-3FD4F1F9EDF3@intel.com>
In-Reply-To: <582E844D-48C1-44CA-A94E-3FD4F1F9EDF3@intel.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.46]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EB9F171dggemm511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/vKxg12kaCkjsyI6kWo2KBd6F5Sg>
Subject: [Rats] 答复: Composite Evidence
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, 23 Jan 2020 07:53:43 -0000

Hi,
I agree with Ned’s categorization of two, and we need to have different terms for them.

I am also wondering the reason why you want to receive a time series snapshots of the same component? If you want to identify the change of a component’s trustworthiness during a period, maybe a better way is through the on-change evidence notification.

B.R.
Frank



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] 代表 Smith, Ned
发送时间: 2020年1月23日 9:54
收件人: Eric Voit (evoit) <evoit@cisco.com>; Birkholz, Henk <henk.birkholz@sit.fraunhofer.de>; Michael Richardson <mcr+ietf@sandelman.ca>; Dave Thaler <dthaler@microsoft.com>
抄送: rats@ietf.org
主题: Re: [Rats] Composite Evidence

Eric,
I think there are two types of “composite” things that could be considered (i) decompositions of hardware and software such as a motherboard and the sub-components that could be plugged into it and (ii) time series snapshots of the same component.

You seem to be asserting (ii) where a time series snapshot of the same thing could be considered “composite evidence”.

I think both cases are valid, but maybe it makes sense to use different terms for each as they seem to have distinct properties. (e.g. evidence having multiple entries of a component with the same name  under (i) implies multiple instances of the same type of device – such as two NIC cards. Whereas under (ii) multiple entries implies there is one instance of the NIC sampled over a time interval.

-Ned

From: "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>>
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>>, Dave Thaler <dthaler@microsoft.com<mailto:dthaler@microsoft.com>>, "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>
Cc: "rats@ietf.org<mailto:rats@ietf.org>" <rats@ietf.org<mailto:rats@ietf.org>>
Subject: Composite Evidence

Henk,         Dave,
Michael,    Ned,

I promised you a definition for Composite Evidence.  You can see my proposed definition directly the text below, but I am not willing yet to place it in a Pull Request. I thought an email thread might be helpful first.

Anyway my strawman definition for Composite Evidence is:  Evidence which includes multiple sub-elements of evidence, more than one of which can be computationally verified to have been generated by a specific Attester Subcomponent or Verifier.

I built this definition considering the passport model, which looks like it will often needs to use composite evidence.  As an example of why I believe this, see the use case below.

    .--------------.
    |  Verifier A  |
    '--------------'
        ^     [2]
        |     Verifier A signed Attestation Results @time(x) (
    evidence(  |  determination, hash(TpmQuote@time(x)))
    TpmQuote   |
    @time(x))  |
       [1]     V
     .-------------.                           .---------------.
     |  Attester   |<------nonce @time(y)---[3]|  Verifier B   |
     |    .-----.  |                           |       /       |
     |    | Tpm |  |[4]-composite evidence ( ->| Relying Party |
     |    '-----'  |      TpmQuote@time(y),    '---------------'
     '-------------'      TpmQuote@time(x),
                          Verifier A signed Attestation Results @time(x) )


In the example above, evidence at time x is generated and signed within a TPM.  This would *not* be composite evidence.   This evidence would be evaluated by Verifier A, signed, and returned as Attestation Results to the Attester.   A subsequent request from a Relying Party at time y could pull three independently signed elements of evidence from the Attester.  These three would comprise the composite evidence which when taken together would allow Verifier B / Relying Party to evaluate the current trustworthiness of the Attester.

Does this definition meet your needs?

Thanks,
Eric