Re: [Rats] Composite Evidence

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 23 January 2020 15:40 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 D2D5812007C for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 07:40:07 -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=MtASmu2o; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=crTMOovC
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 zWRh3QdVpOS9 for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 07:40:03 -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 D9DC612013B for <rats@ietf.org>; Thu, 23 Jan 2020 07:40:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27968; q=dns/txt; s=iport; t=1579794002; x=1581003602; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xPIhRls4PlerOoQQPytYRynFSxJGch3fPkBbwKiweYU=; b=MtASmu2oKSSxLWqZyF2enRN+8L1sMdu1+em662lT5z03t0D37+8oqbpH BVNdTyemiBX7438nuDQFnaWLrkdXdRHwuu7+iyzdoVD6vxhPhc1JUIudV Tw42FR/shgB8PaW8ZU2CMovvnbGM7AlnxezxH+C7nDm37cbHreQK3sqkB U=;
X-Files: smime.p7s : 3975
IronPort-PHdr: 9a23:pc/oZRyWRUPg78HXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YRyN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuIF0r6MNbhbjcxG4JJU1o2t3w=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DVAAA+vSle/5FdJa1mGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gSUvUAVsKy0gBAsqCoQIg0YDiwqCX5gPgUKBEANUAgcBAQEJAwEBLQIBAYErIYJ0AoIeJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDEhEEBhMBATcBDwIBCA4DAwEBASEHAwICAjAUCQgBAQQBDQUIBhSDBYF9TQMfDwECoU8CgTmIYXV/M4J/AQEFhQUYggUHCYE4gVOKNQ8agUE/gViCTD6EFgESASEeFoJaMoIsjWCId5kBCoI5g2eCOJAwmneOXpsIAgQCBAUCDgEBBYFpImdxcBWDJ1AYDYgBCxiDUIpTdAKBJ4ohgSIBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.70,354,1574121600"; d="p7s'?scan'208,217";a="419199585"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 15:40:01 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 00NFe1Rg023717 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2020 15:40:01 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 09:40:00 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 10:39:59 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 23 Jan 2020 09:39:58 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XLQgJzJj0DFt/DVNIWm0ub2mItoaxZ25iaBFqaoG+QPrYA/mVXAhwH4Yn6EKCQpNyK5b2SnSNTPOp6DnVc6THD4ysNPyqbD0qxwm4UpGYZsX1upq+FeG5mKEja0wdPvCBNZ3sbnJK7Q8qrvO30C9rDqihe6WWcvWfEjKy+YWhwFLX+FB3cigJbDLCTYsFjrPCZobUUIcWLyBdYb6am8c19SAW4o2raTpTLjfjAUoQMnPzadFISXRCaZaCjylV0aOhwM0ZzEIbto80EhZwOQ3n3YPNqbcShP9X1DsCtl6aruyxDlE6jFN93xLWYaELoi2iq65mu7MvP4WDoncNoBpGg==
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=8Vp9nxX+nN1e+wIYp8zWymEwsaeVJbQM2dXRnHxtN34=; b=dfoRDYff+3HZSeXCws2nS3n69ynbzrOG67S6Jpw9xDnfd4rF3TGPq6LeuWpmKe4xKNNTBI7wYhnAxYl4OUrMsbnrsJP1/9kG1fwKvjvm26pYF4Jvv+niTyAygqcy3NqtGdbVkSQe0dRjkCFnhH/bbfRvPqT4TMos7/u7hpIRcGlo5SzFBGiz75GMcM2d3MUOQ5etnzcsQEu0x77bQyLgVgJS2RJY0tLSswL5pnSs6WI4K6zCNOd62q84rrUytiLlnf9icJmrFmyhT2eGwGEzM09OmR+DbtLzIZWGAqPnmTokWa9baGdM73cnFFIIvJ0fF94BrGwDt8x/6emqM380Fg==
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=8Vp9nxX+nN1e+wIYp8zWymEwsaeVJbQM2dXRnHxtN34=; b=crTMOovCFVEC05XoejuvWdGWFKSRHkBTmFGxIIP+kSUkp0yZ935f20IBhYLl4BzlhUDtHkuEI7P+I6RdKfoK8rdgspNpJEa5vMQaLsLzwkWbdOwd83zhWuQF5kbNCVkH6hZ1rb5iNU5SsS0nSisrMVsxeUnzRJV+NL8RUY+QEMw=
Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB2792.namprd11.prod.outlook.com (52.135.225.142) 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 15:39:57 +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 15:39:57 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Dave Thaler <dthaler@microsoft.com>, Ned Smith <ned.smith@intel.com>, "Birkholz, Henk" <henk.birkholz@sit.fraunhofer.de>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Composite Evidence
Thread-Index: AdXRgB49sEcLGXWTRbyFhaWoEjRAwwAD+4eAAABTccAAG3YQ8A==
Date: Thu, 23 Jan 2020 15:39:57 +0000
Message-ID: <BYAPR11MB253631F1307FCEE4A57DA969A10F0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com> <582E844D-48C1-44CA-A94E-3FD4F1F9EDF3@intel.com> <BL0PR2101MB10278EBC8D834CD28B6BFF4BA30F0@BL0PR2101MB1027.namprd21.prod.outlook.com>
In-Reply-To: <BL0PR2101MB10278EBC8D834CD28B6BFF4BA30F0@BL0PR2101MB1027.namprd21.prod.outlook.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: db9d1ff0-d973-46a8-93b8-08d7a01a7ff7
x-ms-traffictypediagnostic: BYAPR11MB2792:
x-microsoft-antispam-prvs: <BYAPR11MB27920277B1A6253099E25C8FA10F0@BYAPR11MB2792.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(346002)(366004)(396003)(199004)(189003)(186003)(2906002)(45080400002)(7116003)(81166006)(8676002)(71200400001)(81156014)(86362001)(6506007)(9326002)(8936002)(4326008)(53546011)(110136005)(33656002)(55016002)(5660300002)(7696005)(9686003)(316002)(52536014)(3480700007)(66556008)(66616009)(64756008)(76116006)(66946007)(26005)(66446008)(66476007)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2792; 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: SQMBwo1q1I86MlRnwYuDYOTPkSEY4aRy873a42evrJj2QQ/NShMhq/8Jn5sBuARzakTnwgLD9QGjFCwKfpzEbC8k7xdfhK/ZOtMWmZrtQGtYF0aAcQscPXYaFezshPTzvD0yx4ZYz8hIVB241a2oSVRkn+GoLHACqfzP0LM2UWeYejGsoSe+bPfOPbJ2ED8ncBq3MR0WJo/Al8HVQUAi+go96g6+9koPxkotY5y2wYXl/JDWnfilUhf3Ep4pYh1QMaxfL7P2xjk3kBwOojyeuOHlw/1d3n+LN8S1Rm7/qT0vU+SvVL/5U5u+yfiE9HbnTmv2DUr48aZuWZXi92akkN03jsvBCav3Kq6lfg9xmhFFwFsHPMgHqJstuyPaYYAdhyfPZ7MuGyuNsUWffOGhnI1wfLIoz2NF+ES5SEsEWTjs4QYxU2gbdFCGDWImG/x1
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0085_01D5D1D9.71809BE0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: db9d1ff0-d973-46a8-93b8-08d7a01a7ff7
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 15:39:57.0811 (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: J59XwCNI5uEs8uJq+LrFwgBxCeZPNdIDbStoWhlOMCnrYLzW62L0T6JStpfetfXN
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2792
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/4FryznH-Lp1-Hr8V_yYj3Oq98vA>
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 15:40:08 -0000

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