Re: [Rats] Use case -> architecture document

[Henk Birkholz <[e-mail]>]

Hi Jürgen,

a quick reply on the most simple item (I hope):

> challenge response interaction

The authors decided to split solution references out of the architecture 
and at the moment reference interaction models are maintained here:

> https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/

We are working on the request to move information elements that are not 
Claims but used in the transfer protocols to this I-D, too.

There is also running code as a "proof of concept on freshness & 
veracity" for the nonce-based handshake to enable some hand-on 
experience:ifc	

> https://github.com/fraunhofersit/charra

The next steps are to include more interaction are to include additional 
interaction models for DICE, DAA & TUDA (and corresponding minimal sets 
of elements for network protocols).

Viele Grüße,

Henk

On 15.10.19 17:45, Schönwälder, Jürgen wrote:
> On Mon, Oct 14, 2019 at 11:01:04PM +0000, Dave Thaler wrote:
>>
>> As requested, I have written a document for the WG to consider, that
>> includes my architectural patterns work, plus some content pulled from
>> others' docs.  It's not complete (i.e., some stuff is not covered), but I do
>> hope it's readable by a general audience.
>>
> 
> This document is well readable and the use case examples seem to be
> about right (although it is not entirely clear for all of them how the
> architecture supports them). Dave's document defines fewer terms
> compared to Henk's document and I assume the WG needs to decide what
> the set of terms is that should be defined in the WG's architecture
> document.
> 
> Dave takes a minimalist approach, but then he introduces some terms
> later on in the document (e.g., Endorsement) that may actually belong
> into the terminology section.
> 
> If an Endorsement is a statement, why is it defined under Conceptual
> Messages? I assume messages may carry endorsements.  Perhaps the
> section title "Conceptual Messages" is a bit misleading?  Henk's
> document uses the term 'claim' (which does not really show up in
> Dave's document), as a superclass, i.e., Endorsements and Evidence are
> all forms of Claims (instead of 'Conceptual Messages'). Perhaps Dave's
> 'statements' used informally in the 'Conceptual Messages' section are
> Henk's 'claims' and we need to pick a term and then change the section
> title to 'Types of Claims' or 'Types of Statements' or something like
> that and we likely want to define the concept of a 'Claim' or
> 'Statement'.
> 
> Henk's architecture discusses 'Attestation Principles' that are not in
> Dave's proposal. I guess the WG needs to decide whether to include
> them or not. Are these important for understanding or guiding the RATS
> work?
> 
> I also like to mention that there are research papers where the remote
> attestation process is described more in the form of a challenge
> response interaction, where the verifier sends a specific challenge to
> a device and the device returns a response that is than evaluated by
> the verifier. An example is "compute a hash over certain memory areas
> within a certain time limit" and then the device returns the result
> and the verifier checks whether it is what is expected.  The time
> limit is used to control that an infected device can't reasonably
> forward the challenge to obtain an answer from an unaffected device
> that is then relayed back to the verifier. The question is whether the
> architecture includes models where a stimuli is used to trigger the
> production of a certain Evidence or whether this is left out of the
> architectural picture on purpose. For more details, see for example
> <doi.org/10.1145/2988546> (you will find a preprint if you search).
> 
> /js
> 
>