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

["Eric Voit (evoit)" <[e-mail]>]

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:

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.   

 

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