Re: [Rats] Questions about latest PRs

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

Hi Bin Cao,

 

I appreciate the thoughts.  More at <Eric2>

 

From: RATS <[e-mail]> On Behalf Of caobin (A)
Sent: Thursday, October 15, 2020 9:35 AM
To: Eric Voit (evoit) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Rats] Questions about latest PRs

 

Hello Eric,

 

Sorry for the late response, please see inline.

 

2. I see in the output there are node-id and node-physical-index, which
makes me wonder whether containing TPM's name and location info in the input
and output can make the implementation simpler. I want to discuss my
thoughts more.

I think a better method is containing 'tpm-name' and 'node-id' in the input
part and containing 'tpm-name', 'node-id', and 'certificate-name' in the
output part. 

 

<eric> As certificate-name always uniquely identifies tpm-name and node-id,
including these two items introduces both redundancy in the message, and
error conditions which would need to be checked.   

[Bin] Without the requirement of making the certificate-name unique to
identify tpm-name and node-id, there will be no such redundancy and less
error conditions.

<Eric2> Do you really want to allow a duplicate <certificate-name> on a
single platform?   This could be read as we allow a common attestation key
repeated on different line cards on a single platform.   I don't think this
is a good idea, a hacker could easily swap the quote output of one TPM on
one line card as associate it with another line card. 

 

In previous threads, we have talked about the downsides of requiring a
compound key to reference a specific TPM:

*	Most routers/switches don't have multiple line cards.  So forcing
the RPC to be more complex for the minority of devices should be avoided.
*	Forcing the <node-id> to be exposed means that it naturally act as a
compound key.

 

Note 1: your internal implementation can certainly use a compound key, if
you prefer.  There is nothing in the model which precludes this as the
underlying implementation.

 

Note 2: It is possible to define a YANG model XPATH constraint to eliminate
the error condition you reference by ensuring that no duplicate
<certificate-name> exists within the
/rats-support-structures/tpms/tpm/certificates/certificate/certificate-name.
If this is acceptable, I can propose such an XPATH for the model.

 

The reasons are below:

a) By making the 'tpm-name' and 'node-id' optional or visible only when two
and more TPMs exist, this method doesn't bring complexity to the devices
which only have one TPM.

 

<eric>  IMHO there are the drawbacks of redundancy in the message, extra
fields and error checks.  So you get a more complex API with little benefit.


[Bin] By requiring a unique certificate-name, I don't feel that the error
checks will be much less. And without this uniqueness requirement, there is
no redundancy in the message.

<Eric2> The RPC is more complex if the types of objects populated change
based on whether multiple line cards exist.  Also in the current solution,
the only error-check needed would be ensuring that no duplicate
<certificate-name> exists on write.  And this error check can be skipped
when there is only one TPM (versus when there is a TPM per line card.)

 

b) For the devices which have two and more TPMs, by making the TPM's
location info explicit in the challenge input, the Attester's control plane
can directly find the TPM being challenged and it doesn't need to store and
maintain the relationship among tpm-name, compute-node, and
certificate-name.

 

<eric> Having the Verifier know the relationship between the compute node
and the certificates, but the Attester doesn't need to know/enforce
relationship within its own box seems backwards.   

[Bin] The Attester definitely can know the relationship, but it can have
less processes by knowing the compute-node directly from the message. If it
can be simpler why not?

<Eric2> Yes the Attester must know these relationships.  But the Verifier
shouldn't necessarily trust the non-signed parts of Attester messages.
E.g., It would be a security risk to depend on the Attesting Router to be
the undisputed source of which TPMs are on which line card.

 

c) This method has less exception scenarios to consider. In this method, if
the Verifier doesn't recognize the certificate-name in the output, it just
needs to retrieve this certificate again. In current method, if the TPM's
certificate changed, the exception scenarios include the Attester's control
plane may can't recognize the certificate-name, the Verifier may can't
recognize the certificate-name, etc. Implementers may not be able to think
through all of these exception scenarios.

 

<eric> YANG was designed around maintaining the consistency of the managed
device.  I believe it easier/simpler for an Attester to maintain its own
internal consistency rather for (many?) external verifiers to do this. 

[Bin] The Attester can maintain the consistency. But if it can do less
processes by the way of having the tpm-name and node-id in the input, why
don't do that and choose a way which has more processes.

<Eric2> Hopefully the answer to this is address in the other responses above
(i.e., single TPM devices and minimized RPC complexity.)

 

3. For the log-retrieve RPC, it uses tpm-name in its input and output and is
different from the TPM1.2 and TPM2.0 challenge-response-attestation RPCs.
This also makes me feel a little weird that the TPM being challenged in the
attestation RPCs is not identified by TPM's name.

 

<eric> It does initially seem strange, but there is a some logic here.  

*	The logs entries don't need to be tied to a TPM certificate.
(PCRs are not the same as they are signed.)
*	Looking at the Charra datastore nodes, if you have the
certificate-name, you know the TPM-name.  
*	Plus the logs can continuously be stored even during a certificate
change.

 

And on why the tpm-name can appear in input and output for log-retrieval:

*	If no tpm-name appears in the RPC input, all TPMs are assumed
*	For the output, you need to understand which set of logs belongs to
each TPM.

[Bin] The tpm-name can be used in the log-retrieve RPC to identify the input
and output, so the attestation RPCs can also include the tpm-name (and
node-id).

