Subject: [Rats] A comment on draft-ietf-rats-tpm-based-network-device-attest

From: "Meiling Chen" <[email-masked]>
Date: Wed, 16 Feb 2022 16:58:11 +0800

Hi authors, folks,
 
I had a comment of “whether the TPM here can also refer to something else which is also similar to TCG TPM1.2/TPM2.0” when I first read the draft a long time ago. The network devices may have various kinds of root of trust. In the Abstract of this draft, it only says that the network device contains TPM1.2 or TPM2.0 as defined by TCG. But except for using TCG TPM1.2/TPM2.0, if the network devices use other root of trust which also includes the TPM’s functionalities or protected capabilities, I think the remote integrity verification described in this draft can also be useable for those network devices.
I’m sorry for raising this comment so late. At that time, I didn’t figure out how to simply extend the scope but not complex the content, so I didn’t raise it to the mailing list and gradually forgot about it.
Recently, my colleague found a description in ETSI GS NFV-SEC 012 v3.1.1 [1] when studying the NFV related specifications. After a tea-break talk with him, I recalled this comment and realized that description might also be helpful here. In that ETSI specification, it uses the concept of “Hardware-Based Root of Trust (HBRT)”, and in section 8.10 it says “The HBRT shall be based on hardware-based TPM or equivalent hardware root of trust (e.g. Secure Element including TPM functionalities, HSM including TPM functionalities).”
The usage of “equivalent” gives me some inspiration and makes me feel that we can also use a similar description in the RATS document. I think maybe one or two sentences can be added at the beginning of the draft, to say that the network device not only can contain the TCG TPM1.2/TPM2.0, but also can contain equivalent hardware implementations that include the protected capabilities as provided by TPM.
 
[1] https://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/012/03.01.01_60/gs_NFV-SEC012v030101p.pdf

Best,
Meiling

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 16 Feb 2022 13:50:08 +0000

Hi Meiling,

My belief is that if a router/switch contains cryptoprocessor supporting the
APIs for TPM1.2/TPM2.0, then the RIV and Charra drafts would be considered
compliant.  I think this is fine because neither RIV nor Charra require TCG
certification:
https://trustedcomputinggroup.org/membership/certification/tpm-certified-pro
ducts/       This is something all of the draft authors discussed at
kick-off.  

Put another way, Cisco's router/switch based cryptoprocessors are capable of
the TCG's APIs.  But they have not gone through a TCG Certification Program.
And I do not consider this disqualifying.

If others felt this way, I suspect we could do a late insert of a statement
to this effect.  I am not sure this is necessary.

Eric

From: Meiling Chen, February 16, 2022 3:58 AM

Hi authors, folks,

I had a comment of "whether the TPM here can also refer to something else
which is also similar to TCG TPM1.2/TPM2.0" when I first read the draft a
long time ago. The network devices may have various kinds of root of trust.
In the Abstract of this draft, it only says that the network device contains
TPM1.2 or TPM2.0 as defined by TCG. But except for using TCG TPM1.2/TPM2.0,
if the network devices use other root of trust which also includes the TPM's
functionalities or protected capabilities, I think the remote integrity
verification described in this draft can also be useable for those network
devices.

I'm sorry for raising this comment so late. At that time, I didn't figure
out how to simply extend the scope but not complex the content, so I didn't
raise it to the mailing list and gradually forgot about it.

Recently, my colleague found a description in ETSI GS NFV-SEC 012 v3.1.1 [1]
when studying the NFV related specifications. After a tea-break talk with
him, I recalled this comment and realized that description might also be
helpful here. In that ETSI specification, it uses the concept of
"Hardware-Based Root of Trust (HBRT)", and in section 8.10 it says "The HBRT
shall be based on hardware-based TPM or equivalent hardware root of trust
(e.g. Secure Element including TPM functionalities, HSM including TPM
functionalities)."

The usage of "equivalent" gives me some inspiration and makes me feel that
we can also use a similar description in the RATS document. I think maybe
one or two sentences can be added at the beginning of the draft, to say that
the network device not only can contain the TCG TPM1.2/TPM2.0, but also can
contain equivalent hardware implementations that include the protected
capabilities as provided by TPM.

[1]
<https://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/012/03.01.01_60/gs_NFV
-SEC012v030101p.pdf>
https://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/012/03.01.01_60/gs_NFV-
SEC012v030101p.pdf

Best,

Meiling

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 16 Feb 2022 17:01:07 +0100

Hi Meiling,
hi Eric,

As I-D.ietf-rats-yang-tpm-charra inherits the same "problem statement" I 
am chiming in here.

(1) I think Eric is correct and in general the current phrasing is 
effectively not disqualifying within the self-contained specification 
and its intent.

