Subject: Re: [Rats] Charra: certificate-name vs TPM-name

From: "Panwei (William)" <[email-masked]>
Date: Sun, 2 Aug 2020 14:01:40 +0000

Hi Eric,

I don't object to contain the certificate-name in the response, I just suggest to add the tpm-name in the response and use it as the key.
I don't believe that one TPM per router/switch is enough. From the security perspective, I think one TPM per line card is needed, or at least using more TPMs is the trend. So the YANG module should consider the forward compatibility.
By using the tpm-name as the key of the output (and containing the certificate-name in the output), there are several advantages:
1) It's easy for the readers to understand.
2) It's easy for the Verifier to distinguish which TPM each record corresponds to and which certificate that TPM uses.
3) If the re-keying happens and a new certificate-name is provided to the Verifier, the Verifier only needs to query the Attester about the certificates of the specific TPM and doesn't need to retrieve the certificates of all TPMs.
4) While using different TPM names is already required, this approach doesn't further require to use different certificate names for different TPMs.

Regards & Thanks!
Wei Pan

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Tuesday, July 28, 2020 11:30 PM
To: Panwei (William) <[email-masked]>
Cc: [email-masked]
Subject: Charra: certificate-name vs TPM-name

Hi Wei Pan,

During the RATS WG call you wondered why certificate-name should be used rather than tpm-name.  There are two reasons:

(1) In RFC places like:

      +---x tpm20-challenge-response-attestation {TPM20}?
         +--ro output
            +--ro tpm20-attestation-response* []
               +--ro certificate-name?           string
               +--ro quote?                              binary
               +--ro quote-signature              binary

if just the tpm-name is provided, how does a Verifier know when a re-keying happens?    With the current solution, when unknown certificate-name comes back from the RPC, you just need to query:

    +--rw rats-support-structures
       +--rw tpms* [tpm-name]
          +--rw tpm-name                     string
          +--rw certificates
             +--rw certificate* [certificate-name]
                +--rw certificate-name    string
                +--rw certificate-ref?    leafref
                +--rw certificate-type?   enumeration

and then you can find the tpm-name, plus all the required info post-certificate upgrade in one place.  If the certificate-name is not in the RPC, a Verifier will have to make several guesses on what any failure of signature verification might mean.

(2) The most common implementations will have just one TPM per router/switch.  These implementations might never care about the tpm-name.  They will care about the certificate used on that router/switch.

Thanks,
Eric

Eric Voit
.:|:.:|:. Cisco Systems, Inc.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 3 Aug 2020 16:41:52 +0000

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

Below are some extensive thoughts on both options.  In the end I really am
fine with both.

To start with, I believe some useful context comes from the
ietf-keystore.yang YANG model which is currently under WGLC as part of
draft-ietf-netconf-keystore-17.   Here the following structure can be used
to identify a unique certificate independent of any TPM:   

   module: ietf-keystore.yang
     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name                                    string
              +--rw certificates
                 +--rw certificate* [name]
                    +--rw name                      string

In this model, the certificate's name is accessed without any TPM
information.  The next level in the hierarchy is the key name.  Note that in
this model, certificate's <name> object different than currently in charra.
The charra leaf <certificate-ref> can point to that keystore:

              path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"

                 + "/ks:certificates/ks:certificate/ks:name";

This means we have access to all the certificate info which a keystore would
support.

More after your questions...

From: Panwei, August 2, 2020 10:02 AM

Hi Eric,

I don't object to contain the certificate-name in the response, I just
suggest to add the tpm-name in the response and use it as the key.

I don't believe that one TPM per router/switch is enough. From the security
perspective, I think one TPM per line card is needed, or at least using more
TPMs is the trend. So the YANG module should consider the forward
compatibility.

By using the tpm-name as the key of the output (and containing the
certificate-name in the output), there are several advantages:

<eric> I believe it harder.   You still need to make <certificate-name>
mandatory.   Otherwise you likely need to acquire and test multiple keys
from a keystore to find the right one.   

Note: by mandating the key of <tpm-name> in your proposal you are enforcing
that only one response using a single key from TPM may be included.  Perhaps
this is a good thing.  It is not a good thing if anyone ever wants to return
two tpm quotes using different TPM keys as part of the same RPC response.

2) It's easy for the Verifier to distinguish which TPM each record
corresponds to and which certificate that TPM uses.

<eric> In both cases you need to get to the key itself from a keystore.   A
certificate points to a key, which is associated with a particular TPM.  The
key is already required for validating the signature of returned results.

3) If the re-keying happens and a new certificate-name is provided to the
Verifier, the Verifier only needs to query the Attester about the
certificates of the specific TPM and doesn't need to retrieve the
certificates of all TPMs.

<eric> This is not required for the existing model.  All you need to do is a
get on the existing model with the provided <certificate-name>. 

4) While using different TPM names is already required, this approach
doesn't further require to use different certificate names for different
TPMs.

<eric> If we make <certificate-name> dependent on <tpm-name>, then we have
the nested keys which we are trying to avoid for those devices which only
have a single TPM.   The main question I see from above is whether making
the <certificate-name> (which is system generated) unique across TPMs.
Again I believe this is helpful for those devices with just one TPM.

Eric

Regards & Thanks!

Wei Pan

