Re: [Rats] Questions about latest PRs

"caobin (A)" <caobin8@huawei.com> Thu, 15 October 2020 13:35 UTC

Return-Path: <caobin8@huawei.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 38DB63A09E4 for <rats@ietfa.amsl.com>; Thu, 15 Oct 2020 06:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 rEF44jlTncS7 for <rats@ietfa.amsl.com>; Thu, 15 Oct 2020 06:35:16 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096FA3A09DE for <rats@ietf.org>; Thu, 15 Oct 2020 06:35:16 -0700 (PDT)
Received: from lhreml737-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0EB9DA2E67630FC7C7F9 for <rats@ietf.org>; Thu, 15 Oct 2020 14:35:14 +0100 (IST)
Received: from lhreml737-chm.china.huawei.com (10.201.108.187) by lhreml737-chm.china.huawei.com (10.201.108.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 14:35:13 +0100
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml737-chm.china.huawei.com (10.201.108.187) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 15 Oct 2020 14:35:13 +0100
Received: from DGGEML509-MBX.china.huawei.com ([169.254.1.154]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Thu, 15 Oct 2020 21:35:07 +0800
From: "caobin (A)" <caobin8@huawei.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Questions about latest PRs
Thread-Index: AdaOaksiGF1CuGPiRouIEBaLBIr2nABzXWSgAbG2wXA=
Date: Thu, 15 Oct 2020 13:35:08 +0000
Message-ID: <F0C5D68C1C185E479EEED366166A9E1909E4960B@dggeml509-mbx.china.huawei.com>
References: <F0C5D68C1C185E479EEED366166A9E1909E2B140@dggeml529-mbx.china.huawei.com> <MW2SPR01MB002858B3733C6E29E74430A2A13A0@MW2SPR01MB0028.namprd11.prod.outlook.com>
In-Reply-To: <MW2SPR01MB002858B3733C6E29E74430A2A13A0@MW2SPR01MB0028.namprd11.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.85.169]
Content-Type: multipart/alternative; boundary="_000_F0C5D68C1C185E479EEED366166A9E1909E4960Bdggeml509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/eSYEfy_vpWZwLDVqUCnIAv7NXIA>
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: Thu, 15 Oct 2020 13:35:19 -0000

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.



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.



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?



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.



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).



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>
Cc: 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

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