Re: [Rats] EAT document (was Re: CDDL for CWT, JWT, UCCS and UJCS)

[Laurence Lundblade <[e-mail]>]

Hey Henk,

Pretty much agree with all you say below. Completely understand that EAT doesn’t fit every use case. Thanks for taking the time write it out. :-)

As to Michael’s comment "it does not seem like the document is actually that important.”
- Henk provides some good reasons below
- EAT lines up well for big use case like FIDO and the Android Key Store 
- It works well with TEE’s. It is used by SUIT, is integrated into ARM’s Trusted Firmware and is a part of ARM’s PSA certified program
- If you can’t afford to solder a TPM into you IoT device and your device needs the most compact representation, doesn’t use YANG and such, EAT is a good candidate

Now that the core writing for EAT is done, I hope to spend more time seeing how it fits with other RATS work. Am open to changes in EAT, particularly improving the claims, to make it fit better.

LL



> On Oct 27, 2021, at 3:14 PM, Henk Birkholz <[e-mail]> wrote:
> 
> Hi Laurence,
> 
> one step towards answering the question "what will a person implementing RATS use if they are not using yang?" is of course > draft-ietf-rats-reference-interaction-models
> 
> But of course that work does not provide you with a set of protocols (aka the complete answer), but only with a set of models to chose from in order to build the acutal protocol.
> 
> Now - I've been holding back on that one - TUDA is of course a very exact protocol how to convey evidence and that would be one candiate> draft-birkholz-rats-tuda
> 
> Alas, that protocol does not require EAT, as well as YANG TPM CHARRA does not. In consequence, I like the notion to align EAT more to TUDA or to YANG of course, but I am not certain that that is actually possible. I'd really appreciate proposals that illustrate how to do that.
> 
> EAT brings a lot of flexibility to the table, especially if the layout of an attesting environment is under your design control. Mix in some simple component hierarchy that is also under your direct control, such as with cell phones, and EAT is an excellent fit.
> 
> There are other evidence representations that are more difficult to fit into EAT (as we have learned here in RATS), because they already existed for a long time, have stable and intentionally (relatively "strict defined") interfaces, such as a TPM. That does not seem to be a bad thing, but simply is accepted as a different way how to phrase evidence, in the end.
> 
> In summary, today there are a few distinct ways how to represent evidence. Some representations are based on existing technology, some representations are based on the appraisal process (e.g. IMA logs in support of indeterministic user space environments), and some representations are tailored to match other conceptual message formats.
> 
> On the one hand, I think EAT should be the first goto candidate, if you want to implement RATS and are free to chose how to do it. On the other hand, I also think that EAT should not be an MTI or a mandatory data model to be incorporated in a protocol.
> 
> The most important thing EAT brings to the table - from my point of view - is actually the information model. The information elements defined (and registered as CWT Claim definitions in the end) are the real treat. No evidence format should conflict with these definitions! That would be really really bad for semantic interoperability and would be in conflict with the RATS WG's goals. If there is overlap, the WG process should identify that and address that (although I am not taking a stance on the "how", maybe sometimes a change to EAT might be warranted, but that case would have to be presented very thoroughly).
> 
> In general, I'd like to see EAT as "the first candidate in line", but also other options next to it next in line.
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 
> 
> On 27.10.21 20:53, Laurence Lundblade wrote:
>> Hi Henk,
>> Right. As a data model, the question seems mostly the same.  What will a person implementing RATS use if they are not using yang?
>> Yang is not particularly suitable for small IoT devices, and those devices need attestation too, right? Claims in a UCCS sent over DTLS is EAT, right?
>> And maybe we should we be aligning EAT closer to all the stuff defined for yang?
>> LL
>>> On Oct 27, 2021, at 10:38 AM, Henk Birkholz <[e-mail]> wrote:
>>> 
>>> Hi Laurence,
>>> 
>>> EAT is not a protocol, it is a data model for CWT (and I guess now also for JWT) to represent remote attestation evidence (where evidence is the conceptual message generated by an Attester and appraised by a Verifier).
>>> 
>>> The data model proposed can include information elements that are useful for protocols - most prominently, a nonce - but that does not render it a protocol, it probably makes it "convenient payload" that also "puts constraints on most protocols that want to use EAT".
>>> 
>>> Viele Grüße,
>>> 
>>> Henk
>>> 
>>> 
>>> 
>>> On 27.10.21 18:40, Laurence Lundblade wrote:
>>>> On Oct 27, 2021, at 8:25 AM, Michael Richardson <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> Michael Richardson <[e-mail]> wrote:
>>>>>> To me, the document looks done to me.
>>>>>> I think that there are wording fixes that would make it a little easier to
>>>>>> read, but it sure looks finished to me.
>>>>> 
>>>>> Is EAT core work for the RATS document set?
>>>>> I thought it was.  But it does not seem like the document is actually that important.
>>>> R in RATS is for “remote” which means there’s a protocol to convey Attestation Evidence.
>>>> If you want to do remote attestation that is not conveyed via YANG, would not EAT be the protocol?
>>>> What’s your vision of the protocols used in remote attestation that doesn’t need EAT?
>>>> LL
>>>> _______________________________________________
>>>> RATS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rats