From: Eric Voit (evoit) [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Tuesday, July 28, 2020 11:30 PM
To: Panwei (William) < <mailto:[email-masked]>
[email-masked]>
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Charra: certificate-name vs TPM-name

Hi Wei Pan,

During the RATS WG call you wondered why certificate-name should be used
rather than tpm-name.  There are two reasons:

(1) In RFC places like:

         +--ro output

               +--ro quote?                              binary

if just the tpm-name is provided, how does a Verifier know when a re-keying
happens?    With the current solution, when unknown certificate-name comes
back from the RPC, you just need to query:

       +--rw tpms* [tpm-name]

          +--rw tpm-name                     string

          +--rw certificates

and then you can find the tpm-name, plus all the required info
post-certificate upgrade in one place.  If the certificate-name is not in
the RPC, a Verifier will have to make several guesses on what any failure of
signature verification might mean.

(2) The most common implementations will have just one TPM per
router/switch.  These implementations might never care about the tpm-name.
They will care about the certificate used on that router/switch.

Thanks,

Eric

Eric Voit

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 4 Aug 2020 05:18:22 +0000

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]>
Cc: [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.

But if adding the tpm-name in the response, there is no need to make the certificate-name unique across TPMs, and no need to consider other TPMs when naming a certificate.
This also won't complex single-TPM devices. Because for these devices, the tpm-name can be arbitrary, even using a NULL string may also be acceptable.

Below are some extensive thoughts on both options.  In the end I really am fine with both.

To start with, I believe some useful context comes from the ietf-keystore.yang YANG model which is currently under WGLC as part of draft-ietf-netconf-keystore-17.   Here the following structure can be used to identify a unique certificate independent of any TPM:

     +--rw keystore

        +--rw asymmetric-keys

              +--rw name                                    string

              +--rw certificates

                    +--rw name                      string
In this model, the certificate's name is accessed without any TPM information.  The next level in the hierarchy is the key name.  Note that in this model, certificate's <name> object different than currently in charra.   The charra leaf <certificate-ref> can point to that keystore:
              path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"
                 + "/ks:certificates/ks:certificate/ks:name";
This means we have access to all the certificate info which a keystore would support.

[Wei] Understood. There are 'certificate-name' and 'certificate-ref' in charra and there is certificate's 'name' in the keystore. The 'certificate-name' in charra can't be used to find the actual certificate, but the 'certificate-ref' should be used to find the matched certificate in the keystore. When the Verifier receives the response output, it first uses the certificate-name to search the local rats-support-structures database to find the corresponded TPM and get the certificate-ref, then it uses the certificate-ref to get the actual certificate in the keystore.

I don't object to contain the certificate-name in the response, I just suggest to add the tpm-name in the response and use it as the key.
I don't believe that one TPM per router/switch is enough. >From the security perspective, I think one TPM per line card is needed, or at least using more TPMs is the trend. So the YANG module should consider the forward compatibility.

<eric> I believe it harder.   You still need to make <certificate-name> mandatory.   Otherwise you likely need to acquire and test multiple keys from a keystore to find the right one.

[Wei] The <certificate-name> is also mandatory. But for the readers, they will firstly know which TPM this record matches with, and secondly know which certificate this TPM uses. I think this hierarchy is more logical for reading.

Note: by mandating the key of <tpm-name> in your proposal you are enforcing that only one response using a single key from TPM may be included.  Perhaps this is a good thing.  It is not a good thing if anyone ever wants to return two tpm quotes using different TPM keys as part of the same RPC response.

[Wei] I agree using the tpm-name as the key is not so necessary. Just adding the tpm-name into the response is enough.

<eric> In both cases you need to get to the key itself from a keystore.   A certificate points to a key, which is associated with a particular TPM.  The key is already required for validating the signature of returned results.

[Wei] Got it. The key is stored in the keystore. To get the key, the Verifier needs to use the <certificate-ref> to match against the certificate's <name> in the keystore. To get the <certificate-ref>, the Verifier needs to use the <certificate-name> in the response to match against the <certificate-name> in the rats-support-structures.

<eric> This is not required for the existing model.  All you need to do is a get on the existing model with the provided <certificate-name>.

[Wei] Yes, I figured it out after the twice thinking. But here requires the <certificate-name> to be unique across TPMs.

<eric> If we make <certificate-name> dependent on <tpm-name>, then we have the nested keys which we are trying to avoid for those devices which only have a single TPM.   The main question I see from above is whether making the <certificate-name> (which is system generated) unique across TPMs.   Again I believe this is helpful for those devices with just one TPM.

[Wei] Actually, I think my approach makes the <certificate-name> independent with the <tpm-name>. Because when you name a certificate within one TPM, you don't need to care about other TPMs to make the certificate-name unique across TPMs.
Previously, the module uses the <tpm-name> and <node-id> as the nested keys to identify the TPM, this is unnecessary for the devices which only have a single TPM. But this approach only uses the <tpm-name> to identify the TPM. The <tpm-name> may be a little redundant for the devices which only have a single TPM, but it's not harm, I think.

Eric

Regards & Thanks!
Wei Pan

From: Eric Voit (evoit) [mailto:[email-masked]]
Sent: Tuesday, July 28, 2020 11:30 PM
To: Panwei (William) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Charra: certificate-name vs TPM-name

Hi Wei Pan,

(1) In RFC places like:

Thanks,
Eric

Eric Voit

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 4 Aug 2020 16:13:56 +0000

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.

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,

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.

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

/Eric2