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

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

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

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:

   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.

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

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:
1) It's easy for the readers to understand.

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

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.

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

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

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

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.

[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:[e-mail]]
Sent: Tuesday, July 28, 2020 11:30 PM
To: Panwei (William) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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.