Subject: [Rats] Comments on draft-voit-rats-trusted-path-routing-00:

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Wed, 4 Mar 2020 07:49:41 +0000

Hi Eric,
This draft is a good start in the direction about using remote attestation for the end to end path calculation. The other interesting point is describing the netconf pub/sub model for remote attestation.

As promised, I have reviewed the document and have some comments as below:

1.       About a formally defined trustworthiness level: I like it and think current definition may be not enough. In addition to "boot-verified, unverified and compromised", there may be more like: system-verified, system-unverified, "key file"/"key process"-verified, "key file"/"key process"-verified, key-safe, key-unsafe... I don't want to complicate the definition, but we may need to consider more, and their combination;

2.       About Backward compatibility: we must consider the case that some legacy devices in the network don't support the proposed new functions, which will result in a partial end to end trusted path (topology). For this aspect, centralized way seems better than distributed way, since the hop by hop EAP messages of the distributed way cannot be exchanged directly across the legacy device. It's possibly a problem to be addressed;

3.       About the fitness of RATS architecture for the Centralized Trusted Path Routing: I think current 2 defined RATS architectures (background check and passport) are both not very suitable for it. The Centralized Trusted Path Routing mode is a little bit different from the RATS background check architecture in terms of attester directly communicating with the verifier. The RATS architecture can add some sentences to clarify this option;

4.       Echo to 1, TPM PCR value should be the only input to assess the trustworthiness of the target device, more claims can be considered. We can discuss it along the draft iteration;

5.       Too many verifiers in the Distributed Trusted Path Routing mode: according to your current content, every device can be a verifier to request the neighboring device's composite evidence. I think this design complicate the solution. Except a few verifiers, most of the devices only need to be the relying party, which just consume the attestation result in the composite evidence. Otherwise, every device needs to know each other's credential and Know Good Values as being the role of verifier, which is very complex, I think;

6.       About netconf pub/sub model for remote attestation:

a)         I am not sure whether it's your intention, or it's just the beginning of this document, current document has not considered all the features of netconf pub/sub and their applicability to remote attestation. For example, dynamic subscription, on-change subscription are described, configuration subscription, periodic subscription are not. The event stream and selection filters are mainly about TPM PCR, not about other claims. We should discuss it later, and my draft (draft-xia-rats-pubsub-model-02) has more description about them;

b)         Actually, the freshness check problem of netconf pub/sub model is not well addressed in this draft as well. We need to work more;

Thanks!

B.R.
Frank

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 4 Mar 2020 19:22:28 +0000

Hi Frank,

Thanks very much for the comments.  Some thoughts in-line...

From: Xialiang, March 4, 2020 2:50 AM

Hi Eric,

This draft is a good start in the direction about using remote attestation
for the end to end path calculation. The other interesting point is
describing the netconf pub/sub model for remote attestation. 

1.      About a formally defined trustworthiness level: I like it and think
current definition may be not enough. In addition to "boot-verified,
unverified and compromised", there may be more like: system-verified,
system-unverified, "key file"/"key process"-verified, "key file"/"key
process"-verified, key-safe, key-unsafe. I don't want to complicate the
definition, but we may need to consider more, and their combination;

<eric>  Yes I agree.  There is a whole domain of router trustworthiness
levels which need to be explored.   In the YANG model, I made this into a
tree of identities.   And the Verifier can return a list of identities after
doing appraisal.  Figuring out this tree means understanding how each
identity might be actioned within the network.

2.      About Backward compatibility: we must consider the case that some
legacy devices in the network don't support the proposed new functions,
which will result in a partial end to end trusted path (topology). For this
aspect, centralized way seems better than distributed way, since the hop by
hop EAP messages of the distributed way cannot be exchanged directly across
the legacy device. It's possibly a problem to be addressed;

<eric> It is very true that legacy devices must be addressed.  My biggest
technical concern with "distributed" is integration of L2 spanning tree
topologies between L3 FlexAlgo nodes.  The good news is that are lots of
networking technologies which can be applied, including things like the
creation of IPSec tunnels for Secure Subnets between FlexAlgo nodes where an
end-to-end path doesn't currently exist.  Because of all the possible
technical solutions here, I think it is appropriate for all the networking
technology solutions to be abstracted away for this document's scope.

Note: "centralized" does have technical concerns as well.  For example,
centralized path selection and maintenance requires traffic steering
mechanisms.  Also unless you have a robust controller, inserting undetected
devices between nodes is more of a concern.  So there are +/- to both
alternatives.  

3.      About the fitness of RATS architecture for the Centralized Trusted
Path Routing: I think current 2 defined RATS architectures (background check
and passport) are both not very suitable for it. The Centralized Trusted
Path Routing mode is a little bit different from the RATS background check
architecture in terms of attester directly communicating with the verifier.
The RATS architecture can add some sentences to clarify this option;