(2) With respect to the audience of these RFSs and processing 
corresponding specifications during requirements compliance, I can see 
how a few more words might safe a lot of cycles arguing that about the 
RFCs not only applying to "dedicated TPM system components", but to 
"system components in compliance with the TCG's TPM ((A)P)Is".

Speaking from experience, subtle changes to statements like this that 
reflect the intended scope of application only a bit more precise can 
prevent several cost sinks during adoption.

Meiling, do you have a phrasing in mind that would address you concern? 
 From my point of view (which is about I-D.ietf-rats-yang-tpm-charra), 
this a purely editorial issue and we could address that in the next few 
days, if you provide a PR to 
https://github.com/ietf-rats-wg/basic-yang-module/pulls

We still have few (but relatively minor) PRs open due to recent 
feedback. I would like to have the churn stop 14 days before the 
scheduled IESG telechat, which means: Churn cut-off is at Mar 24th at 
the latest. Does that work for you?

Viele Grüße,

Henk

On 16.02.22 14:50, Eric Voit (evoit) wrote:
> Hi Meiling,
> 
> My belief is that if a router/switch contains cryptoprocessor supporting 
> the APIs for TPM1.2/TPM2.0, then the RIV and Charra drafts would be 
> considered compliant.  I think this is fine because neither RIV nor 
> Charra require TCG certification: 
> https://trustedcomputinggroup.org/membership/certification/tpm-certified-products/ 
> <https://trustedcomputinggroup.org/membership/certification/tpm-certified-products/>    
>     This is something all of the draft authors discussed at kick-off.
> 
> Put another way, Cisco's router/switch based cryptoprocessors are 
> capable of the TCG's APIs.  But they have not gone through a TCG 
> Certification Program.  And I do not consider this disqualifying.
> 
> If others felt this way, I suspect we could do a late insert of a 
> statement to this effect.  I am not sure this is necessary.
> 
> Eric
> 
> *From:*Meiling Chen, February 16, 2022 3:58 AM
> 
> Hi authors, folks,
> 
> I had a comment of “whether the TPM here can also refer to something 
> else which is also similar to TCG TPM1.2/TPM2.0” when I first read the 
> draft a long time ago. The network devices may have various kinds of 
> root of trust. In the Abstract of this draft, it only says that the 
> network device contains TPM1.2 or TPM2.0 as defined by TCG. But except 
> for using TCG TPM1.2/TPM2.0, if the network devices use other root of 
> trust which also includes the TPM’s functionalities or protected 
> capabilities, I think the remote integrity verification described in 
> this draft can also be useable for those network devices.
> 
> I’m sorry for raising this comment so late. At that time, I didn’t 
> figure out how to simply extend the scope but not complex the content, 
> so I didn’t raise it to the mailing list and gradually forgot about it.
> 
> Recently, my colleague found a description in ETSI GS NFV-SEC 012 v3.1.1 
> [1] when studying the NFV related specifications. After a tea-break talk 
> with him, I recalled this comment and realized that description might 
> also be helpful here. In that ETSI specification, it uses the concept of 
> “Hardware-Based Root of Trust (HBRT)”, and in section 8.10 it says “The 
> HBRT shall be based on hardware-based TPM or equivalent hardware root of 
> trust (e.g. Secure Element including TPM functionalities, HSM including 
> TPM functionalities).”
> 
> The usage of “equivalent” gives me some inspiration and makes me feel 
> that we can also use a similar description in the RATS document. I think 
> maybe one or two sentences can be added at the beginning of the draft, 
> to say that the network device not only can contain the TCG 
> TPM1.2/TPM2.0, but also can contain equivalent hardware implementations 
> that include the protected capabilities as provided by TPM.
> 
> [1] 
> https://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/012/03.01.01_60/gs_NFV-SEC012v030101p.pdf 
> <https://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/012/03.01.01_60/gs_NFV-SEC012v030101p.pdf>
> 
> Best,
> 
> Meiling
>

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 17 Feb 2022 04:10:28 +0000

Hi Meiling,
Hi Eric,

To Meiling, thank you for bringing this topic, I find it is interesting and useful.

To Eric, thanks for sharing the thoughts of the authors.
> This is something all of the draft authors discussed at kick-off.
Is there any written record of this discussion?

I think the ambiguity would keep existing if it weren’t clearly pointed out, and future readers would also be possible to have such confusion. Because before Meiling started this discussion, I had always thought that the “TPM” in these two drafts meant the TPM having passed the TCG certification. Until now, I realized that it was not the case at all. But I’m glad to see that the “TPM” can mean a broader scope. I think the content of these two drafts is also applicable for the “equivalent hardware implementations that include the protected capabilities as provided by TPM”.

So I prefer inserting a statement into the document.

Regards & Thanks!
Wei Pan (潘伟)

From: RATS [mailto:[email-masked]] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, February 16, 2022 9:50 PM
To: Meiling Chen <[email-masked]>; [email-masked]; draft-ietf-rats-tpm-based-network-device-attest <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] A comment on draft-ietf-rats-tpm-based-network-device-attest

