Subject: [Rats] Questions about latest PRs

From: "caobin (A)" <[email-masked]>
Date: Sat, 19 Sep 2020 09:52:33 +0000

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?

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

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.

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.

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.

Bin Cao
[email-masked]
+8613347737317

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 21 Sep 2020 20:41:55 +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 

[email-masked] <mailto:[email-masked]> 

+8613347737317