Re: [Rats] Composite Evidence

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 24 January 2020 00:02 UTC

Return-Path: <evoit@cisco.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 F143012001A for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 16:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gnkjCQBZ; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=zQT+JU1L
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 ycZlVmp2fW6p for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 16:02:24 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AE11200CD for <rats@ietf.org>; Thu, 23 Jan 2020 16:02:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51499; q=dns/txt; s=iport; t=1579824144; x=1581033744; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JkYnuBBs85/GKkFkHdImB2IYDg9m3ZnchpQyyv09MGE=; b=gnkjCQBZ6BmH0pGEVNdoglmFf/H1C5ycemgW+wQgK1GarCZjWj3+2TyE +orivXLAPAuXdLrdINIeIf4GuBv3grPFPWHgt50wxGk9B76dh6sLiYVDH WX9L0Xj7KhDhbQ/iK9rlx6cF7kXmP3+IGzPnjuvv4BQ/Qa77hQGumRrHG s=;
X-Files: smime.p7s : 3975
IronPort-PHdr: 9a23:KwDIchEWRFXxTp5V//luVJ1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4w3A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+efP0aC0mNM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcAwCtMipe/5JdJa1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gSUvUAVsKy0gBAsqCoQIg0YDiw+BfmGBAZcOgUKBEANUAgcBAQEJAwEBGxICAQGBKyGCdAKCHiQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAxIICQQGEwEBMAcBDwIBCBEDAQEBIQEGAwICAjAUCQgCBAENBQgGFIMFgX1NAx8PAQKiHgKBOYhhdX8zgn8BAQWFDxiCBQcJgTiBU4o1DxqBQT+BEUeCFzU+hBYBEgEhHhYIglIygiyLRoIaiHeYC3YKgjmDZ4I4gSGFQ4lMmneOTRGbCAIEAgQFAg4BAQWBaSJncXAVgycJRxgNiAELAReDUIRRhSdbdAEBgSeJWg8XB4EEAYEPAQE
X-IronPort-AV: E=Sophos;i="5.70,355,1574121600"; d="p7s'?scan'208,217";a="419489820"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2020 00:02:22 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 00O02MGK031890 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jan 2020 00:02:22 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 18:02:21 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 18:02:18 -0600
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 23 Jan 2020 19:02:18 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fq5P5DjzK9K/o6DlWGBT0ZZg/L/diYpwKJ8sFuZdlUkiDyBoRAdV73f4zpgu/6fuKWWqsFmDq+UsMDDj6egqFE0ssQNYSOZ2eCXvV6j8pPVNODU8VUgJV8Gp2MpsVK+EJooXLphonWFE0orXJH7KGBW6b6hvhkj77FLVy54yhK6EINGYcnu7c2jpuSu0QOdp4LX8YlXZhSdDf4EOoYOla2ZAjWf6m2tl+3kYoFtDt3PUis5TTYQ4HAu8pzg88H+SaiqGjiZD5FZPjFb/m4DkHfdGQj0JxwCn2l/FbFEfLK73sJzDmPtTWf9WFpMLSodTNKK1RTtB3kc7DkubB0gygw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4UOjZ8/oPLpIXnbR32I/rFUWtvP+EYiCZeYWoxtXXbA=; b=dMJmzIQy+HNx1eoj/ubI+S9y0A9G4kvYa6wEMFzuQVWv7XUiIouRDpqJ0tqbrCOcK8iylkn3WMiX1b7FJiRf5DESNG+t0OKwg+URqZ+ncn6ZgKbWtO0q5JPrGqxxj6c0In5YOscf6DKw9mce3sGDK5oNdFxfcRel09YgdgtgchYvWz7AokFHvByS7vAQw3mC0cW2nLy2/46RhVJL+vNXt7b3kosasA9QJGZHUk0gO79nYMW/AZ1J2V8xtLOkB9eDLtdlRNdO6Oa0KlwUnRqRXvzIAo09kAASJZ7QrD5ya2ZNu4MS+nl+2EDEbBukYZwuvnQvrkXFOi+SD7azmYAhlQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4UOjZ8/oPLpIXnbR32I/rFUWtvP+EYiCZeYWoxtXXbA=; b=zQT+JU1LQ4LN1UyiiN9WPx7+ULi/H6i4mCTbeZ7pVrd5SknphFEjLHZz/EG6QZAl7pO2vxpnawJZalfHJQ8KPgcC/0VQbnCwIF6Uk+dj8kzKfMrag9tVRwsV+6dfunL0ekGkEHA/W5ZVd+YPfRtTOdVgVHO3P3C3vGgHxBZGj1g=
Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB2694.namprd11.prod.outlook.com (52.135.227.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.24; Fri, 24 Jan 2020 00:02:17 +0000
Received: from BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5]) by BYAPR11MB2536.namprd11.prod.outlook.com ([fe80::20d1:96f3:bde9:17e5%5]) with mapi id 15.20.2665.017; Fri, 24 Jan 2020 00:02:17 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Smith, Ned" <ned.smith@intel.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/jsEcLGXWTRbyFhaWoEjRAw6f4ozQQgABBXACAAAGQ4A==
Date: Fri, 24 Jan 2020 00:02:17 +0000
Message-ID: <BYAPR11MB2536663383942014FAD25F0BA10E0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <FAE8E748-474B-43EC-AEA2-33BD85075E36@intel.com> <BYAPR11MB2536818E391A47457B20FF90A10F0@BYAPR11MB2536.namprd11.prod.outlook.com> <7527C725-950B-4C7F-999A-28CDF6775B00@intel.com>
In-Reply-To: <7527C725-950B-4C7F-999A-28CDF6775B00@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
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
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com;
x-originating-ip: [173.38.117.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 98712b92-7c58-43f0-5178-08d7a060accc
x-ms-traffictypediagnostic: BYAPR11MB2694:
x-microsoft-antispam-prvs: <BYAPR11MB26943B420800B14D316B13F5A10E0@BYAPR11MB2694.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02929ECF07
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(346002)(136003)(376002)(199004)(189003)(2906002)(33656002)(4326008)(9686003)(55016002)(53546011)(7696005)(186003)(6506007)(86362001)(30864003)(26005)(66946007)(478600001)(76116006)(81166006)(81156014)(71200400001)(52536014)(66476007)(66446008)(66616009)(45080400002)(8676002)(66556008)(64756008)(110136005)(5660300002)(9326002)(8936002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2694; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SjUICfoUPbSnE9EhLBTvLpE4+McPH2yz3orbST1pSONgGvU2Hk0yDXwuHLQQynybSljwjFc0efZEc19mkOMxmXu8L/ss4xqQyHWM6wH8a2qSx04mlOW7edLYb4AmGGW3NDqKBYm5Sn4oQOOvNFFXT4mXqpmh01ql/wa/SGYayEH5xc0ZENEzHoQDC7x1EqHDS5YLQO/Z0V227QLzjAk0uxUeDI4uwlxe4CCmIY2LiLYjs/ycgpi7b1o1HTvf7Fim6Te4L5lvCjafkBj0yNIQdxLeHnuuRIfGAd9Kq0vXAWYdsHDBfTqSWSt80tb5laIuqzhmtV+uoJbb78ypWdnx6IzB51AoxYsPygkCoXCFDX3I+msuH9GJCktyoLshGbhSh4bUxH5YHuqSzbmI2B5QoD4MS0uy5jEdcKXEP5l3b5dRhALuuMRSewACuFZLbwwG
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_01F2_01D5D21F.7C6A2D50"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 98712b92-7c58-43f0-5178-08d7a060accc
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 00:02:17.1091 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VHfg/WMza9P9uaRnGkHp8SqEln3gGtBKXGpTBmdWxYpIhy0fI9d0lB3xTNJ99xsq
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2694
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/C-DlMVhSNU2PP3jVCQFgnDThEpY>
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: Fri, 24 Jan 2020 00:02:29 -0000

Hi Ned,

 

From: Smith, Ned, January 23, 2020 6:26 PM



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

<eric> This is one type of thing covered in (iii).  The generalization of what I intended from (iii) was evidence provided by an Attester which is provably not generated within the Attester.  For example, a recent Time quote from a Time Stamp Authority like in draft-birkholz-rats-tuda could also be included in what is sent to a Verifier/Relying Party.”

[nms] The Time Stamp Authority is an Attester (A1) that claims the time is some value E1. When THE Attester (A2), receives E1. What does he do with it? Does he forward it (see my reply to Michael’s thread) or does he use it to create Evidence E2? I think you’re suggesting it’s the latter. In this case, the evidence consists of a claim that expects the time. E.g. Claim c1 in E2 looks like: c1.name = “name of something”, c1.timestamp = E1.time, c1.xyz = … 

 

<eric2> Interpreting TUDA (draft-birkholz-tuda) on behalf of Henk...  

*	The Sync token of TUDA's Figure 1 (let's call it E3) is created by signing across E1 plus E2 (a local TPM quote) to create E3.  
*	E1, E2, and E3 all must be analyzed by A2 to determine the validity of the sync token.

 

The question to ask is whether or not provenance of E1.time needs to be communicated to Verifier. Maybe A2 just needs to prove that it uses a secure time source and that’s it? If you’re saying Verifier needs to know which time source it used, then it becomes a question of defining the claim c1 in such a way that it includes E1 (or points to it somehow) – BTW I’m assuming E1 is signed by A1 so it has provenance.

 

<eric2> E1 signed by A1 is an assumption of TUDA.  You need to know the Public Key of the TSA in order to understand (at minimum) a base timeticks or timestamp of the TSA.  (Actually it is a little more complicated than that, the Attester signs Quotes to the TSA, which is then signed and timestamped by the TSA.)   In any case, the answer to your question is that C1 will sometimes need to include E1 from a known, verifiable external source.

 

Eric

 

 

This seems like an interesting possibility / use case.

 

-Ned

 

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

 

Hi Ned,

 

From: Smith, Ned, January 23, 2020 2:04 PM

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’. 

 

<eric> While it isn't 100% clear in the current terminology, I see "Attestation Results"  as a special type of evidence. This is evidence where any trustworthiness claims made of the Attester can be accepted without requiring further evaluation.

 

The Relying Party needs a way to validate the freshness of whatever comes from the Verifier.   This can be done a number of ways.   For example in my diagram below, the TPM2's timeticks counters can be included in [1] and [4].  As the TPM has predictable incrementing of these counters.  The deltas between the timeticks counters can be trusted, even though both claims were generated from within an Attester Component.

 

A related question then is whether the Attestation Results in [2] actually match to the TpmQuote from [1].  The Relying party can establish this based on a hash within [2] proving its relation to [1].

 

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)

