Subject: [Rats] Comments on the changes of CHARRA YANG module

From: "Panwei (William)" <[email-masked]>
Date: Fri, 10 Jul 2020 10:38:52 +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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 14 Jul 2020 11:45:52 +0000

Including the 'rats' alias.  I missed this in the original response...

-----Original Message-----
From: Eric Voit (evoit) 
Sent: Friday, July 10, 2020 11:24 AM
To: Panwei (William) <[email-masked]>
Cc: [email-masked]
Subject: RE: Comments on the changes of CHARRA YANG module

Hi Wei Pan,

Thanks for the comments.  Some thoughts in-line...

> From: Panwei (William), July 10, 2020 6:39 AM
> 
> 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:

It seems like it would be good to add some text which explains common
operations outside of the YANG model.   I will propose some text to the
draft based on your thoughts lower in the thread.  

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

Yes.  A large benefit we don't send redundant information in a continuous
set of RPC replies.    And by sending the certificate as the unique
identifier, it becomes easy to handle certificate upgrades, as when you see
a new certificate being used, you then can retrieve the information from the
Attester.

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

The absence of either should result in the acquisition of PCR information
for all physical TPMs.  This is a benefit from the previous version where we
explicitly had a 'tpm-name' of 'ALL'.  That is the purpose of the YANG model
text:

        "Name of one or more unique TPMs on a device.  If this object
exists,
        a selection should pull only the objects related to these TPM(s).
If
        it does not exist, all qualifying TPMs that are 'hardware-based'
        equals true on the device are selected.";

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

This is correct.

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

With the current version, this is not the case.  (As there is not a required
key of 'tpm-name' mandatory in the RPC.)

What needs to happen is that there is a secure method of provisioning on the
certificate on the Verifier.  And if you receive an unknown certificate, you
have a choice of how to then acquire that information.   The current YANG
model points to ' ietf-keystore.yang' as a potential place to get that
information.

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

Yes.  And this could be a random system generated string.  It cannot be a
TPM path, as this could change on a reboot.

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

The certificate-name should be unique within a Attester.  I will add that as
a constraint to the YANG model via XPATH.  Good catch, I had not explicitly
said this is required.

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

I agree.  In fact, I would argue that you should not allow both
'key-identifier' and 'tpm-name*' in the same query.  What happen if they
conflict?   If you agree, we could make an explicitly choice allowing either
one or the other.  

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

I assert this is a very large benefit.  You do not have to identify the key
at all in the query.
 
> 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. 

'tpm-name' is an internal structure to the Attester, and need not be used by
the Verifier where there is only one TPM.  This is a significant benefit of
getting rid of the key.   And for implementations with only one TPM, life is
much simpler.

> Two
> advantages would be: easier for readers to understand, the Verifier
doesn't
> need to search the database to find out the matched TPM.

There is another simplifying advantage of the current structure.  When a
certificate changes, you then can simply fetch the corresponding tpm info
from the datastore.  Certificate management/upgrades should become easier.

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

On "supported-algos":  an operator might want to limit the universe of
supported-algos from the full set which might be available from a vendor.

On "certificates":  YANG has some structural issues with how config data can
be exposed.  I believe that an Attesting device should allow new
certificates to be provisioned in a place like ' ietf-keystore.yang'.
However I am not sure if YANG allows non-config leafrefs to point to
configuration data.  I get an error if I try to make these objects system
generated.  Any suggestions on how automatically update things here?  I do
know there are implications to NMDA (RFC-8342).

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

I believe these can be removed.  Perhaps we can ask everyone during the IETF
session if they have any objections?

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

Agree.   The answer to the above question should be true here as well.

Thanks!
Eric