Subject: [Rats] About current RATS drafts

From: H Y <[email-masked]>
Date: Fri, 1 Nov 2019 21:08:06 +0900

Hi all,

I'm Yuhei Hayashi, network security researcher of NTT in Japan. I
learned about the existence of RATS WG at IETF 105.

I'm interested in the work of RATS WG and I'm trying to understand it.
So, I'm firstly trying to understand which drafts contain the
standards listed in the charter.

I will attach the result of organizing it from my own point of view.
I'm glad if you confirm that my understanding is correct, if possible.

Thanks,
Yuhei
-- 
----------------------------------
Yuuhei HAYASHI
[email-masked]
----------------------------------

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 1 Nov 2019 13:20:40 +0100

Hello Yuhei,

welcome :)

I think your survey is a quite astute representation of the current state.

Please note, that the "information-model" I-D was intended to kickstart 
the discussion about "where do the definitions of information elements 
go", it might not survive the outcome, or might become the hub document 
for the information model and how it is supposed to be extended, or 
absorbed by another doc - that is not clear yet.

Also, while EAT is currently placed in the "attestation evidence flow" 
(Claim) scope and not in the "attestation provision flow" (Assertion) 
scope, EAT is extendable and it might make sense to create EAT flavors 
for the other scope later, if required.

Current planning also includes to remove architectural text from the EAT 
I-D, but that requires some resolve (aka WG consensus) on how to proceed 
with the architecture I-D.

Having said that, everything I did not comment on seems to be right 
where it should be. Other comments?

Viele Grüße,

Henk

On 01.11.19 13:08, H Y wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 1 Nov 2019 07:25:02 -0700

Hello,

A frame up that works for me is to think about 1) the claims, the attestation format and its details and 2) the transport / conveyance and its details.

In the TPM/TCG world the claims and attestation format is locked down by what TPM chips do today. It is a set of registers that hold hash values used to measure software.  In the EAT world, which typically implements on fully functional CPUs, the claims and attestation format is not at all locked down and our work is to define it (the eat draft).

A lot of the network and router folks have been putting TPMs into their routers and now need a way to get the TPM output off the router to the network management center. This world runs off of Yang protocols. The main interest there is a very specific Yang-based way to move TPM output. This is the yang, tuda and pubsub drafts.

The EAT use cases are more about TEE’s and lining up with end-user-application-oriented uses like FIDO and the Android key store. They make use of all the existing transports used by application protocol (mainly HTTP) so there’s no worry about defining transport.

I think a few of us see EAT as the more general and flexible attestation format that will eventually replace the TPM format. Because EAT can use CBOR and COSE which are carefully designed for constrained devices there is some hope that it can go into TPM-like HW.

The architecture draft is trying to tie the two together in a sort of unified field theory. Seems possible, but hard to me.

LL

> On Nov 1, 2019, at 5:08 AM, H Y <[email-masked]> wrote:
> 
> Hi all,
> 
> <RATS_drafts.pdf>_______________________________________________
> RATS mailing list
> [email-masked]

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 1 Nov 2019 15:57:37 +0100

Hi Laurence,

good point. There are basically two primary focuses here, I think:

1.) Evidence that includes Trustworthy Claims about the Attester, and
2.) Evidence that includes Claims about the Trustworthiness of the Attester.

In 1.) you can put trust into the Veracity of Evidence due to the 
attestation Provenance, in 2.) you are given the decision basis for 
assessing the Trustworthiness/Integrity of the attestation Provenance.

Laurence, please correct me if I am wrong, but the current EAT draft 
focuses on 1.). Is that correct?

Viele Grüße,

Henk

On 01.11.19 15:25, Laurence Lundblade wrote:
> Hello,
> 
> A frame up that works for me is to think about 1) the claims, the 
> attestation format and its details and 2) the transport / conveyance and 
> its details.
> 
> In the TPM/TCG world the claims and attestation format is locked down by 
> what TPM chips do today. It is a set of registers that hold hash values 
> used to measure software.  In the EAT world, which typically implements 
> on fully functional CPUs, the claims and attestation format is not at 
> all locked down and our work is to define it (the eat draft).
> 
> A lot of the network and router folks have been putting TPMs into their 
> routers and now need a way to get the TPM output off the router to the 
> network management center. This world runs off of Yang protocols. The 
> main interest there is a very specific Yang-based way to move TPM 
> output. This is the yang, tuda and pubsub drafts.
> 
> The EAT use cases are more about TEE’s and lining up with 
> end-user-application-oriented uses like FIDO and the Android key store. 
> They make use of all the existing transports used by application 
> protocol (mainly HTTP) so there’s no worry about defining transport.
> 
> I think a few of us see EAT as the more general and flexible attestation 
> format that will eventually replace the TPM format. Because EAT can use 
> CBOR and COSE which are carefully designed for constrained devices there 
> is some hope that it can go into TPM-like HW.
> 
> The architecture draft is trying to tie the two together in a sort of 
> unified field theory. Seems possible, but hard to me.
> 
> LL
> 
> 
> 
> 
> 
>> On Nov 1, 2019, at 5:08 AM, H Y <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 1 Nov 2019 08:24:52 -0700

Hi Henk,

good point.

Yes, EAT has been focused on 1) below. However it seems we might expand EAT to 2) especially considering that 2) is not constrained by the TPM.  I’ve added an issue <https://github.com/ietf-rats-wg/eat/issues/44> to the EAT GitHub to track this possible work.

Here’s two examples:

The input to the verifier may be software measurements (TPM or EAT format). The output of the verifier might be a Boolean that the measurements were correct.

Some implicit claims might be made explicit. For example, if the verifier knows that the device will never send an attestation is the boot and debug state are not locked down, then the verifier can add those claims.