<eric> I agree with other type of evidence/claims relating to the attester in general, and these not needing to be provably associated with any specific sub-component.    This is one of the reasons I am hoping we turn this discussion towards a decomposed set of evidence types, rather than having individual terms for different combinations of composite evidence.

) 

 

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.

<eric> Nesting is certainly possible. So I am fine with this statement.  To match this to my example below, step [4] assembles a composition of this evidence, rather than doing any nesting.  Although perhaps nesting *could* be claimed the Attestation Results in [2] contains a hash of [1].  Is this nesting?  Is this Layering?  I don't know.

 

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.

<eric> This is the exact reason why I got caught up attempting a definition of "Layering".  I am not sure what constraints can a 'local verifier' trustworthy, nor when a 'networked verifier' can provide validation into a TCG DICE type Layer.  These are not questions I have looked at closely.   

 

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

<eric> This is one type of thing covered in (iii).  The generalization of what I intended from (iii) was evidence provided by an Attester which is provably not generated within the Attester.  For example, a recent Time quote from a Time Stamp Authority like in draft-birkholz-rats-tuda could also be included in what is sent to a Verifier/Relying Party.

 

Eric

 

-Ned

 

From: RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> > on behalf of "Eric Voit (evoit)" <evoit@cisco.com <mailto:evoit@cisco.com> >
Date: Thursday, January 23, 2020 at 7:40 AM
To: Dave Thaler <dthaler@microsoft.com <mailto:dthaler@microsoft.com> >, "Smith, Ned" <ned.smith@intel.com <mailto:ned.smith@intel.com> >, Henk Berkholz <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de> >, Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr+ietf@sandelman.ca> >
Cc: "rats@ietf.org <mailto:rats@ietf.org> " <rats@ietf.org <mailto: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 < <mailto:ned.smith@intel.com> ned.smith@intel.com> 
Sent: Wednesday, January 22, 2020 5:54 PM
To: Eric Voit (evoit) < <mailto:evoit@cisco.com> evoit@cisco.com>; Birkholz, Henk < <mailto:henk.birkholz@sit.fraunhofer.de> henk.birkholz@sit.fraunhofer.de>; Michael Richardson < <mailto:mcr+ietf@sandelman.ca> mcr+ietf@sandelman.ca>; Dave Thaler < <mailto:dthaler@microsoft.com> dthaler@microsoft.com>
Cc:  <mailto:rats@ietf.org> 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