Re: [Rats] Composite Evidence

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 23 January 2020 21:08 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 69D4712083C for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 13:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, 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=ZDcIS2L7; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=eGZWZc1o
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 qyqitmcM0k7M for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 13:08:38 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52DD7120823 for <rats@ietf.org>; Thu, 23 Jan 2020 13:08:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13236; q=dns/txt; s=iport; t=1579813718; x=1581023318; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3xRxqSBG4gnMjwejhAt0Sm9NqzgbnxrbniEbmR6W/1I=; b=ZDcIS2L7WDXYvPLqJMqRnIsPkRpNNLgVY1tsJsx7HQqiyLVCOEFOoTV2 UtLGb1shgR4/wTcpYMYwYV5J+VC/wpetuibLZznYzhZ+S8+wuxIxX7h+t JZFjdmggADOg5TyNj+ZDOT3QU+OuXTKwG94xQbZdvp3Siizu8QwAGqNU3 U=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AsT6O2hDtK8aSHTOZeglrUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg93kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIeDtbjASF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAQC9Cipe/51dJa1lHQEBAQkBEQU?= =?us-ascii?q?FAYFpBgELAYFTJCwFbCstIAQLKgqECINGA4sOToIRgQGXDoEuFIEQA1QCBwE?= =?us-ascii?q?BAQkDAQEfDgIBAYFMgnQCgh4kNgcOAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQE?= =?us-ascii?q?CARIRHQEBMAgECwIBCBIDAyoCAgIwFw4BAQQBEggGFIMFgX1NAw4RDwECojo?= =?us-ascii?q?CgTmIYXWBMoJ/AQEFhQ0YggUHCYE4AYFSijUPGoFBP4ERR4IXNT6EFQEBEgE?= =?us-ascii?q?PEoMOMoIsjU6SWI8yCoI5g2eCOIYaihaad45emwgCBAIEBQIOAQEFgVkNJWd?= =?us-ascii?q?xcBWDJwlHGA2IAQsBF4J8VIpTdIEpiVoPFweBBAGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.70,355,1574121600"; d="p7s'?scan'208";a="706320772"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 21:08:37 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 00NL8b6g003092 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2020 21:08:37 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 15:08:36 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 16:08:35 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 23 Jan 2020 15:08:35 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n58l0JF36gUUpYmrg1CPJxhoUaG6LUZKGteomu59iNhbmjuKQHWOqIcqoyNPAOBSGQ5ZSZsdp5yl196d+T5BYP2LGHSXVek2gkbZs7r2O3eETmpzbVfUSY9/7JRlwCtW/6JqD4P/MnYCeWXYFwobI4HSnXvtDyiaq5bpcI0MegXxLhTEbmq5WB25+sWn3frskJn7SAygqlUoeIVEYj9nEvnmM5oicIDABzjB9GiEsTeCegh543hlbMai+Nkc1ygSpqaNLcaW7oEOUhH3ViJY0VKoF4RbciF3JLl6mFXLnsxc1cKKj97frQQvgVvsEJS8bVDHqMAojE4AbmA3fFCYiA==
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=OyXgaOfhj8jstRtl9NUkfyPpazkbGV6bsDiICewxDbQ=; b=mRYQorjZ+N+YAP7J49svt14EGivD2w6U6PMQxn+D+8r4v3QAySRY/tjMNcAO4v6JYnRjfFKf8jMMq76lFHzAQMaN+eaL1QM63OvdKXRcExw9gffHmg670VMCNyrrWf+Q2yquKrZTySXfVq9fwGyrKlEoPfWHLd49t5y/9S6Axf5LALKmSKr+WXNRHT75mohxKdBEhYYym8BsRPJZJzOeJEmEidUD6YUMeYyP4tzyEenBoFW49eikzYIuEQzN/RHS2gQ7Ah1aq/CjbMwa2KNrBcTWT8yttzcCSy6HGEbT2OarfAeM2Gl4MgQ86XIbemNoWWU3NzAyFUTSiPfbOB2OYA==
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=OyXgaOfhj8jstRtl9NUkfyPpazkbGV6bsDiICewxDbQ=; b=eGZWZc1oWz91R6zYdPtLo8Wh8EnXLZCWpf6aBHLEGRxnJdfcy0Hkv/NoNwkQjLFkN3sMWKfdmwnLpqHxxUU5zrSA55rii7sFks6ODEy/Yl+S5l7uNr/Gsw1PtFSlTwJm2nJH4E9K9Lj/3M27QeZeBO693WtH2veacjZg8S21qZA=
Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB2981.namprd11.prod.outlook.com (20.177.224.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Thu, 23 Jan 2020 21:08:34 +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; Thu, 23 Jan 2020 21:08:34 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Smith, Ned" <ned.smith@intel.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Composite Evidence
Thread-Index: AdXRgB49sEcLGXWTRbyFhaWoEjRAwwAFlsyAABye0OAABxixAAACBbaQ
Date: Thu, 23 Jan 2020 21:08:34 +0000
Message-ID: <BYAPR11MB2536BA19568435E7724D79DCA10F0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com> <25403.1579747229@localhost> <BYAPR11MB2536EEF62BD7B1C53EC59659A10F0@BYAPR11MB2536.namprd11.prod.outlook.com> <85492C6F-E854-448F-9507-BBAC25455392@intel.com>
In-Reply-To: <85492C6F-E854-448F-9507-BBAC25455392@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
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: ca7036b9-1d82-448c-eedd-08d7a0486846
x-ms-traffictypediagnostic: BYAPR11MB2981:
x-microsoft-antispam-prvs: <BYAPR11MB29813EF2083A1995A9565A39A10F0@BYAPR11MB2981.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(366004)(346002)(376002)(199004)(189003)(86362001)(6506007)(71200400001)(7696005)(33656002)(966005)(52536014)(316002)(5660300002)(110136005)(66616009)(478600001)(26005)(2906002)(186003)(66946007)(66476007)(66446008)(76116006)(66556008)(64756008)(8676002)(81166006)(81156014)(55016002)(8936002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2981; 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: jChehZnV/+dik3edTm8bhpinW3+sZXiTzfOPfVz9r49OCPvrwfW2GEnE/qBLS8yHBtZr8pMNEuPlt0UC+Bf7ZqJtuFCTZQHKBjx0CJMYGymBTFqM32RbC8hTwS3nCRbf8PtRv0PxY+p/feeBcPEpI2/sUUKT5bdrD0ex6MutKFpVWnlRIV2nocYul9TFGgoL7pgjtxqL17A23ClYeIsx3HEjr0OP098Us/2OGTo3OFUvBIqD8PWcuzd7AyMPMiAQT8akkaUvoRYTgzEAWg0ApvPx3aCRrOjGeNBlAhMnN/bZfTztJanCQJyP0gZp12duvO7Aw0IANkiJMLJMYDV+awCPmAJoguqb1IBWcMhEjKSGHNuxEkGvo6Uz4N3L0oWMiDSm0Dcrv6RXJ3eqK4MUZ4z/TjtPGB9XSc61IdaRSA0/Wq4OhudBRd0ksy+eVFrIVq//aRcqowUm4x2Tu03g+2bRxS7TD9FbJU5KIZ/42+A=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010E_01D5D207.51279410"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ca7036b9-1d82-448c-eedd-08d7a0486846
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 21:08:34.1484 (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: BiV07VtHtE3e68zSa5dSlZKz1dq4jCN6lH3+fzqDOA0UR0OqmBJ7GgNZ0feVojp/
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2981
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/di_CMdje74HpVahU_u3j8hzisY8>
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 21:08:41 -0000

Hi Ned,

> From: Smith, Ned, January 23, 2020 2:43 PM
> 
> Eric, Michael,
> The semantics of 'union composite evidence' (below) seems to suggest that
> the local Verifier that produced 'ar' is itself an attestable claim. The Attester
> asserts that the Attestation Results from a local Verifier are trustworthy and
> that they originated from a sub-component of its Target environment.

This is a good example of why Attestation Results should be a subtype of evidence.

> Another way to think about it is the Attesting environment knows that the
> Target environment includes a Verifier and wants to assert that the Verifier
> has trustworthiness properties - possibly by returning its SWID tag value. The
> Remote Verifier can then evaluate the trustworthiness of the SWID tag.

Makes sense.

> Based on that, if the Remote Verifier trusts the Local Verifier then the local
> Attestation Results are not claims asserted by the Attesting environment,
> but claims asserted by the Local Verifier. The only claim that seems to make
> sense from the Attesting environment's perspective is that an 'ar' value from
> its Target was forwarded to a Remote Verifier. Signing the local Verifier's ar
> payload just asserts that the forwarding action has taken place. This is an
> argument for defining an 'Attestation Results forwarded' claim. Maybe this
> isn't that valuable in terms of a trustworthiness claim?

Signing the ar payload (or hashing it, then signing) can prove when the payload was created.  This is what is behind the "TUDA Core concept" within draft-birkholz-rats-tuda.

> If however the Attesting environment wanted to make a stronger
> trustworthiness assertion it would have some other way to collect Evidence
> about the Targeted sub-components (who must already have their own
> Attesting environments). But if the Attesting environment could do this then
> it must be the same environment as the sub-components' Attesting
> environments. In which case, there is no need for a local Verifier - it is just
> complexity for complexity's sake.

If by local verifier, you mean something internal to the Attester, then I agree with you.

> The case of a local Verifier working with a remote Verifier is semantically the
> same as a Remote Verifier working with another Remote Verifier. So, I don't
> see why Evidence and Attestation Results formats need to do anything
> special - like 'union composite evidence'.  It just says that Verifier1 may
> evaluate Evidence about Verifier2 before trusting Attestation Results from
> Verifier2.

I don't consider an Attester deciding what composite evidence to assemble for a "Verifier + Relying Party" as anything special.   What Michael's code says to me that it is important for that Attester to be able to frame all evidence so that the far end can understand the trust assumptions and validations needed to draw some conclusion from the aggregate.

Eric 
 
> -Ned
> 
> On 1/23/20, 8:47 AM, "RATS on behalf of Eric Voit (evoit)" <rats-
> bounces@ietf.org on behalf of evoit@cisco.com> wrote:
> 
>     Hi Michael,
> 
>     > From: Michael Richardson, January 22, 2020 9:40 PM
>     >
>     > Eric Voit (evoit) <evoit@cisco.com> wrote:
>     >     > 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.
>     >
>     > First, I found the diagram confusing, because I think you rotated our
>     > previous diagram 90 degress clockwise.
> 
>     As I was adopting the passport model, I used the Architecture Document
>     Figure 4 in Section 5.1 as a base.
> 
>     > The Verifier A, was in my mind, towards me (in the third dimension) out,
>     > "above" the "Internal Verifier", which we asked to have renamed "Claims
>     > Collector"
>     > (Screw the monochrome SVG debate... lets go VRML)
> 
>     I thought about trying SVG.  But I am not brave enough with the tooling to
>     be an early IETF adopter :-).
> 
>     > Second, I found the extra hash(),@time, stuff distracting, as it went into
>     a
>     > level of detail that just confused me.
> 
>     I need to put together a submission which defines the elements diagram.
>     These details are important for exposing why I see the intersections of
>     evidence types and composite evidence being quite important.  Some of
> these
>     reasons are exposed in my reply to Dave & Ned which dives into three
> types
>     of evidence (i), (ii), & (iii).
> 
>     >     > 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 am not sure what "computationally" verified means.
> 
>     Good point, we probably can remove "computationally".
> 
>     > Give an example of something that would not fall into that category.
>     > Maybe you are trying to abstract "has a signature" to things that can be
>     > verified without a asymmetric digital signature. (KerbV Ticket?)
> 
>     It is true I am trying to abstract away from "has a signature".   I didn't
>     want to exclude things like the possibility that Verifier B to go back to
>     Verifier A if a trust relationship hasn't been established between them
> yet.
> 
>     > I think that the key thing that we needed to be able to say is that
>     Composite
>     > Evidence is not:
>     > 1) struct evidence_claims foo[];
>     > -or-
>     > 2) struct attestation_results foo[];
>     >
>     > but rather:
>     >     union composite_evidence {
>     >           struct evidence_claims ec;
>     >           struct attestation_results ar;
>     >     } foo[];
> 
>     I very much agree with your code above. And the definition needs to
> reflect
>     this.   The question which Ned & Dave open up is whether types of
>     evidence_claims need to be exposed in your union composite_evidence.
> This
>     directly hits my question of whether the definition of composite evidence
>     needs to intersect the definition of evidence types (i), (ii), & (iii).
>     The more I think about this in the context of your code above, the more I
> am
>     hoping to keep the two concepts orthogonal.
> 
>     Eric
> 
>     > were I more hip, I'd learn to write this in CDDL.
>     >
>     > --
>     > ]               Never tell me the odds!                 | ipv6 mesh
>     networks [
>     > ]   Michael Richardson, Sandelman Software Works        |    IoT architect
>     [
>     > ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
>     [
>     >
>     >
>     > --
>     > Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software
> Works
>     > -= IPv6 IoT consulting =-
>     >
>     >
> 
>