Re: [Rats] Questions about latest PRs

"Eric Voit (evoit)" <evoit@cisco.com> Mon, 21 September 2020 20:42 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 82DF83A0994 for <rats@ietfa.amsl.com>; Mon, 21 Sep 2020 13:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=GEJzqJ5s; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=nd3cAh2y
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 VDcIidiZ4TsQ for <rats@ietfa.amsl.com>; Mon, 21 Sep 2020 13:42:00 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AA33A0992 for <rats@ietf.org>; Mon, 21 Sep 2020 13:42:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33408; q=dns/txt; s=iport; t=1600720920; x=1601930520; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vLUC+jpJIEJIZ2aewGNmIk9mVZ5LRWOdQEanmmtHBjk=; b=GEJzqJ5swwa3DEjLHD3QeCXiILhGIFIvs0dB+X1n2hSNLNOnEow6HJpK wvRn+sWde0TxavtluNMt6DzmOvG+V7RUOUfOFJsm9f534BifSgtQM99KV zBdyAs0fPSnVQrqDDmuGgrYakF4LuLmNGiEUK+zMErV97u/dJnE2Vih7h c=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AEBUsKh9NqqScsP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1CQBuD2lf/5hdJa1fHgEBCxIMQIJ?= =?us-ascii?q?yLykoB3AsLS8sCod2A416h2OOKoJnglMDVQQHAQEBCgMBASUIAgQBAYRLAoI?= =?us-ascii?q?rAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEBAhIbEwEBLAQHAQ8CAQg?= =?us-ascii?q?VEBMBBgcCMBQRAQEEDgUIBhSCOUw4gUZNAx8PAQ6qHwKBOYhhdIE0gwEBAQW?= =?us-ascii?q?BNFEDgycYggkHAwaBOIFTgR6CXEuHFBuBQT+BEUOCTT6BeWMDgSg4FRYJgxS?= =?us-ascii?q?CLZpWgRmbQwqCZ4RFgl+BUpF3oQGdXJBvhCwCBAIEBQIOAQEFgWsjgVdwFTu?= =?us-ascii?q?CaVAXAg2OH4NxhRSFQnQCAQEQIwIGCgEBAwl8jFIBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.77,288,1596499200"; d="p7s'?scan'208,217";a="803629183"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Sep 2020 20:41:58 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 08LKfwIq012892 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2020 20:41:58 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 21 Sep 2020 15:41:56 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 21 Sep 2020 15:41:57 -0500
Received: from NAM10-BN7-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.1497.2 via Frontend Transport; Mon, 21 Sep 2020 15:41:57 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cVwURzk5UdDaCKgzHWrpiI319YVnLCnUbqZYPHSZu33rfO0NwP/ak6L9eshqpYgKrrg/uvVTDfiY+FeLn/0dClQIrB1AN3NhrxA/IJEYGPz/o4sfAqvgTXhon/cIy2wuCm8z6zsPZhjiQCDK8E8AuBG08wXswIuLlVJF5fUbzc06dBWWjmY0NVNbfiwIAdSaoBeSVPCA3daJIfR217UTVFbeQwcpOjH23lXilT6t0AwIsCdopoEuVmaSc9lPycnu5YQLiV2WG2Qk3eP+m42M32soeq7SgMkqOgNCqEBm1vgZX2bKZvaT2Trnw8BrzKGGlyxSlzH9V2DLxceOBBvnNw==
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=6+Cm5HPS5j4OzjwgEWReK7Kdxn82i1+1DYDoD2nkkEI=; b=Q48lcO8tNeh+DO5SPfABZBYigO/1XrND4KHAvS7NcllR5NRthCMlxJNAcViaiKFeWV15xzQ7+8hd0yiiw5btyGPrxzXiRu9I1uu4hum7lHroquoAVO5fNPULZ4AXt5ORqpAX7gl7//VbYSiQ0OFNmrFvqv62/iAQ9AjWQu2VyA1H5i9w419khJf8i66FwxWfN2DGPDR9S2ZZLNjXyT9JcZaXFGW1uVI/fafZw49gMWgQOFfrrYvLQ7Zt1G3G7Ge8hEL7mOEn70c94ORcJwKg9otL65dd63ZRu4CmB29N9Mx5Fi16xI+1jXNSAAd5RQWktR8eLjum8bR9rNPb2lAdYw==
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=6+Cm5HPS5j4OzjwgEWReK7Kdxn82i1+1DYDoD2nkkEI=; b=nd3cAh2ysvH7D5Vp357J016Q30Gq7KTJ4nvL3leRsjRBpzsXhv2/ze7VuFaQrxW21UfkMttkGryZVAmTgQOB4v1ZkLtOfktWFa1fCpnaEeU5fVuiYcQcsSdvh/GlyhjQdwXC4Z9s2LANHfN3kiplZ9G3btoB0q4/n2t1tsl807g=
Received: from MW2SPR01MB0028.namprd11.prod.outlook.com (2603:10b6:907:12::33) by MN2PR11MB3662.namprd11.prod.outlook.com (2603:10b6:208:ee::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.19; Mon, 21 Sep 2020 20:41:55 +0000
Received: from MW2SPR01MB0028.namprd11.prod.outlook.com ([fe80::b0eb:c010:327a:65bd]) by MW2SPR01MB0028.namprd11.prod.outlook.com ([fe80::b0eb:c010:327a:65bd%6]) with mapi id 15.20.3391.014; Mon, 21 Sep 2020 20:41:55 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "caobin (A)" <caobin8@huawei.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Questions about latest PRs
Thread-Index: AdaOaksiGF1CuGPiRouIEBaLBIr2nABzXWSg
Date: Mon, 21 Sep 2020 20:41:55 +0000
Message-ID: <MW2SPR01MB002858B3733C6E29E74430A2A13A0@MW2SPR01MB0028.namprd11.prod.outlook.com>
References: <F0C5D68C1C185E479EEED366166A9E1909E2B140@dggeml529-mbx.china.huawei.com>
In-Reply-To: <F0C5D68C1C185E479EEED366166A9E1909E2B140@dggeml529-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7cf0e5a8-fbee-49ed-c129-08d85e6ec776
x-ms-traffictypediagnostic: MN2PR11MB3662:
x-microsoft-antispam-prvs: <MN2PR11MB366274A590214D8931CCB2D7A13A0@MN2PR11MB3662.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: P0LZqPJI3SWXDnfm8gA6FYX8HRhGS54gTUlcKPUXxAPZuvqG8pH/NXXnORiGSNxhQ44qz5nbDZsGXASyvsKo5yUrx8H9xbT1DXBm7oTOEn6Rs2PJWcNaa1NjbujRZsabbV/1rBlTqQf13U2oF3O0QVe3/Z1U+npQHslja+oe/zidYWGPkK+78DNx22hvCH3u0v4Kljwj3fo2Ld15Wv7ERgAiWQY8LaTTigGAnmlnmzEbgOEKUosI9YJid4U4O6ysHWV7SF8guk9XxurBW4fVyAFNqyJb97XJEhkGBXRPl+Ms2GF9dpn4zM0wAY3Cfqd7benP1stMiwOiqfBmYQ4v0Er7DuuoG1YsGd2VwJVwgpN62F+XlDczHJyc5jz0nl6JIEptJomS/w0UdUuaYcY+LGtQIqovs9Z82I0KKUrzjODs30pmAE+hwd2jdqi9fHPHnPAoZ9GhBBcrMr3eqjfN792G5G7fqz6InWbFFdDJuy1OQTJ6ADcZgsWrt3AG1yDFxdE9XqRXcPTeNREBoxgvcYAWhs3nRJZmO2ijXqe80kg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2SPR01MB0028.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(376002)(136003)(396003)(39860400002)(99936003)(2906002)(4326008)(186003)(7696005)(26005)(478600001)(86362001)(52536014)(3480700007)(5660300002)(6506007)(66476007)(64756008)(66616009)(71200400001)(66556008)(66946007)(66446008)(76116006)(6916009)(966005)(8676002)(8936002)(33656002)(166002)(316002)(9686003)(55016002)(83380400001)(43620500001)(15398625002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: tQ+kFbZ8ICnZw0H6zHBduEvp1p2LzBtQo1tr2rJq4KrLxnOCPvNM2DYE6gcgN8YUbdmdJnc6YmldIyH8OpJd8bOM1CHT1iJ+h27atbuXtpj0k7POF5njuKzXVYyo0b/O6BZ4LB23Dka6lHwwr9734jAhYn1q+S/P8MFa8mhkAjfxx15jwspCjmZ5QvHXfYEsKIgA2IMqd1mYGWAcWiopHlDCgIfCYLVpyGdDDf2yEtCmgHLUTZMoBR5xxmqig9vGCUnZgar28xk8gnJ+rJz/gSsHBbJQJ4F6YsfUEQodttEZDAzZMAGOa9dKGVyLQauC9mdij2VbZIYRb8AC5c7KATfajQmVYBrwOo7XU2TgHwzaT9H8yQt0Q4HwNACv6KnQmc0RuV6qGCCP5tPZc87kpy+G0gu9X30cDCBq3JRV9P74vVdK9xbGDlwHv6JgBKsl+klYwm6k5bQN2/SSvyZnUuYk4+yZC2i2mP/+qerTdWCK3xZIL5RTfsv3CRz6gdOmJRXCw0cOajY5Gg6Q6MJUJ1DNqqPY0L+/vaLIZjZVKtuxajpGTGczZ98Z0iAELQdk0KuhiNRAA2yQN6Sipodvj+Cio0W20iTpDFH8+A3bZspuqXUgLZk/S/isuOiwFNqd0Acz5YtRHPLk7SdP8BrHqg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01F9_01D69035.E0A4C710"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW2SPR01MB0028.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7cf0e5a8-fbee-49ed-c129-08d85e6ec776
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 20:41:55.7368 (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: r6b8YMsbPAOoh3lDgrxGvwPOQjqmtKmDF8E7PWt+YrQ6ewlbREPEwLOm5zdJ3npO
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3662
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/6VLRljm0g4IIns5hor9kx8jNxlg>
Subject: Re: [Rats] Questions about latest PRs
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: Mon, 21 Sep 2020 20:42:05 -0000

Hello Bin Cao,

 

Thanks for the comments, some thoughts in-line...

 

From: caobin (A), September 19, 2020 5:53 AM



Hi authors,

 

I've noticed the changes of CHARRA YANG module on the GitHub. Here I have
some comments:

 

1. The 'TPM_PCR_COMPOSITE' in the output of RPC
tpm12-challenge-response-attestation and the 'TPMS_QUOTE_INFO' in the output
of RPC tpm20-challenge-response-attestation are capitalized while other
elements are not. Is there a special reason?

 

<eric> The capitalization of TPMS_QUOTE_INFO emphasizes that this objects
are identical to objects from the corresponding TCG specs.  I.e.:

https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-
Structures-01.38.pdf

Section 10.12.1  "TPMS_QUOTE_INFO".

 

The capitalization of TPM_PCR_COMPOSITE is not so straight-forward however.
It is true that is includes the objects from TPM_PCR_COMPOSITE. See Section
8.2 of: 

https://trustedcomputinggroup.org/wp-content/uploads/mainP2Structrev103.pdf

However there is not a binary equivalency between the two.   For that
reason, the object should not be capitalized.

 

Stepping back, I think that the TPM1.2 response (and TPM2.0 response) could
be simplified even more.    Initially the PCR indexes and values were broken
out for a variety of reasons on the mailing list such as on-change
(RFC-8641) YANG subscription (even those these nodes are associated with
RPC...).     However draft-birkholz-rats-network-device-subscription now
suggests that RFC-8639 Event subscription is a better match than RFC-8641
YANG subscription.

 

As a result, I believe that parsing YANG objects from TPM_PCR_COMPOSITE.
Let me start a thread on that.

 

 

2. I see in the output there are node-id and node-physical-index, which
makes me wonder whether containing TPM's name and location info in the input
and output can make the implementation simpler. I want to discuss my
thoughts more.

I think a better method is containing 'tpm-name' and 'node-id' in the input
part and containing 'tpm-name', 'node-id', and 'certificate-name' in the
output part. 

 

<eric> As certificate-name always uniquely identifies tpm-name and node-id,
including these two items introduces both redundancy in the message, and
error conditions which would need to be checked.   

 

The reasons are below:

a) By making the 'tpm-name' and 'node-id' optional or visible only when two
and more TPMs exist, this method doesn't bring complexity to the devices
which only have one TPM.

 

<eric>  IMHO there are the drawbacks of redundancy in the message, extra
fields and error checks.  So you get a more complex API with little benefit.


 

b) For the devices which have two and more TPMs, by making the TPM's
location info explicit in the challenge input, the Attester's control plane
can directly find the TPM being challenged and it doesn't need to store and
maintain the relationship among tpm-name, compute-node, and
certificate-name.

 

<eric> Having the Verifier know the relationship between the compute node
and the certificates, but the Attester doesn't need to know/enforce
relationship within its own box seems backwards.   

 

c) This method has less exception scenarios to consider. In this method, if
the Verifier doesn't recognize the certificate-name in the output, it just
needs to retrieve this certificate again. In current method, if the TPM's
certificate changed, the exception scenarios include the Attester's control
plane may can't recognize the certificate-name, the Verifier may can't
recognize the certificate-name, etc. Implementers may not be able to think
through all of these exception scenarios.

 

<eric> YANG was designed around maintaining the consistency of the managed
device.  I believe it easier/simpler for an Attester to maintain its own
internal consistency rather for (many?) external verifiers to do this. 

 

3. For the log-retrieve RPC, it uses tpm-name in its input and output and is
different from the TPM1.2 and TPM2.0 challenge-response-attestation RPCs.
This also makes me feel a little weird that the TPM being challenged in the
attestation RPCs is not identified by TPM's name.

 

<eric> It does initially seem strange, but there is a some logic here.  

*	The logs entries don't need to be tied to a TPM certificate.
(PCRs are not the same as they are signed.)
*	Looking at the Charra datastore nodes, if you have the
certificate-name, you know the TPM-name.  
*	Plus the logs can continuously be stored even during a certificate
change.

 

And on why the tpm-name can appear in input and output for log-retrieval:

*	If no tpm-name appears in the RPC input, all TPMs are assumed
*	For the output, you need to understand which set of logs belongs to
each TPM.

 

Eric

 

Bin Cao 

caobin8@huawei.com <mailto:caobin8@huawei.com> 

+8613347737317