Re: [Rats] About current RATS drafts

[Laurence Lundblade <[e-mail]>]

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