Re: [Rats] Composite Evidence

"Smith, Ned" <ned.smith@intel.com> Thu, 23 January 2020 01:54 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 47E9B120018 for <rats@ietfa.amsl.com>; Wed, 22 Jan 2020 17:54:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 9PONYS0YebGC for <rats@ietfa.amsl.com>; Wed, 22 Jan 2020 17:54:31 -0800 (PST)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 D4F0E12004E for <rats@ietf.org>; Wed, 22 Jan 2020 17:54:31 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2020 17:54:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.70,352,1574150400"; d="scan'208,217";a="285760386"
Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga001.fm.intel.com with ESMTP; 22 Jan 2020 17:54:31 -0800
Received: from orsmsx113.amr.corp.intel.com (10.22.240.9) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 22 Jan 2020 17:54:30 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.6]) by ORSMSX113.amr.corp.intel.com ([169.254.9.57]) with mapi id 14.03.0439.000; Wed, 22 Jan 2020 17:54:30 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: "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+4eA
Date: Thu, 23 Jan 2020 01:54:29 +0000
Message-ID: <582E844D-48C1-44CA-A94E-3FD4F1F9EDF3@intel.com>
References: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
x-originating-ip: [10.24.10.130]
Content-Type: multipart/alternative; boundary="_000_582E844D48C144CAA94E3FD4F1F9EDF3intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/gUtD3iy7i0e5qMA4PnSJWpCzygQ>
Subject: Re: [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 01:54:35 -0000

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>
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz <henk.birkholz@sit.fraunhofer.de>de>, Michael Richardson <mcr+ietf@sandelman.ca>ca>, Dave Thaler <dthaler@microsoft.com>om>, "Smith, Ned" <ned.smith@intel.com>
Cc: "rats@ietf.org" <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