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

[Henk Birkholz <[e-mail]>]

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
>