<eric> This is one of the reasons I put the draft together.  I am hoping
that the authors of the architecture document are able to confirm this is a
valid "Combination"  architecture.  And this will be my ask for any
completion of WGLC by the architecture document :-).    I don't believe that
there needs to be any blockers here, but I am hoping for confirmation.

4.      Echo to 1, TPM PCR value should be the only input to assess the
trustworthiness of the target device, more claims can be considered. We can
discuss it along the draft iteration;

<eric> Yes I agree.   There is text within the document highlighting that
additional YANG notifications can be placed onto the <attestation> Event
Stream.   My expectation is that these might be both standards and vendor
based.

5.      Too many verifiers in the Distributed Trusted Path Routing mode:
according to your current content, every device can be a verifier to request
the neighboring device's composite evidence. I think this design complicate
the solution. Except a few verifiers, most of the devices only need to be
the relying party, which just consume the attestation result in the
composite evidence. Otherwise, every device needs to know each other's
credential and Know Good Values as being the role of verifier, which is very
complex, I think;

<eric> I don't believe the Verifier B role is as complicated as it might
first appear.   The hardest part is acquiring the public keys of the TPMs of
your peers.  Beyond that, it is only the centralized Verifier A which needs
to understand and approve KGVs.   The relying party just needs to be able to
compare time(y) PCR values to time(x) PCR values.  If they are the same,
Verifier B can accept Verifier A's Trustworthiness Level.    Or as link
layer protocols like 802.1x have tunable reauthentication timers, you could
choose to accept the difference in PCR values for a single reauthentication
cycle.

As interesting PCRs shouldn't change too often, the transaction should be
quite manageable.  In fact, the number of transactions could go down as the
relying party doesn't have to verify credentials as the state and identity
of the Attester has already been examined by Verifier A.

a)       I am not sure whether it's your intention, or it's just the
beginning of this document, current document has not considered all the
features of netconf pub/sub and their applicability to remote attestation.
For example, dynamic subscription, on-change subscription are described,
configuration subscription, periodic subscription are not. The event stream
and selection filters are mainly about TPM PCR, not about other claims. We
should discuss it later, and my draft (draft-xia-rats-pubsub-model-02) has
more description about them;

<eric> there are certainly good elements of draft-xia-rats-pubsub-model, a
few of which I point out lower* in this email.  

While it is possible to do a periodic subscription to all the TPM objects, I
find that unsatisfying as PCRs should change rarely.  And we need a very
quick reaction speed when PCRs do change.  When the RATS WG kicked-off I
thought on-change would be a good fit.   However I no longer believe
on-change is appropriate because:

*        *every* internal Attester TPM2 quote would result in a new
signature as the timeticks counter increments.  So changes in needed objects
would flood an RFC-8641 compliant Verifier.

*        You mention draft-bryskin-netconf-automation-yang, however I don't
believe we can wait for the evolution and deployment of
event-condition-action drafts/functionality.  And such a draft would be
needed to selectively allow the sending of TPM Quotes based on a specific
PCR change.

This is why I now believe a RFC-8639 stream is the right way to go.

On configured subscriptions, they should be supportable.   I didn't include
them in the -00 draft because they shouldn't need any incremental
technologies to make them work.  But the fact they are actually supportable
isn't well articulated in the text.  Thanks for the catch on this, I will
make some text changes to Section 5.1 better reflect this possibility. 

b)       Actually, the freshness check problem of netconf pub/sub model is
not well addressed in this draft as well. We need to work more;

<eric> Following are the mechanisms believe are viable for handling
freshness.

*        For the distributed model

o   freshness is verifiable based on TPM Quote at time(y)

*        For the centralized model:

o   Where dynamic subscriptions with a TPM2, use the nonce in the
<establish-subscription>, and then follow the incrementing of timeticks in
the YANG notifications.  

*  For on-change subscription, the object <tpm2-heartbeat> will then cover
an attacker who is getting rid of notifications

*  For periodic subscriptions, freshness can be seen by incrementing
timeticks.

o   For configured subscriptions where there is a TPM2, take TUDA's approach
of watching an incrementing of timeticks. (e.g., Section 7, step [3])

o   Where there is a TPM1.2, either use:

*  a periodic fetch <tpm12-challenge-response-attestation>, see Section
5.2.2

*  broadcast new signed nonces from a central location (not described in the
draft)

I will improve the text to better document some of these.

* Elements of draft-xia-rats-pubsub-model which I believe help fill gaps
from this draft include:

