[Rats] Comments on the changes of CHARRA YANG module

"Panwei (William)" <william.panwei@huawei.com> Fri, 10 July 2020 10:39 UTC

Return-Path: <william.panwei@huawei.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 454483A0898 for <rats@ietfa.amsl.com>; Fri, 10 Jul 2020 03:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XdQ__ivDGC9A for <rats@ietfa.amsl.com>; Fri, 10 Jul 2020 03:39:08 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 6A1EB3A0896 for <rats@ietf.org>; Fri, 10 Jul 2020 03:39:08 -0700 (PDT)
Received: from lhreml742-chm.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 3986A930FD2436C8B7D1 for <rats@ietf.org>; Fri, 10 Jul 2020 11:39:06 +0100 (IST)
Received: from nkgeml706-chm.china.huawei.com ( by lhreml742-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 10 Jul 2020 11:39:05 +0100
Received: from nkgeml705-chm.china.huawei.com ( by nkgeml706-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 10 Jul 2020 18:38:52 +0800
Received: from nkgeml705-chm.china.huawei.com ([]) by nkgeml705-chm.china.huawei.com ([]) with mapi id 15.01.1913.007; Fri, 10 Jul 2020 18:38:52 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Comments on the changes of CHARRA YANG module
Thread-Index: AdZWpd3aUHkm/3I1RKafnNj2CppmIw==
Date: Fri, 10 Jul 2020 10:38:52 +0000
Message-ID: <4e2e0b53d2be47009b1958758620914c@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4e2e0b53d2be47009b1958758620914chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/T4_8cdKEzCz7jRjojxFEQ-FFCmY>
Subject: [Rats] Comments on the changes of CHARRA YANG module
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, 10 Jul 2020 10:39:10 -0000

Hi Eric,

I've read the YANG modules you changed, actually I didn't get how the new modules worked when I read it the first time. After reading it a few times and discussion with others, I kind of figured out how it worked:

1.     The Verifier (or Relying Party) uses the "rats-support-structures" datastore structure to retrieve the hardware information, i.e., all the compute-nodes and all the TPMs, from the Attester. Then the Verifier can establish the relationship between the TPM and its compute-node info and certificates info. Further, the Verifier can identify the TPM according to the certificate-name and/or the compute-node.

2.     Next, the Verifier uses the RPC structures to get Evidence in a challenge-response fashion. In the challenge input, the Verifier can use the leaf "key-identifier" to ask Evidence of one specific TPM based on this TPM's unique credential, or it can use the leaf-list "tpm-name" to ask Evidence of one or more TPMs based on these TPMs' names.

3.     In the response output, the Attester returns the Evidence. If the input contains only one TPM, then the output can match that TPM anyway. But if the input contains several "tpm-name", then the output is a set of Evidence of these TPMs, in this situation, the Verifier needs to use the "certificate-name" and/or "node-id" in each Evidence to identify which TPM produced it.

If my understanding is right, then the YANG modules after changed have some assumptions which aren't explicitly said, I conclude them below:

1.     The Verifier must retrieve the datastore first before initiate the challenge request.

2.     Every TPM should have a unique name, at least be unique in an Attester.

3.     Every certificate should have a unique name. It should be unique in an Attester if the certificate-name can identify the TPM, or should be unique in a compute node if the certificate-name and the node-id are used together to identify the TPM.

4.     For the input, if you choose to use the "key-identifier", then the list-leaf "tpm-name" must have only one value.
My suggestion would be to have a section to describe the workflow or the example of how to use this YANG module. Also, explicitly pointing out the assumptions would be much better.

Generally, I agree with the idea that don't use nested keys to identify the TPM (and its position) in RPCs. This has a significant benefit of scalability. Because if in the future more dimensions are needed to identify the TPM (and its position), the RPC structures don't need to be changed, only modifying the datastore structure is enough. But the current RPCs also have a disadvantage that the key is very obscure and implicit, for example, you need to use "certificate-name" and "node-id" as the key in the output. I suggest that we can just use the "tpm-name" as the key of output. Two advantages would be: easier for readers to understand, the Verifier doesn't need to search the database to find out the matched TPM.

Other comments:

1.     Some elements in the "rats-support-structures" are changed from read-only to read-write, e.g., the "supported-algos" and "certificates" of TPM. Why these elements can be configured now?

2.     The outputs of RPC "tpm12-challenge-response-attestation" and "tpm20-challenge-response-attestation" contains the "node-id" and "node-physical-index". Can these two elements be omitted in the output? Because they can be get through the datastore.

3.     The output of RPC "log-retrieval" doesn't contain the "node-id" or "node-physical-index", and this is different with the outputs of other two RPCs. I wonder whether here is right and other two RPCs need to delete the two elements.

Regards & Thanks!
Wei Pan