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

["Panwei (William)" <[e-mail]>]

Hi Eric,

I'm forwarding this thread to the rats mailing list.

Other comments but the below one are discussed in the other thread. 

> This is not a problem, the question is then do we make this a case
> statement, or use XPATH.   Either one works.  Do you want to propose the
> YANG model change?

Sure, I can propose a change in the github.

Regards & Thanks!

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:[e-mail]]
> Sent: Tuesday, August 4, 2020 12:54 AM
> To: Panwei (William) <[e-mail]>;
> [e-mail]
> Cc: [e-mail]
> Subject: RE: Comments on the changes of CHARRA YANG module
> 
> Hi Wei Pan,
> 
> > Hi Eric,
> >
> > Thanks for your reply, and sorry for my late reply, please see inline.
> >
> > Regards & Thanks!
> > Wei Pan
> >
> > > -----Original Message-----
> > > From: Eric Voit (evoit) [mailto:[e-mail]]
> > > Sent: Friday, July 10, 2020 11:24 PM
> > > 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.
> >
> > Thanks.
> >
> > > > 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.
> >
> > I agree with the design that sending the certificate identifier instead of
> the
> > actual certificate. As I explained in another email, I just suggest that
> adding the
> > tpm-name as the key.
> 
> We can work that one in the other thread.
> 
> > > > 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.";
> >
> > Yes, agreed.
> >
> > > > 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.
> >
> > If so, what's the purpose of the certificates in rats-support-structures?
> I assume
> > to use this module to get the certificates.
> 
> You need to store much common info about certificate (in the keystore
> draft), but you also need to know which TPM has what certificates (and this
> given to you by the <certificate-ref>).  Additionally different certificates
> might have different purposes with a TPM (here you populate
> <certificate-type>).
> 
> > > > 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.
> >
> > I'd like to say that if you using the tpm-name as the key for the output,
> there is
> > no need to require the certificate-name to be unique within a Attester.
> 
> See other thread.
> 
> > > > 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.
> >
> > Agree, a choice is much better.
> 
> This is not a problem, the question is then do we make this a case
> statement, or use XPATH.   Either one works.  Do you want to propose the
> YANG model change?
> 
> > > > 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.
> >
> > As I explained in another email, I feel like that adding the 'tpm-name' in
> the
> > output is useful, even if it is not used as the key.
> 
> Let's work this on the other thread.
> 
> > > > 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.
> >
> > But in current design, you need to fetch all TPMs info of an Attester. If
> the
> > output contains the tpm-name, you can only fetch this specific TPM info.
> 
> This is not correct.  You can fetch based on the <certificate-name>.
> 
> > > > 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?
> >
> > I also agree to remove these elements.
> 
> Thanks.  I have added the other authors to see if they have any issue with
> this?
> 
> Eric
> 
> 
> > > > 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