Re: [Rats] About current RATS drafts

[Henk Birkholz <[e-mail]>]

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 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> 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 <[e-mail] 
>>>> <mailto:[e-mail]> <mailto:[e-mail]>> 
>>>> wrote:
>>>>
>>>> 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
>>>> [e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail]>
>>>> ----------------------------------
>>>> <RATS_drafts.pdf>_______________________________________________
>>>> RATS mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/rats
>>> _______________________________________________
>>> RATS mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>