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

"Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de> Tue, 18 September 2018 12:37 UTC

Return-Path: <andreas.fuchs@sit.fraunhofer.de>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2DD130E02; Tue, 18 Sep 2018 05:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQRi8Id3StsE; Tue, 18 Sep 2018 05:37:45 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A03C130DD7; Tue, 18 Sep 2018 05:37:44 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w8ICbdcN014787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Sep 2018 14:37:40 +0200
Received: from EXCH2010C.sit.fraunhofer.de ([169.254.3.246]) by EXCH2010CAS2.sit.fraunhofer.de ([141.12.84.171]) with mapi id 14.03.0415.000; Tue, 18 Sep 2018 14:37:34 +0200
From: "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>
To: Denis <denis.ietf@free.fr>, "eat@ietf.org" <eat@ietf.org>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] [EAT] Scope, Goals & Background for RATS
Thread-Index: AQHUTzw9348Ry9uliUq0c8+yQH9L36T15lpE
Date: Tue, 18 Sep 2018 12:37:34 +0000
Message-ID: <9F48E1A823B03B4790B7E6E69430724D01426458B6@exch2010c.sit.fraunhofer.de>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de>, <b3aa7b71-a80a-78fc-aef7-fc9145a3169b@free.fr>
In-Reply-To: <b3aa7b71-a80a-78fc-aef7-fc9145a3169b@free.fr>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.12.88.97]
Content-Type: multipart/alternative; boundary="_000_9F48E1A823B03B4790B7E6E69430724D01426458B6exch2010csitf_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/JOCidYuVt8pGbBUyKAz0o18zLqg>
Subject: Re: [EAT] [Rats] Scope, Goals & Background for RATS
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2018 12:37:50 -0000

Hi Denis,

I think that the attestation certificates of FIDO (as far as I understand them from your description) are a prime example for implicite attestation.
Reason: you validate a signature and from the accompanying "shared attestation certificate" you can infer the signing device's property of being a FIDO thingy.
Thus, I'd see this being covered within the current draft, but the charter does not refer to any specific technologies.

Regarding the naming, IMHO we should stick with implicite/explicite attestation, because these are well established terms, other than inferred/direct.
Some evidence on google: https://www.google.com/search?q=Implicit+Attestation vs https://www.google.com/search?q=Inferred+Attestation

The difference between explicite and implicite is also not what you are proposing in you new definitions. To put it is simpler words:
- Explicite is a signature over a statement of claims originating from the platform.
- Implicite is a signature with the augmented information that the private key is usage-restricted to certain claims (e.g. being a FIDO token)

There could be an additional dimension for direct (from the device itself) vs indirect (from a third party, i.e. hear-say) orthogonally to ex-/implicite, leading to the terms explicite direct, explicite indirect, implicite direct, implicite indirect.
I've thought about this in the past, but I did not see practical applications beyond the direct ones. But maybe that would be something to discuss in the formed WG.

Bests,
Andreas

________________________________
From: RATS [rats-bounces@ietf.org] on behalf of Denis [denis.ietf@free.fr]
Sent: Tuesday, September 18, 2018 12:41
To: eat@ietf.org; rats@ietf.org
Subject: Re: [Rats] [EAT] Scope, Goals & Background for RATS

Hi Henk,

I browsed through the document and I am a bit puzzled. I was expecting some words about the attestation certificates that FIDO is using, but I found none.

In FIDO, the concept of an attestation certificate is that a batch of devices from the same model have the same attestation private key and thus the same certificate.

In this WG, such a restriction should not necessarily be made and when the certificate is different for each device model the question is how we should name it.

Let me attempt a proposal:
"shared attestation certificates" to designate attestation certificates that are specific to a batch of devices from the same model (like in FIDO),
"individual attestation certificates" to designate attestation certificates that are specific to each device.
The introduction section states:
Authentication presumes some protection: e.g., that there is not an illicit copy of the private key available to anyone other than the intended subject.
This is insufficient, it also assumes that a legitimate client does not perform all the cryptographic computations that another client needs:
preventing the export of private keys does not prevent a client to use a private key for the benefits of another client.

The background section states:
Generally speaking, attestation is applied before data is exchanged to avoid disclosure to insufficiently trusted environments.
I don't believe so. There is the need to demonstrate that a data exchange really originates from a secure device, acting as a client,
and that that device has some well known properties.

In the terminology section, I would expect to find a definition for an attestation certificate.

I read the definition of an "Attestation Evidence" in the terminology section several times and I have difficulties to understand it.
I wonder if such a concept really exists. In particular, within this definition, the text states:
Attestation Evidence veracity may be augmented by Claimant signatures over portions of the Attestation Evidence.
I don't believe so.  If I am assuming the use of Attestation Certificates, there is an attestation private key associated to the public that is in it.
The authentication exchange performed by a client should be counter-signed by the attestation private key corresponding to the public key
placed within the Attestation Certificate.

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.

I could not understand either the value of local attestations. IMO, the WG should only focus on remote attestations.

Finally, the following invitation was raised:
Naturally, we are also very interested in feedback about the illustrated difference between explicit attestation and implicit attestation.
The current definition for Explicit Attestation is:
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.
The current definition for Explicit Attestation is:
Implicit Attestation is where the Attester conveys evidence of the availability of an authenticating credential that allows the Verifier
to infer the Attestation Claims/Evidence associated with an execution environment. The Verifier knows that the availability of
the authenticating credential is bound to certain Attestation Claims/Evidence. Inferred knowledge may further be conveyed as Attestation Evidence
by a Trusted Third Party via a credential certificate or other out-of-band method.
It is quite hard to understand the concept since three sentences are being used.
Let me attempt to define a different but, maybe, close concept:
Inferred Attestation is when a Trusted Third Party (TTP) testifies to a verifier that some data originating from a client originated in practice from a secure device
that has specific functional and security properties.
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