LL

> On Nov 1, 2019, at 7:57 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> In 1.) you can put trust into the Veracity of Evidence due to the attestation Provenance, in 2.) you are given the decision basis for assessing the Trustworthiness/Integrity of the attestation Provenance.
> 
> Laurence, please correct me if I am wrong, but the current EAT draft focuses on 1.). Is that correct?
> 
> Viele Grüße,
> 
> Henk
> 
>>> On Nov 1, 2019, at 5:08 AM, H Y <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi all,
>>>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 1 Nov 2019 16:38:10 +0100

Hi Laurence,

I'll map that to the terminology that is still consistent between the 
initial architecture I-D and Dave's condensed architecture I-D. Also a 
question at the end.

> The input to the verifier may be software measurements (TPM or EAT format).

That is the Attestation Evidence (that was the only thing I meant when 
talking about the "two primary focuses".

> The output of the verifier might be a Boolean that the measurements were correct.

That is (the most simple, but most certainly viable) the Attestation Result.

> If the verifier knows that the device will never send an attestation is the boot and debug state are not locked down, then the verifier can add those claims.

I do not fully follow you here, I am afraid. Which Claims can be added 
by the Verifer to what at which time? :) I assume you mean that the 
Attestation Result can include implicit assertions based on the 
attestation Provenance - expressed as Claims. I am not really sure, what 
type of claims you are implying, though.

Viele Grüße,

Henk

On 01.11.19 16:24, Laurence Lundblade wrote:
> Hi Henk,
> 
> good point.
> 
> Yes, EAT has been focused on 1) below. However it seems we might expand 
> EAT to 2) especially considering that 2) is not constrained by the TPM. 
>   I’ve added an issue <https://github.com/ietf-rats-wg/eat/issues/44> to 
> the EAT GitHub to track this possible work.
> 
> Here’s two examples:
> 
>     The input to the verifier may be software measurements (TPM or EAT
>     format). The output of the verifier might be a Boolean that the
>     measurements were correct.
> 
>     Some implicit claims might be made explicit. For example, if the
>     verifier knows that the device will never send an attestation is the
>     boot and debug state are not locked down, then the verifier can
>     add those claims.
> 
> 
> LL
> 
> 
>> On Nov 1, 2019, at 7:57 AM, Henk Birkholz 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Laurence,
>>
>>> attestation format and its details and 2) the transport / conveyance 
>>> and its details.
>>> In the TPM/TCG world the claims and attestation format is locked down 
>>> by what TPM chips do today. It is a set of registers that hold hash 
>>> values used to measure software.  In the EAT world, which typically 
>>> implements on fully functional CPUs, the claims and attestation 
>>> format is not at all locked down and our work is to define it (the 
>>> eat draft).
>>> A lot of the network and router folks have been putting TPMs into 
>>> their routers and now need a way to get the TPM output off the router 
>>> to the network management center. This world runs off of Yang 
>>> protocols. The main interest there is a very specific Yang-based way 
>>> to move TPM output. This is the yang, tuda and pubsub drafts.
>>> end-user-application-oriented uses like FIDO and the Android key 
>>> store. They make use of all the existing transports used by 
>>> application protocol (mainly HTTP) so there’s no worry about defining 
>>> transport.
>>> I think a few of us see EAT as the more general and flexible 
>>> attestation format that will eventually replace the TPM format. 
>>> Because EAT can use CBOR and COSE which are carefully designed for 
>>> constrained devices there is some hope that it can go into TPM-like HW.
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 1 Nov 2019 10:56:22 -0700

> On Nov 1, 2019, at 8:38 AM, Henk Birkholz <[email-masked]> wrote:
> 
> I do not fully follow you here, I am afraid. Which Claims can be added by the Verifer to what at which time? :) I assume you mean that the Attestation Result can include implicit assertions based on the attestation Provenance - expressed as Claims. I am not really sure, what type of claims you are implying, though.

Yes, more details are a good idea. :-) With an example of a chip made by the fictitious “Acme Chip Company”. 

Acme makes chip model X with HW and boot ROM that:
- have an attestation key programmed at the Acme factory
- prevent use of the attestation key unless
  - booted using authenticated sw
  - all HW debug facilities are turned off

Acme operates the verification service itself. When it receives attestation evidence from chip model X it knows that authenticated boot was used and all the debug modes are turned off because the attestation key would not be accessible if that wasn’t true. There would be no attestation. Further, it knows it is Acme Model X because of the particular attestation key. They only put that key in Model X device, not in Model Y or Z devices.

So, when Acme’s verification service generates an attestation result it can include these even though they were not in the attestation evidence:
debug_disable_claim = disabled
boot_state_claim = true

They are implicit claims in the attestation evidence made explicit in the attestation result.

I expect there are a number of claims that could and should work this way.

LL

---

From: H Y <[email-masked]>
Date: Sat, 2 Nov 2019 08:27:09 +0900

Hi Henk, Laurence,

Thank you for confirming my understandings. Your comments really help me to
read current drafts. :-)

Thanks,
Yuhei

2019年11月1日(金) 23:25 Laurence Lundblade <[email-masked]>:

> used to measure software.  In the EAT world, which typically implements on
> fully functional CPUs, the claims and attestation format is not at all
> locked down and our work is to define it (the eat draft).
>
> network management center. This world runs off of Yang protocols. The main
> interest there is a very specific Yang-based way to move TPM output. This
> is the yang, tuda and pubsub drafts.
>
> They make use of all the existing transports used by application protocol
> (mainly HTTP) so there’s no worry about defining transport.
>
> CBOR and COSE which are carefully designed for constrained devices there is
> some hope that it can go into TPM-like HW.
>

08065300884
[email-masked]