Re: [Rats] Use case -> architecture document

[Schönwälder, Jürgen <[e-mail]>]

Henk,

I prefer having all relevant interaction models in the architecture.

Looking at your architecture draft and "attestation characteristics"
(aka attestation principles), then I am not sure I do understand all
definitions. For me, 'relevance' seems somewhat unclear. Should such
terms be defined in an architecture doccument? Probably yes if they
are fundamental for understanding the technology and not covered by
generally known security terminology.

/js

On Sun, Nov 03, 2019 at 07:37:04PM +0100, Henk Birkholz wrote:
> Hi Jürgen,
> 
> in the RATS WG we split that specific challenge/response interaction (there
> are others, but this is the best understood one) out into this document:
> 
> > https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/
> 
> An complementary approach was recently introduced here:
> 
> > https://datatracker.ietf.org/doc/draft-xia-rats-pubsub-model/
> 
> Both types of (and by inference - all) interaction adhere to the same
> "attestation principles" (which we are currently relabeled to "attestation
> characteristics" but this is more a matter of finding the most intuitive
> title here), which are included in one of the architecture documents.
> 
> I think you highlighted a good question that we should put to a call for
> consensus: Are attestation characteristics, such as freshness, provenance
> (often referred to as origination), or veracity defining (or vital) concepts
> for remote attestation procedures so that they belong into the architecture
> document?
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 
> On 15.10.19 17:45, Schönwälder, Jürgen wrote:
> > 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).

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>