Re: [Rats] Composite Evidence

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 23 January 2020 16:19 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 CE3191208A2 for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 08:19:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.498
X-Spam-Level:
X-Spam-Status: No, score=-13.498 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, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=AZvydTiW; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=gmA9D4w2
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 Mt9EdWPpG4Fg for <rats@ietfa.amsl.com>; Thu, 23 Jan 2020 08:19:38 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3D312089F for <rats@ietf.org>; Thu, 23 Jan 2020 08:19:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39394; q=dns/txt; s=iport; t=1579796377; x=1581005977; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9+DjY4f762ZaqdtSTMGPrJepqtqU2xBNRU5wCQotyZs=; b=AZvydTiWZ/nZkZkUay1XeTYOZFB5cW4WrYWgHgqlv0HgRZsVhIUg5p8t +LuC5cGIjyxR2+aUDmVqgjDemYDYECMutDQheifeBqNh7msOVpgh2Q2NV bMgUGTyZdNuHT+w5a2XrQuErgeOPq2CIlTKL4I8vDBCqXgEsmiLsoT55C A=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AqJuHSRXMUHw3PAOvpyjRbjUtp5fV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANWJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3AsNDSHdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAAC6xile/40NJK1cChsBAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgWoDAQEBCwGBJC8pJwVsKy0gBAsqCoQIg0YDiwyCX5g?= =?us-ascii?q?PgUKBEANUAgcBAQEJAwEBLQIBAYErIYJ0AoIeJDcGDgIDDQEBBAEBAQIBBQR?= =?us-ascii?q?thTcMhV4BAQEBAxIRBAYTAQE3AQ8CAQYCEQMBAg4TAQYDAgICMBQJCAEBBAE?= =?us-ascii?q?NBQgGFII5TIF9TQMfDwECkH2QZQKBOYhhdX8zgn8BAQWEfBiCBQcJgTgBgVK?= =?us-ascii?q?JJoEPDxqBQT8ma0eBTn4+hBYBBwQHASEeFoJaMoIsjUQcL4hImAt2CoI5g2e?= =?us-ascii?q?COI1QgmCCR4gKkCaOXpYhhGcCBAIEBQIOAQEFgWgjKj1xcBWDJ1AYDYgBCxi?= =?us-ascii?q?BBAECgkmKU3QCgSeKEAIPFweBBAGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.70,354,1574121600"; d="p7s'?scan'208,217";a="618959545"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 16:19:36 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 00NGJajt012964 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2020 16:19:36 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 10:19:35 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 10:19:34 -0600
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 23 Jan 2020 10:19:34 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X5tM1WWwGavI0iLnYSydLIQa/lXP9uIM9ZITOEMhuV5Qnw3bf1K2xGUSH3IIGj1nLgvRcYa+oxQ0MR9Pym0dgA6b888fG9PRXtgM9wk17AIIJgyGImafvNjWMGop93P1Spcg2aJ89uqqRobiT3zMJ2jolsRkdM+dXU1XgxCvcY5/H3W5QnlU/9VrZeJcehmjtqJNONh/PSyq/kqIaOE2djVDYf0lpQS5q2hiHO1Pn4msbBZDJGW9D725LYX3K7szBf6kEs6X1y1SGpC2A7GwmIJ26K4jjnYwCkZceDcKy+z21Sw6dm/K4V3O62p+SwHEMsqr+SWvOe/TMw7AvsNV/A==
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=/R6NGhzcczz9tKEG3TPJuEdGgyyv3ll8tlYZk/g2ZWA=; b=DQhI0SUt95dSsXHl9ags1BC/kVp8mCm8UAst7AqNw3pk7AG5bByyQ+/DMGctTwT89zmki1AC/oR0YMaijiA5y/y/z7lAASEhK4Sr74hHhftCTs67LertxzHhe1VmYB47Ctyu3PX2HDkAFT2lbzlUAqVONDPmBLGx06USB3WSjJfs4nfNaSXtbSmINbW7C5qpIvsodjg1pm1Iv3Xl1Ec3s22e1wBn1fQCWwUDHwypbOwryGnXkOvH8aEEjK2LFMB7ixHu6ygKmZ6dGUU9TarD6lPNdCsf/7mDlgnTaB/fk2ThpjSFOJ6uxnRg6DXBBQ2FF7VAGhHYCGWUESJ2yzDpBg==
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=/R6NGhzcczz9tKEG3TPJuEdGgyyv3ll8tlYZk/g2ZWA=; b=gmA9D4w2IqeKYLQfZqyRtTuFM1J6OYmiQV8R12ykSF82ZTiViXcGXQfPd0W4za0PglqI5jcmT3JEHnYajzaKWPrT8ewYE3PWE6WRV/HhzWkz7gWX0FZVV55LrGDJU/hRFmPhCXTv58BDJBEzvfFCllL8D1KNvjAaaD+WdZZJkt8=
Received: from BYAPR11MB2536.namprd11.prod.outlook.com (52.135.226.32) by BYAPR11MB3766.namprd11.prod.outlook.com (20.178.206.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Thu, 23 Jan 2020 16:19:33 +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 16:19:33 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, "Smith, Ned" <ned.smith@intel.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+4eAAAwyENAAEKRfYA==
Date: Thu, 23 Jan 2020 16:19:33 +0000
Message-ID: <BYAPR11MB2536B58BC13E266AF4422927A10F0@BYAPR11MB2536.namprd11.prod.outlook.com>
References: <BYAPR11MB2536867559E1A20682A1FC2BA10F0@BYAPR11MB2536.namprd11.prod.outlook.com> <582E844D-48C1-44CA-A94E-3FD4F1F9EDF3@intel.com> <C02846B1344F344EB4FAA6FA7AF481F13EB9F171@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13EB9F171@dggemm511-mbx.china.huawei.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: e0d411fe-0f4e-4771-f02f-08d7a0200857
x-ms-traffictypediagnostic: BYAPR11MB3766:
x-microsoft-antispam-prvs: <BYAPR11MB37663AA39881E913959A888BA10F0@BYAPR11MB3766.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4502;
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(396003)(346002)(366004)(136003)(189003)(199004)(7696005)(3480700007)(76116006)(81166006)(8936002)(55016002)(7116003)(66946007)(478600001)(2906002)(5660300002)(45080400002)(81156014)(8676002)(52536014)(33656002)(4326008)(9686003)(71200400001)(53546011)(6506007)(110136005)(66556008)(186003)(66616009)(64756008)(9326002)(66446008)(86362001)(26005)(316002)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3766; H:BYAPR11MB2536.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: P1OkIfiIgfAZsn5hUfWz5snw4ydN1Wv0joCMXvo5l6gaw3t/WSWf9Z0J39CScSK35FWwvZCO1wE9Qh6USWes3/VihnOsqnslx7D8HhySAcKoNBnzrx+NnLi7B/N/lrBBfu9L7Lb9aSpuBi/BclpiWnyDlfqjlZbQtuCl2KnaxihLQiFRzt00c/yytx4GMuSZCTloU4sbmmO1khEx4fP0J9UDwrbjXpUfsTaXL0F/VPANdN9OsCR7Ks1Rx2OaANsb1qk6HXWvve5qA/4a7dhQLt/1zhnwWOz7KAoX7fGeAc3iuS6i9J1x8+yKi0e80/a7SjS7RpWLB7sbkH88VIFh3p82aq6E4Bw+cMDyjQaCeyEKzvoqCkdMS1yn7LyOdLvekcKd6Uaf+UWcaidDAZHzE3QcVT2vrPYGBqLZFzgGDyJzvO6RUrp132v6cCRLPqI9
x-ms-exchange-antispam-messagedata: UFlp4cHr6Lmz44G3s8aNjcY3aKUbwHlUjDtZI+0q9YBOa88ohOHCvG9AIvgnAapdIGlxHmlZy8lN7AjT1HxtMSJ+iqESme7NsvVbMzgT6h/BBGNhKrrakf9KojujV7po0FFt92wzZNtWk7gduVTSjg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D8_01D5D1DE.FA15DF60"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e0d411fe-0f4e-4771-f02f-08d7a0200857
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 16:19:33.4223 (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: tebfELwuax/xw6nFr2/AWpy9GNAweGrkoyw4t2VuR6rMtPdErNsIjuqRyVe4BkTk
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3766
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/IaQNZKvlP2M000ZYKLpg8hW8ch8>
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 16:19:41 -0000

Hi Frank,

 

From: Xialiang, January 23, 2020 2:53 AM



Hi,

I agree with Ned’s categorization of two, and we need to have different terms for them.

 

<eric> I agree that we need different terms for different types of evidence.  And added a third: relayed evidence.

 

I suspect it would be better to separate those from the "composite" concept.  It will be interesting to get others' thoughts on this.

 

I am also wondering the reason why you want to receive a time series snapshots of the same component? 

 

<eric> A Verifier can make an "ok-validated" evaluation on a particular TPM Quote, and send it back to the Attester.  Subsequently, a Relying Party can get a Quote from the same TPM to establish what are current, fresh measurements.   If both Quotes have the same PCR values, then the current state is in an "ok-validated" state.  This minimizes Verifier transactions, and gives quick/fresh response to the Relying Party.

 

If more documentation on this is interesting, I could put together something for the WG.

 

If you want to identify the change of a component’s trustworthiness during a period, maybe a better way is through the on-change evidence notification.

 

<eric> I initially thought on-change would be sufficient.  However there is quite a bit of volatile evidence which needs to be transmitted only under a certain condition.    For example, *only* when a specific PCR changes, send the full signed TPM quote as well as the log entries for that PCR.   It would be unaffordable/unsupportable to send all PCR quotes on-change as things like nonces/clock counters are continuously updating.

 

In a perfect world, this conditional push requirement would be a good match to your draft-bryskin-netconf-automation-yang.  However since this draft isn't close to being picked up by the NETCONF WG yet, we can't depend on that functionality.

 

If we are building from today's available RFCs, I think defining a new "attestation" event stream based on RFC-8639 Subscription to YANG Notifications will be a more stable starting point than starting with RFC-8641 for on-change YANG datastore subscription. 

 

Eric

 

B.R.

Frank

 

 

 

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

发件人: RATS [ <mailto:rats-bounces@ietf.org> mailto:rats-bounces@ietf.org] 代表 Smith, Ned
发送时间: 2020年1月23日 9:54
收件人: Eric Voit (evoit) < <mailto:evoit@cisco.com> evoit@cisco.com>gt;; Birkholz, Henk < <mailto:henk.birkholz@sit.fraunhofer.de> henk.birkholz@sit.fraunhofer.de>gt;; Michael Richardson < <mailto:mcr+ietf@sandelman.ca> mcr+ietf@sandelman.ca>gt;; Dave Thaler < <mailto:dthaler@microsoft.com> dthaler@microsoft.com>
抄送:  <mailto:rats@ietf.org> rats@ietf.org
主题: Re: [Rats] 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)" < <mailto:evoit@cisco.com> evoit@cisco.com>
Date: Wednesday, January 22, 2020 at 4:04 PM
To: Henk Berkholz < <mailto:henk.birkholz@sit.fraunhofer.de> henk.birkholz@sit.fraunhofer.de>gt;, Michael Richardson < <mailto:mcr+ietf@sandelman.ca> mcr+ietf@sandelman.ca>gt;, Dave Thaler < <mailto:dthaler@microsoft.com> dthaler@microsoft.com>gt;, "Smith, Ned" < <mailto:ned.smith@intel.com> ned.smith@intel.com>
Cc: " <mailto:rats@ietf.org> rats@ietf.org" < <mailto: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