Re: [Rats] Composite Evidence

"Smith, Ned" <ned.smith@intel.com> Thu, 23 January 2020 19:05 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 52E071209D6 for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 11:05:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 5LYcln0kEBL7 for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 11:05:54 -0800 (PST)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 35639120818 for <rats@ietf.org>; Thu, 23 Jan 2020 11:05:51 -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 orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2020 11:04:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.70,354,1574150400"; d="scan'208,217";a="426376479"
Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga005.fm.intel.com with ESMTP; 23 Jan 2020 11:04:07 -0800
Received: from orsmsx125.amr.corp.intel.com (10.22.240.125) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 23 Jan 2020 11:04:07 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.6]) by ORSMSX125.amr.corp.intel.com ([169.254.3.145]) with mapi id 14.03.0439.000; Thu, 23 Jan 2020 11:04:07 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Dave Thaler <dthaler@microsoft.com>, "Birkholz, Henk" <henk.birkholz@sit.fraunhofer.de>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Composite Evidence
Thread-Index: AQHV0h/jsEcLGXWTRbyFhaWoEjRAww==
Date: Thu, 23 Jan 2020 19:04:07 +0000
Message-ID: <FAE8E748-474B-43EC-AEA2-33BD85075E36@intel.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
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-23T02:04:41.5804837Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f78ab453-bbe8-4b62-9d54-dd2752ed39ae; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
x-originating-ip: [10.254.187.28]
Content-Type: multipart/alternative; boundary="_000_FAE8E748474B43ECAEA233BD85075E36intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/5qn_DjKPrkCtlLS7vv7Zi9zAD7E>
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 19:05:58 -0000

Eric,
Can you say more about relayed evidence in terms of how it was obtained and how it is protected as it is ‘relayed’?

The Passport and Background Check models incorporate ‘relaying’ of Evidence, but don’t try to describe the Evidence as ‘relayed evidence’.

In the context of Attesting Environment Collecting Evidence from a Target environment the way it is collected seems to determine whether it would be classified as (i), (ii) or (iii). (Note: there is the category of simple evidence that is just a set of atomic claims – no need to drill deeper into the foo[] data structure – and not represented by (i), (ii) or (iii))

If (i) means the target environment consists of a decomposition of things, then there is expected to be a nesting of Evidence that parallels the decomposition.
If (i) also means the target environment consists of a decomposition of things and where there is a ‘local verifier’ that evaluates Evidence and produces an Attestation Result in the place where the decomposition would otherwise expect nested Evidence then this seems to overload (i) somewhat.

However, it could be that one of these is what you mean by (iii)?

-Ned

From: RATS <rats-bounces@ietf.org> on behalf of "Eric Voit (evoit)" <evoit@cisco.com>
Date: Thursday, January 23, 2020 at 7:40 AM
To: Dave Thaler <dthaler@microsoft.com>, "Smith, Ned" <ned.smith@intel.com>, Henk Berkholz <henk.birkholz@sit.fraunhofer.de>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "rats@ietf.org" <rats@ietf.org>
Subject: Re: [Rats] Composite Evidence

Hi Ned,
Hi Dave,

I agree with Ned's framing of (i) and (ii).  These two are embedded in my passport example below.    We also have (iii): evidence which is relayed from outside the Attester.  I think (iii) needs to be broken out as an evidence type because signed information from the Verifier should be trusted differently from other evidence the Attester.

That makes:
 (i) component evidence
(ii) time-series evidence
(iii) relayed evidence

Beyond (i), (ii), & (iii), do we need term combinations of (i), (ii), & (iii) with the word "composite"?  Hopefully we wouldn't need to define six terms for each combination of these three variants.  Otherwise my example might be called "component, time-series, relayed composite evidence".  And that is a mouthful.

Eric


From: Dave Thaler, January 22, 2020 9:05 PM


Agree with Ned that we should keep composite devices separate from time series snapshots of the same component in terms of concepts.

From: Smith, Ned <ned.smith@intel.com<mailto:ned.smith@intel.com>>
Sent: Wednesday, January 22, 2020 5:54 PM
To: Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>>; Birkholz, Henk <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>>
Cc: rats@ietf.org<mailto:rats@ietf.org>
Subject: Re: 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