Re: [Rats] Multi-line card? (was RE: Charra: certificate-name vs TPM-name)

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

Hi Eric,

I agree with you, I also didn't intend to bring the topic of the relationships/roles between TPMs into CHARRA. What I've tried is to make the model easy to understand and to augment in the future.

I don't object to adding a constraint to limit the <tpm-name> in the RPC output. But if you think it is tricky and it may not clear to see the potential problems, then I suggest we don't need to add such constraints.
The <tpm-name> is a mandatory and key node in the datastore rats-support-structure. So you can see, even for the devices with only one TPM, the TPM should be given a name. Then adding this <tpm-name> into the RPC output isn't an extra complicated thing.
If you are very concerned about the devices with only one TPM, I think maybe we can just set <tpm-name> to an optional node, this is easy to do and the devices with only one TPM can just omit this node.

Regards & Thanks!

From: RATS [mailto:[e-mail]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 5, 2020 1:29 AM
To: Panwei (William) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: [Rats] Multi-line card? (was RE: Charra: certificate-name vs TPM-name)

Hi Wei Pan,

I didn't want to couple the general Multi-line card topic you have been advocating in the architecture draft with the charra RPC response structures.  But they are related.

One of the things not currently in the scope of Charra are the roles and relationships between redundant supervisor cards and line cards.  As you have pointed out, each of these cards might have their own TPM.  As was thinking about the issue below, I considered adding a constraint to the RPC output list which would limit including <tpm-name> in the RPC to only those times when there were two or more <tpm-name> instantiated in the configuration datastore nodes.  (This should be fine as we agree <tpm-name> need not be a key object.)

Opening up the discussion into such constraints needs to be done carefully as they have the potential to limit future solutions to how to structure roles/relationships between TPMs.  I don't think that this is a topic ready to bring into charra as we are trying to get it to WGLC.  But at some point we will need draft which defines how  to securely advertise/discover the relationships between multiple line cards and supervisors.  I.e., if a Verifier has a certificate for a supervisor, can information stored in that supervisor's TPM can safely expose the relationships between TPMs in that device?  How do you refresh this view when the line cards in a device change.  This is a worthwhile problem to solve.

Eric

Hi Wei Pan,

Below I cut the thread to the last bit of difference.  I think we agree on everything else.

From: Panwei (William), August 4, 2020 1:18 AM
Hi Eric,

Thanks for your reply. After a twice thinking, I realize it's true that the difference between our proposals is that whether to contain <tpm-name> in the response and whether to make <certificate-name> unique across different TPMs.
Some thoughts please see inline.

Regards & Thanks!
Wei Pan

From: RATS [mailto:[e-mail]] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, August 4, 2020 12:42 AM
To: Panwei (William) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] Charra: certificate-name vs TPM-name

Hi Wei Pan,

I fully agree that multiple line cards per switch/router is necessary. The current model does support this, as the RPC output is a list.  Lists are identified by the "[]" in the tree diagram.   So for any current list entry, a <certificate-name> which is unique to an individual TPM can be placed within this list.

The real difference I see between our proposals is that you want <tpm-name> explicitly listed in the RPC response,

[Wei] Indeed.

and I thought a unique <certificate-name> which doesn't require users of single TPM devices to understand <tpm-name> is preferable.  I.e., some complexity is hidden within the router so that a class of developers need not care.

[Wei] But I think some new complexities for multi-TPM devices have also emerged.
The first complexity is that the certificate name should be unique across TPMs.
Imagine this case: there are two TPMs and each one has a certificate, e.g., tpmA's certificate is cert1 and tpmB's certificate is cert2. When tpmA changes its certificate, it releases the name 'cert1' and names the new certificate 'cert3'. Right after that tpmB changes its certificate, and names the new certificate 'cert1' because 'cert1' is unique right now. But you can see a potential problem here, if the Verifier receives the attestation response before receiving the updates of the certificates, it will wrongly match the record according to the certificate-name, as it doesn't know the owner of 'cert1' is changed. Although the Verifier will fail to verify the signature, but it doesn't know what's the real problem.
So, the second complexity is that the certificate name should not be reused by other TPMs.
There may be other complexities that I didn't come up with.

<eric2> If the charra model's <certificate-name> were populated with something like "cert1", I would absolutely agree with you.   But that is not what I am proposing.

Stepping back, perhaps the conventions used for YANG object naming are causing some mis-communications here.

In the example below, use:

  *   "ks" as the prefix for ietf-keystore.yang
  *   "tpm" as the prefix for charra


<tpm:certificate-ref> points to an instance of
 "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/ks:certificates/ks:certificate/ks:name"

It is over in ietf-keystore.yang, you would have that <ks:name> be something human readable like "cert1".  But we likely wouldn't want two human readable names for the same certificate in different yang models.

Looking back at the path from ietf-keystore.yang, you can see that there is no TPM differentiator in that YANG datastore for asymmetric keys.  In other words the primary repository for asymmetric-key information does not use anything like <tpm:tpm-name> as part of its key.  This is why I believe that <tpm:certificate-name> is best system generated, and need not be human readable.  So what I would do in implementation for <tpm:certificate-name> is to populate it with the value of "/ks:asymmetric-key/ks:name" appended with the value of "/ks:asymmetric-key/ks:certificates/ks:certificate/ks:name".  This long a string isn't necessary, but it works and requires no additional human configuration.  Other protections could be put into place as well, such as an XPATH constraint on <tpm:certificate-name> so that it is never the same as "../../tpm:tpm-name/tpm:certificate-name".

Again, I wouldn't be overly upset if the WG did have a preference for the nested key option of <tpm:tpm-name> and <tpm:certificate-name>.  It is less efficient, and exposes extra complexity to the receiver (nested identifiers and the need for single TPM devices to expose a TPM-name).  But it has the benefit of being simple to understand.

<Eric3>   How about add a XPATH constraint on <tpm:tpm-name> within the RPC to allow the inclusion of this object when

/Eric2