Re: [Rats] Questions about latest PRs
"Eric Voit (evoit)" <evoit@cisco.com> Fri, 16 October 2020 18:49 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 54DDF3A07AE
for <rats@ietfa.amsl.com>; Fri, 16 Oct 2020 11:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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.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=V5tDSwKm;
dkim=fail (1024-bit key)
reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com
header.b=s7LMrHvP
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 FTYdYJCN21Ea for <rats@ietfa.amsl.com>;
Fri, 16 Oct 2020 11:49:32 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94])
(using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id AABF83A0799
for <rats@ietf.org>; Fri, 16 Oct 2020 11:49:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=cisco.com; i=@cisco.com; l=71415; q=dns/txt;
s=iport; t=1602874172; x=1604083772;
h=from:to:cc:subject:date:message-id:references:
in-reply-to:mime-version;
bh=EWsp65li2xG3F0ECvqIf2ArcYVqEu5+QYr+XKdVdahA=;
b=V5tDSwKmjqJPkHsrX/n+Lc6ZfYAUqS7EKDPRp5XYHG8BW7cncXqCnw6G
aCR9Vt8eD/lzVRa9+8/C1fAklrm/UhFho4Pmw/4dL25epRe3KVjajUQed
ymKc5fKv15jGLoZyX/mbWwfh3GMHk8pfWKWBLZjtabZyLQ1hNOlPMOhPZ M=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3A+dmR3RUSDoadkAPbOf9e4YXGRijV8LGuZFwc94?=
=?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyFufJZgvXbsubrXmlTqZqCsXVXdptKWl?=
=?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBomC78jMTXB?=
=?us-ascii?q?74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?=
=?us-ascii?q?3CpX4bdg=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DICgAL6olf/5ldJa1WCh4BAQsSDEC?=
=?us-ascii?q?Cci8pKAdwLC0vLAqHfAONS4dlji2CaIJTA1UEBwEBAQoDAQElCAIEAQGESgK?=
=?us-ascii?q?CCwIlOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEBAQISCBMTAQEsBAcBDwI?=
=?us-ascii?q?BCBEEAQEOEwEGBwIwFAkIAQEEDgUIBg0HgjlMOIFGTQMfDwEOo0MCgTmIaHS?=
=?us-ascii?q?BNIMEAQEFgTRRA4MaGIIJBwMGgTiBU4EfgmBMhxgbgUE/gRFDgk0+gXljA4E?=
=?us-ascii?q?oCS8FBwkWCQSDEIIskGOKJIEZikWRGQqCaoRNgl+BWJIOgxaKCIVHjmmeIpE?=
=?us-ascii?q?LhC4CBAIEBQIOAQEFgWsjgVdwFTuCaVAXAg2OH4NxhRSFQnQCAQEQJAIGCgE?=
=?us-ascii?q?BAwl8jDsBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.77,383,1596499200";
d="p7s'?scan'208,217";a="564604139"
Received: from rcdn-core-2.cisco.com ([173.37.93.153])
by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA;
16 Oct 2020 18:49:31 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14])
by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 09GInVFI025791
(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL);
Fri, 16 Oct 2020 18:49:31 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com
(173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2;
Fri, 16 Oct 2020 13:49:31 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com
(173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2;
Fri, 16 Oct 2020 13:49:30 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by
xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server
(TLS) id
15.0.1497.2 via Frontend Transport; Fri, 16 Oct 2020 14:49:30 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=le9fLZaHu44xXZNjN3nBcNj8rOBpDBKPwwMOvxh0A9voF1dcuk0CC6brGWrH+oSE9VQRGK8AohhwzXTEfKkcjns46H+TBV3D5J7g6Nf2SbHuZUCu8Mdl7g0d1oHlPw0FFLZtS7XqBfULLYvvsd6btuNp5pAgQDTYxFv8mXAVVkDJKjBGpeFDHevxhYbwtvo/UOPrD+Pgr6oeY8TImWqKKiwpypXu40hZ1aq9d+LnEW12aio3H8eHTSyGO8iLkttXjFvljXYnyc90FPMXsZReYyx8DY2f37ld1t/3nYS6uGCb1PbJaQsCRezvhjtTpt0dNDMd/h6HWQdrqagdLbaW0g==
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=OWjvRdfaGsWcvJrH1g4GfPeHvRg/ehYDJ61dtnk1Njs=;
b=QYvJPJFwKxwvWnd/T4L8KR/Oqp+6Cdr1qDAeEZfoCD5rwyycFqkBNwJTOJW8QVOF/OuUAui4mtIcclPn4Yhhv2HmxkypSfwGhjUdwgFNh9ojUZKi1rDb+6DORZO76qTXWDlR8DeLIqdv8EneZusSl159GEbMVu1TiUn/n9Og57luEVUpheb991D+aJZfTREuj/VYviXokEC5cjsuMUefMWmUZSNVPmutqxtBrX1/419jNxpFHkt9cJFrRB3S1+FBmK5ZtMeC3ITBY6Fui6JCuEqZ24rsEhy0wR5D5ELEzmAWBwNXqerDhe8FCI5GFEpfTVSYvMYtveVDIwObnCJsGQ==
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=OWjvRdfaGsWcvJrH1g4GfPeHvRg/ehYDJ61dtnk1Njs=;
b=s7LMrHvPAFZauiX3Wit2FiRDDyW4hUT0/8cQEHkubCXtZw7JLSB7xu9fvD7T/nguHoLhLPcrNy8cW77F7HTQoTiFKaMjS5ZhvaTRBXEWxB4hWPJbLQSrDHNoUQKcD5hAX1aLh+es+xxJjH+PcYmAdiMg+3H6RRe+ZWRMKsmUdUE=
Received: from SN6PR11MB3135.namprd11.prod.outlook.com (2603:10b6:805:d5::20)
by SN6PR11MB2800.namprd11.prod.outlook.com (2603:10b6:805:5b::15)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Fri, 16 Oct
2020 18:49:28 +0000
Received: from SN6PR11MB3135.namprd11.prod.outlook.com
([fe80::b819:72bd:80b2:d2e0]) by SN6PR11MB3135.namprd11.prod.outlook.com
([fe80::b819:72bd:80b2:d2e0%4]) with mapi id 15.20.3477.021; Fri, 16 Oct 2020
18:49:28 +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: AdaOaksiGF1CuGPiRouIEBaLBIr2nABzXWSgAbG2wXADAVVYYA==
Date: Fri, 16 Oct 2020 18:49:28 +0000
Message-ID: <SN6PR11MB3135ED3CD6F27DBDE9095B12A1030@SN6PR11MB3135.namprd11.prod.outlook.com>
References: <F0C5D68C1C185E479EEED366166A9E1909E2B140@dggeml529-mbx.china.huawei.com>
<MW2SPR01MB002858B3733C6E29E74430A2A13A0@MW2SPR01MB0028.namprd11.prod.outlook.com>
<F0C5D68C1C185E479EEED366166A9E1909E4960B@dggeml509-mbx.china.huawei.com>
In-Reply-To: <F0C5D68C1C185E479EEED366166A9E1909E4960B@dggeml509-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: [108.18.114.139]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 23903a1d-b72f-4e6c-73d8-08d8720435f0
x-ms-traffictypediagnostic: SN6PR11MB2800:
x-microsoft-antispam-prvs: <SN6PR11MB2800026CA0435E5229E44E5AA1030@SN6PR11MB2800.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: HUFRUfeStvC9kmVOruB3uxRRoQO8VrZrCERZYZWZcVWDzb3nBZIxegOZA14bNPjWAvokaS8UiI3/vQ21ajVkGex6fXdXr3t7YFARNsK6LRuqk3D+pCuvKUp7id0cQEVIfwh9yJA6wOcZhH/fDU44Q16QEjoDcYEWprxjriZQUKGaaB1g1gjSkYLmaMoebJTZzLel9u/NbUOJKqVQTkJNC/AgvMZsnNB6oR1Qv/UHw67epLPV/Ok1pw/+bOvco1ulZMrepn5ThCEd6gIU9UhG9oRLb1LkXZO/64TeKPv8SGMCN1up+le/4yXg0QzVuZfwbvP3AR+taWEuic6m9JMtFqGQz64qnLm6q6gCzA+5aX0ZVtjOLAmW1/pNrLVR746QozRiUf1oN9BPyp1zYOIub0SOCGZM5HT0JzOKY1XJT+LhUnmKzFnlFgJ1rkYRknNee1C2hx/9ei96Jgveogh272oM4rZNqC7f+Pt81YiCiNY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM;
H:SN6PR11MB3135.namprd11.prod.outlook.com; PTR:; CAT:NONE;
SFS:(396003)(346002)(39860400002)(366004)(376002)(136003)(316002)(478600001)(2906002)(6916009)(86362001)(99936003)(26005)(8936002)(33656002)(166002)(30864003)(9686003)(5660300002)(66476007)(8676002)(66556008)(66616009)(53546011)(52536014)(55016002)(966005)(66446008)(76116006)(83380400001)(66946007)(186003)(4326008)(7696005)(71200400001)(64756008)(6506007)(3480700007)(66574015)(43620500001)(15398625002)(579004)(559001);
DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 0WDrUl0nBXRSQI/EgdrlV6nSnPZ8X/afXkSHKUHt2lQtRH0JhcuL+Si/BCDb3mC7YtC55MhOwxmTpezOzMWplUp+mtTUAcgxOBmp8Q1IiTKvfvf4Qwv8OLa3iH6GrXHL1O6MwQTzW058x3Ro3nGvAizRg7aOIQ4lRs8jBjHwzl75f20J6AQL/qiPp2KCta4FVpsfrErAIp4LUxNhJ7ZWrGPTVDDFGTGAEgV1PuGtlPFWqnTU+fdCpXxP74JffYvRRRza7rxIidbSLZ244A5WCG5aC2DIfVPGw8D3XlktXNAqMTLnLspd6M0cPWmgeAE3fvovTnlTTpI9xoAcvow5iCRPEOuRnGEoC0rVw8bZbk5Ee/79EknKR1l40qPypbXTRGu/zuw+r26IFu0VeisIceXgcUCsYRechpjlJ10tFDKEXB3mKmPk1uvn7Sk1YIAMCoWrNPRdkaQxJ+sHQvLdJz1VboGcaW6Oogqf+hqSYsE5OLn4jA4sG990nasp9P/kNwxrjOqS9NfjSkyo+j2bFYMJJPUDWm+llzeTnunbThDg+nh1OG+dtKNTBh5Dj0DL+B7lQ2m6bo8p5bxXby/TpEbZtGN76GlP4AFfH30XHw1kMNWs+qL2v2vNesRHc6rSkOrGQTsySZUkgEjyt/4moQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed;
boundary="----=_NextPart_000_1C2A_01D6A3CB.86106BC0";
protocol="application/x-pkcs7-signature"; micalg=SHA1
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3135.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 23903a1d-b72f-4e6c-73d8-08d8720435f0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 18:49:28.1642 (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: KU/qo/CJRBiHRRmYSn22JNr6PVY6CiTFeIlqRm/MirvJnR/cIklvNmzmMFkziej4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2800
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/BO2dm4488jR-QUC1i6o39vNqAyI>
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: Fri, 16 Oct 2020 18:49:36 -0000
Hi Bin Cao, I appreciate the thoughts. More at <Eric2> From: RATS <rats-bounces@ietf.org> On Behalf Of caobin (A) Sent: Thursday, October 15, 2020 9:35 AM To: Eric Voit (evoit) <evoit@cisco.com> Cc: rats@ietf.org Subject: Re: [Rats] Questions about latest PRs Hello Eric, Sorry for the late response, please see inline. 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. [Bin] Without the requirement of making the certificate-name unique to identify tpm-name and node-id, there will be no such redundancy and less error conditions. <Eric2> Do you really want to allow a duplicate <certificate-name> on a single platform? This could be read as we allow a common attestation key repeated on different line cards on a single platform. I don't think this is a good idea, a hacker could easily swap the quote output of one TPM on one line card as associate it with another line card. In previous threads, we have talked about the downsides of requiring a compound key to reference a specific TPM: * Most routers/switches don't have multiple line cards. So forcing the RPC to be more complex for the minority of devices should be avoided. * Forcing the <node-id> to be exposed means that it naturally act as a compound key. Note 1: your internal implementation can certainly use a compound key, if you prefer. There is nothing in the model which precludes this as the underlying implementation. Note 2: It is possible to define a YANG model XPATH constraint to eliminate the error condition you reference by ensuring that no duplicate <certificate-name> exists within the /rats-support-structures/tpms/tpm/certificates/certificate/certificate-name. If this is acceptable, I can propose such an XPATH for the model. 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. [Bin] By requiring a unique certificate-name, I don't feel that the error checks will be much less. And without this uniqueness requirement, there is no redundancy in the message. <Eric2> The RPC is more complex if the types of objects populated change based on whether multiple line cards exist. Also in the current solution, the only error-check needed would be ensuring that no duplicate <certificate-name> exists on write. And this error check can be skipped when there is only one TPM (versus when there is a TPM per line card.) 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. [Bin] The Attester definitely can know the relationship, but it can have less processes by knowing the compute-node directly from the message. If it can be simpler why not? <Eric2> Yes the Attester must know these relationships. But the Verifier shouldn't necessarily trust the non-signed parts of Attester messages. E.g., It would be a security risk to depend on the Attesting Router to be the undisputed source of which TPMs are on which line card. 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. [Bin] The Attester can maintain the consistency. But if it can do less processes by the way of having the tpm-name and node-id in the input, why don't do that and choose a way which has more processes. <Eric2> Hopefully the answer to this is address in the other responses above (i.e., single TPM devices and minimized RPC complexity.) 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. [Bin] The tpm-name can be used in the log-retrieve RPC to identify the input and output, so the attestation RPCs can also include the tpm-name (and node-id). <Eric2> The tpm-name is in the log-retrieval RPC. This is the only option to identify specific TPMs, so there is no redundancy. Right now there is only certificate-name for the attestation RPCs, there is no redundancy. If we allowed certificate-name or tpm-name or node-id, there are redundant choices which make the RPC far more expensive to implement. Additionally, are combinations of each of these objects allowed? And which combinations? BTW: I see no problem in having vendor specific augmentations allowing tpm-name or node-id in the attestation RPC. I just am trying to make the standard implementation as simple as possible while maintaining coverage for both single TPM and multiple TPM platforms. Thanks, Eric Thanks! Bin Cao From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Tuesday, September 22, 2020 4:42 AM To: caobin (A) <caobin8@huawei.com <mailto:caobin8@huawei.com> > Cc: rats@ietf.org <mailto:rats@ietf.org> Subject: RE: Questions about latest PRs 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> 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 > 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 <mailto:caobin8@huawei.com> caobin8@huawei.com +8613347737317
- [Rats] Questions about latest PRs caobin (A)
- Re: [Rats] Questions about latest PRs Eric Voit (evoit)
- Re: [Rats] Questions about latest PRs caobin (A)
- Re: [Rats] Questions about latest PRs Eric Voit (evoit)