Hi Meiling,

My belief is that if a router/switch contains cryptoprocessor supporting the APIs for TPM1.2/TPM2.0, then the RIV and Charra drafts would be considered compliant.  I think this is fine because neither RIV nor Charra require TCG certification: https://trustedcomputinggroup.org/membership/certification/tpm-certified-products/       This is something all of the draft authors discussed at kick-off.

Put another way, Cisco's router/switch based cryptoprocessors are capable of the TCG's APIs.  But they have not gone through a TCG Certification Program.  And I do not consider this disqualifying.

If others felt this way, I suspect we could do a late insert of a statement to this effect.  I am not sure this is necessary.

Eric

Best,
Meiling

---

From: "Meiling Chen" <[email-masked]>
Date: Thu, 17 Feb 2022 14:59:13 +0800

Hi all,
Thanks for Eric's quick reply, also thank Panwei for his suggestion.
Unfortunately, I didn't notice that the authors have discussed this issue before. 
Since the main contents of these two drafts are not based on the TCG certified TPM, I suggest that this implicit ambiguity can be eliminated.
Most importantly, as Eric said, just  insert of a statement, a small change, it seems that there should be time to modify it before RFC publication.

Best,
Meiling
 
发件人： Panwei \(William\)
发送时间： 2022-02-17 12:10
收件人： Eric Voit (evoit); Meiling Chen; [email-masked]; draft-ietf-rats-tpm-based-network-device-attest
抄送： [email-masked]
主题： Re: [Rats] A comment on draft-ietf-rats-tpm-based-network-device-attest
Hi Meiling,
Hi Eric,

 

Regards & Thanks!
Wei Pan (潘伟)

Hi Meiling,

 
 
Eric

 

Best,
Meiling

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Feb 2022 07:11:20 +0000

Hi,

just joining in here after a long hiatus.  We had a hand in much of the NFV security specs and in particular various items relating to root of trust.

One of the difficulties when talking about TPM is that it is often incorrectly assumed to mean a discrete piece of hardware, and then often believed to be produced by one single manufacturer. Obviously, this is incorrect so pains must be taken to address that the TPM specification suite addresses a large number of aspects and for the most part TPM can be better thought of as a suite of security technologies, cf: Pluton etc.

I typically address this by referring to "Attestable" things to cover a larger array of technologies, not just TPM. Attestable here meaning those that can provide claims with particular security guarantees, cf: TPM quotes.

Attestatble might be too broad for RATS but has helped in defining the properties of what such a device/element/thing must have.

t.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Panwei (William) <[email-masked]>
Sent: 17 February 2022 06:10
To: Eric Voit (evoit) <evoit=[email-masked]>; Meiling Chen <[email-masked]>; [email-masked] <[email-masked]>; draft-ietf-rats-tpm-based-network-device-attest <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Rats] A comment on draft-ietf-rats-tpm-based-network-device-attest

Hi Meiling,

Hi Eric,

Regards & Thanks!

Wei Pan (潘伟)

Hi Meiling,

Eric

Hi authors, folks,

Best,

Meiling

---

From: "Meiling Chen" <[email-masked]>
Date: Thu, 17 Feb 2022 15:17:58 +0800

Hi Henk,
That's a great idea, I will submit a modification proposal on GitHub later.

Best,
Meiling
 
From: Henk Birkholz
Date: 2022-02-17 00:01
To: Eric Voit (evoit); Meiling Chen; [email-masked]; draft-ietf-rats-tpm-based-network-device-attest
CC: [email-masked]
Subject: Re: [Rats] A comment on draft-ietf-rats-tpm-based-network-device-attest
Hi Meiling,
hi Eric,

 

 

Viele Grüße,
 
Henk
 
> <https://www.etsi.org/deliver/etsi_gs/NFV-SEC/001_099/012/03.01.01_60/gs_NFV-SEC012v030101p.pdf>
 
_______________________________________________
RATS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rats

---

From: "Meiling Chen" <[email-masked]>
Date: Wed, 23 Feb 2022 11:14:01 +0800

Hi Henk, all,
I have made a little change in the abstract, please see more detail from the github.
https://github.com/ietf-rats-wg/basic-yang-module/pull/73 

Best,
Meiling
 
From: Meiling Chen
Date: 2022-02-17 15:17
To: Henk Birkholz; evoit; [email-masked]; draft-ietf-rats-tpm-based-network-device-attest
CC: [email-masked]
Subject: Re: Re: [Rats] A comment on draft-ietf-rats-tpm-based-network-device-attest
Hi Henk,
That's a great idea, I will submit a modification proposal on GitHub later.

Best,
Meiling
 
From: Henk Birkholz
Date: 2022-02-17 00:01

 

 

Viele Grüße,
 
Henk