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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 4 Aug 2020 17:28:58 +0000

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:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, August 4, 2020 12:42 AM
To: Panwei (William) <[email-masked]
<mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
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:certif
icate/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

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 19 Aug 2020 07:29:42 +0000

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:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, August 5, 2020 1:29 AM
To: Panwei (William) <[email-masked]>; [email-masked]
Cc: [email-masked]
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.

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:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, August 4, 2020 12:42 AM
To: Panwei (William) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
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.

<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