(1) the possibility of several event streams to support different types of
Evidence: pcr-trust-evidence, bios-log-trust-evidence and
ima-log-trust-evidence.    Maybe we would define a hierarchy of streams to
make subscription filtering easier?

(2) explicit identification of the attestation-certificates.  It is
important to explicitly describe mechanisms to easily acquire these.

Thank you!

Eric

Thanks!

B.R.

Frank

 

This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Thu, 5 Mar 2020 07:41:54 +0000

Hi Eric,
It’s a very quick and detailed response, thanks a lot~~

Please see my further comments inline:

发件人: Eric Voit (evoit) [mailto:[email-masked]]
发送时间: 2020年3月5日 3:22
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>
抄送: [email-masked]
主题: RE: Comments on draft-voit-rats-trusted-path-routing-00:

Hi Frank,

1.       About a formally defined trustworthiness level: I like it and think current definition may be not enough. In addition to “boot-verified, unverified and compromised”, there may be more like: system-verified, system-unverified, “key file”/”key process”-verified, “key file”/”key process”-verified, key-safe, key-unsafe… I don’t want to complicate the definition, but we may need to consider more, and their combination;
<eric>  Yes I agree.  There is a whole domain of router trustworthiness levels which need to be explored.   In the YANG model, I made this into a tree of identities.   And the Verifier can return a list of identities after doing appraisal.  Figuring out this tree means understanding how each identity might be actioned within the network.

2.       About Backward compatibility: we must consider the case that some legacy devices in the network don’t support the proposed new functions, which will result in a partial end to end trusted path (topology). For this aspect, centralized way seems better than distributed way, since the hop by hop EAP messages of the distributed way cannot be exchanged directly across the legacy device. It’s possibly a problem to be addressed;
<eric> It is very true that legacy devices must be addressed.  My biggest technical concern with "distributed" is integration of L2 spanning tree topologies between L3 FlexAlgo nodes.  The good news is that are lots of networking technologies which can be applied, including things like the creation of IPSec tunnels for Secure Subnets between FlexAlgo nodes where an end-to-end path doesn't currently exist.  Because of all the possible technical solutions here, I think it is appropriate for all the networking technology solutions to be abstracted away for this document's scope.
[Frank]: you mean a hop by hop IPSec tunnels between FlexAlgo nodes, like: anima acp plane? In fact, anima acp plane also has its complexity and constraints. But I agree that we can abstract them away from this document, at least now~~

Note: "centralized" does have technical concerns as well.  For example, centralized path selection and maintenance requires traffic steering mechanisms.  Also unless you have a robust controller, inserting undetected devices between nodes is more of a concern.  So there are +/- to both alternatives.

[Frank]: agree.

3.       About the fitness of RATS architecture for the Centralized Trusted Path Routing: I think current 2 defined RATS architectures (background check and passport) are both not very suitable for it. The Centralized Trusted Path Routing mode is a little bit different from the RATS background check architecture in terms of attester directly communicating with the verifier. The RATS architecture can add some sentences to clarify this option;
<eric> This is one of the reasons I put the draft together.  I am hoping that the authors of the architecture document are able to confirm this is a valid "Combination"  architecture.  And this will be my ask for any completion of WGLC by the architecture document :-).    I don't believe that there needs to be any blockers here, but I am hoping for confirmation.
[Frank]: let’s talk with RATS architecture authors later for this, maybe.

4.       Echo to 1, TPM PCR value should be the only input to assess the trustworthiness of the target device, more claims can be considered. We can discuss it along the draft iteration;
<eric> Yes I agree.   There is text within the document highlighting that additional YANG notifications can be placed onto the <attestation> Event Stream.   My expectation is that these might be both standards and vendor based.

5.       Too many verifiers in the Distributed Trusted Path Routing mode: according to your current content, every device can be a verifier to request the neighboring device’s composite evidence. I think this design complicate the solution. Except a few verifiers, most of the devices only need to be the relying party, which just consume the attestation result in the composite evidence. Otherwise, every device needs to know each other’s credential and Know Good Values as being the role of verifier, which is very complex, I think;
<eric> I don't believe the Verifier B role is as complicated as it might first appear.   The hardest part is acquiring the public keys of the TPMs of your peers.  Beyond that, it is only the centralized Verifier A which needs to understand and approve KGVs.   The relying party just needs to be able to compare time(y) PCR values to time(x) PCR values.  If they are the same, Verifier B can accept Verifier A's Trustworthiness Level.    Or as link layer protocols like 802.1x have tunable reauthentication timers, you could choose to accept the difference in PCR values for a single reauthentication cycle.

As interesting PCRs shouldn't change too often, the transaction should be quite manageable.  In fact, the number of transactions could go down as the relying party doesn't have to verify credentials as the state and identity of the Attester has already been examined by Verifier A.
[Frank]: I agree you analysis for current PCR implementation, but if we consider more for future, maybe we need to support more claims and their verification on different devices as required, the distribution of KGVs still exist then.

