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

["Eric Voit (evoit)" <[e-mail]>]

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) <[e-mail]>
Cc: [e-mail]
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:
> 1. The Verifier must retrieve the datastore first before initiate the
> challenge request.

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

> Regards & Thanks!
> Wei Pan