Re: [EAT] Scope, Goals & Background for RATS

[nms] See my comments inline. - Ned.

On 9/18/18, 3:42 AM, "EAT on behalf of Denis" <eat-bounces@ietf.org<mailto:eat-bounces@ietf.org> on behalf of denis.ietf@free.fr<mailto:denis.ietf@free.fr>> wrote:

Hi Henk,

[nms]--- some text deleted ---

In the background section, the concept of a remote attestation is the following:

Remote Attestation is where the Attester conveys Attestation Evidence to a Verifier that compares it with Reference Values
(in order for it to be considered, for example, healthy). A Relying Party (or the Verifier acting as a Relying Party) appraises the verification result
to assess device trustworthiness and to manage security risk.
Since I could not grasp the concept of Attestation Evidence, I couldn't grasp the concept of a Remote Attestation which is based on it.
The goal is not simply to "assess device trustworthiness" but to make sure that some data exchange is really coming from a device
that has specific properties. Such properties are going beyond the protection, the non-export and the non-import of private keys.
[nms]The concept of associating security properties to data is described in more detail in https://datatracker.ietf.org/doc/draft-birkholz-attestation-terminology/ We struggle with knowing how much terminology to include in a charter vs. save for a terminology draft. The basic idea is data inherits security properties of the environment (loosely defined term) that contains it. Sometimes people describe a communication path as a channel with ‘endpoints’. Lots of environments can be an ‘endpoint’ and endpoints have data-at-rest security properties. A goal of attestation should be to communicate the security properties of the endpoint that originated the data in the channel. Additionally, the channel has data-in-motion security properties. Often these properties are defined in terms of cryptography. A consideration for data-in-motion extends to the endpoint environment that protects the keys. These are subtly different concepts that could be conflated if our terminology is imprecise. In terms of the charter discussion, attestation of the endpoint environment that encompasses data-at-rest as well as endpoint environments that encompass keys used to protect data-in-motion are relevant to ‘remote attestation’.

I could not understand either the value of local attestations. IMO, the WG should only focus on remote attestations.
[nms] I believe the charter focus is only remote attestation. Local attestation is (should be) out of scope. Note: Since the charter distinguishes a focus on remote attestation it becomes necessary to acknowledge the existence of local attestation.
[nms]--- some text deleted ---
Explicit Attestation is where the Attestation Claims/Evidence is conveyed authentically (e.g. signed) by the Attester to the Verifier
where a root-of-trust enumerates the Attestation Claims/Evidence associated with an execution environment.
I would rephrase it in the following way:
Direct Attestation is when a verifier can be confident that some data originating from a client originates in practice from a secure device
that has specific functional and security properties.
[nms] It may be important to avoid overloading terminology too much as there already is a term “direct anonymous attestation” (DAA) that refers to a group signature scheme that is also an ISO standard.
[nms]--- some text deleted ---

Denis
Hi all,

we pushed an initial document to the RATS github in order to focus the discussion about remote attestation procedures a bit.

https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md

We included a background section to better highlight the meaning of the term "attestation" in general. Hence, there is a trade-off between clarity and conciseness, which is one of the things we would like to get feedback about.

Naturally, we are also very interested in feedback about the illustrated difference between explicit attestation and implicit attestation.

Viele Grüße,

Henk

_______________________________________________
EAT mailing list
EAT@ietf.org<mailto:EAT@ietf.org>
https://www.ietf.org/mailman/listinfo/eat