a)         I am not sure whether it’s your intention, or it’s just the beginning of this document, current document has not considered all the features of netconf pub/sub and their applicability to remote attestation. For example, dynamic subscription, on-change subscription are described, configuration subscription, periodic subscription are not. The event stream and selection filters are mainly about TPM PCR, not about other claims. We should discuss it later, and my draft (draft-xia-rats-pubsub-model-02) has more description about them;

<eric> there are certainly good elements of draft-xia-rats-pubsub-model, a few of which I point out lower* in this email.

While it is possible to do a periodic subscription to all the TPM objects, I find that unsatisfying as PCRs should change rarely.  And we need a very quick reaction speed when PCRs do change.  When the RATS WG kicked-off I thought on-change would be a good fit.   However I no longer believe on-change is appropriate because:

・         *every* internal Attester TPM2 quote would result in a new signature as the timeticks counter increments.  So changes in needed objects would flood an RFC-8641 compliant Verifier.

・         You mention draft-bryskin-netconf-automation-yang, however I don't believe we can wait for the evolution and deployment of event-condition-action drafts/functionality.  And such a draft would be needed to selectively allow the sending of TPM Quotes based on a specific PCR change.
This is why I now believe a RFC-8639 stream is the right way to go.
[Frank]: you are the expert of pub/sub model, I need to learn more from you~~

On configured subscriptions, they should be supportable.   I didn't include them in the -00 draft because they shouldn't need any incremental technologies to make them work.  But the fact they are actually supportable isn't well articulated in the text.  Thanks for the catch on this, I will make some text changes to Section 5.1 better reflect this possibility.
[Frank]: thanks.

b)         Actually, the freshness check problem of netconf pub/sub model is not well addressed in this draft as well. We need to work more;
<eric> Following are the mechanisms believe are viable for handling freshness.

・         For the distributed model

o   freshness is verifiable based on TPM Quote at time(y)
[Frank]: it requires the time sync among the devices, right?

・         For the centralized model:

o   Where dynamic subscriptions with a TPM2, use the nonce in the <establish-subscription>, and then follow the incrementing of timeticks in the YANG notifications.

§  For on-change subscription, the object <tpm2-heartbeat> will then cover an attacker who is getting rid of notifications

§  For periodic subscriptions, freshness can be seen by incrementing timeticks.

o   For configured subscriptions where there is a TPM2, take TUDA's approach of watching an incrementing of timeticks. (e.g., Section 7, step [3])

§  a periodic fetch <tpm12-challenge-response-attestation>, see Section 5.2.2

§  broadcast new signed nonces from a central location (not described in the draft)
I will improve the text to better document some of these.
[Frank]: ok, looking forward to more text about this key issue~~

* Elements of draft-xia-rats-pubsub-model which I believe help fill gaps from this draft include:

(1) the possibility of several event streams to support different types of Evidence: pcr-trust-evidence, bios-log-trust-evidence and ima-log-trust-evidence.    Maybe we would define a hierarchy of streams to make subscription filtering easier?
(2) explicit identification of the attestation-certificates.  It is important to explicitly describe mechanisms to easily acquire these.
[Frank]: I can help on these`~~

B.R.
Frank

Thank you!
Eric

Thanks!

B.R.
Frank

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Mar 2020 16:41:13 +0000

Hi Frank,

Pruning the questions below to those which are open...

From: Xialiang, March 5, 2020 2:42 AM

Hi Eric,

It's a very quick and detailed response, thanks a lot~~

 

From: Eric Voit (evoit)

Hi Frank,

Hi Eric,

...

[Frank]: I agree you analysis for current PCR implementation, but if we
consider more for future, maybe we need to support more claims and their
verification on different devices as required, the distribution of KGVs
still exist then.

<eric>  The passport model as described in Section 4.2 works because two
instances of signed Evidence "Quotes" are coming from the TPM based
attesting environment.  Additionally the first Evidence Quote *must* be
coupled with a Verifier's Attestation Result.  There is no other assumption
that Verifier be limited in the evidence it collects.   This is why I am
interested in draft-fedorkow-rats-network-device-attestation's Figure 2.   I
believe a lot can be done with this construct, as long as we have guidelines
on what Evidence might extend specific PCRs.   

<eric>  No time synch between the devices is absolutely required.   The
nonce provided at (3) establishes freshness.

<Eric>  Excellent.   As the draft gets additional feedback from the WG,
hopefully we can establish a group willing to progress the concepts.

Eric

B.R.

Frank

Thank you!

Eric

Thanks!

B.R.

Frank