<Eric2> The tpm-name is in the log-retrieval RPC.  This is the only option
to identify specific TPMs, so there is no redundancy.  Right now there is
only certificate-name for the attestation RPCs, there is no redundancy.
If we allowed certificate-name or tpm-name or node-id, there are redundant
choices which make the RPC far more expensive to implement.  Additionally,
are combinations of each of these objects allowed?  And which combinations?
BTW: I see no problem in having vendor specific augmentations allowing
tpm-name or node-id in the attestation RPC.  I just am trying to make the
standard implementation as simple as possible while maintaining coverage for
both single TPM and multiple TPM platforms.

 

Thanks,

Eric

 

Thanks!

Bin Cao

 

From: Eric Voit (evoit) [mailto:[e-mail]] 
Sent: Tuesday, September 22, 2020 4:42 AM
To: caobin (A) <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
Subject: RE: Questions about latest PRs

 

Hello Bin Cao,

 

Thanks for the comments, some thoughts in-line...

 

From: caobin (A), September 19, 2020 5:53 AM

Hi authors,

 

I've noticed the changes of CHARRA YANG module on the GitHub. Here I have
some comments:

 

1. The 'TPM_PCR_COMPOSITE' in the output of RPC
tpm12-challenge-response-attestation and the 'TPMS_QUOTE_INFO' in the output
of RPC tpm20-challenge-response-attestation are capitalized while other
elements are not. Is there a special reason?

 

<eric> The capitalization of TPMS_QUOTE_INFO emphasizes that this objects
are identical to objects from the corresponding TCG specs.  I.e.:

 
<https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2
-Structures-01.38.pdf>
https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-
Structures-01.38.pdf

Section 10.12.1  "TPMS_QUOTE_INFO".

 

The capitalization of TPM_PCR_COMPOSITE is not so straight-forward however.
It is true that is includes the objects from TPM_PCR_COMPOSITE. See Section
8.2 of: 

 
<https://trustedcomputinggroup.org/wp-content/uploads/mainP2Structrev103.pdf
>
https://trustedcomputinggroup.org/wp-content/uploads/mainP2Structrev103.pdf

However there is not a binary equivalency between the two.   For that
reason, the object should not be capitalized.

 

Stepping back, I think that the TPM1.2 response (and TPM2.0 response) could
be simplified even more.    Initially the PCR indexes and values were broken
out for a variety of reasons on the mailing list such as on-change
(RFC-8641) YANG subscription (even those these nodes are associated with
RPC...).     However draft-birkholz-rats-network-device-subscription now
suggests that RFC-8639 Event subscription is a better match than RFC-8641
YANG subscription.

 

As a result, I believe that parsing YANG objects from TPM_PCR_COMPOSITE.
Let me start a thread on that.

 

 

2. I see in the output there are node-id and node-physical-index, which
makes me wonder whether containing TPM's name and location info in the input
and output can make the implementation simpler. I want to discuss my
thoughts more.

I think a better method is containing 'tpm-name' and 'node-id' in the input
part and containing 'tpm-name', 'node-id', and 'certificate-name' in the
output part. 

 

<eric> As certificate-name always uniquely identifies tpm-name and node-id,
including these two items introduces both redundancy in the message, and
error conditions which would need to be checked.   

 

The reasons are below:

a) By making the 'tpm-name' and 'node-id' optional or visible only when two
and more TPMs exist, this method doesn't bring complexity to the devices
which only have one TPM.

 

<eric>  IMHO there are the drawbacks of redundancy in the message, extra
fields and error checks.  So you get a more complex API with little benefit.


 

b) For the devices which have two and more TPMs, by making the TPM's
location info explicit in the challenge input, the Attester's control plane
can directly find the TPM being challenged and it doesn't need to store and
maintain the relationship among tpm-name, compute-node, and
certificate-name.

 

<eric> Having the Verifier know the relationship between the compute node
and the certificates, but the Attester doesn't need to know/enforce
relationship within its own box seems backwards.   

 

c) This method has less exception scenarios to consider. In this method, if
the Verifier doesn't recognize the certificate-name in the output, it just
needs to retrieve this certificate again. In current method, if the TPM's
certificate changed, the exception scenarios include the Attester's control
plane may can't recognize the certificate-name, the Verifier may can't
recognize the certificate-name, etc. Implementers may not be able to think
through all of these exception scenarios.

 

<eric> YANG was designed around maintaining the consistency of the managed
device.  I believe it easier/simpler for an Attester to maintain its own
internal consistency rather for (many?) external verifiers to do this. 

 

3. For the log-retrieve RPC, it uses tpm-name in its input and output and is
different from the TPM1.2 and TPM2.0 challenge-response-attestation RPCs.
This also makes me feel a little weird that the TPM being challenged in the
attestation RPCs is not identified by TPM's name.

 

<eric> It does initially seem strange, but there is a some logic here.  

*	The logs entries don't need to be tied to a TPM certificate.
(PCRs are not the same as they are signed.)
*	Looking at the Charra datastore nodes, if you have the
certificate-name, you know the TPM-name.  
*	Plus the logs can continuously be stored even during a certificate
change.

 

And on why the tpm-name can appear in input and output for log-retrieval:

*	If no tpm-name appears in the RPC input, all TPMs are assumed
*	For the output, you need to understand which set of logs belongs to
each TPM.

 

Eric

 

Bin Cao 

 <mailto:[e-mail]> [e-mail]

[phone]