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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 18 September 2018 14:18 UTC

Return-Path: <henk.birkholz@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 D60CB130E1B; Tue, 18 Sep 2018 07:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q47BSK7RJ-yD; Tue, 18 Sep 2018 07:18:13 -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 8507912777C; Tue, 18 Sep 2018 07:18:10 -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 w8IEI7W3018296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Sep 2018 16:18:08 +0200
Received: from [134.102.164.33] (134.102.164.33) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 18 Sep 2018 16:18:02 +0200
To: Denis <denis.ietf@free.fr>, <eat@ietf.org>, <rats@ietf.org>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <b3aa7b71-a80a-78fc-aef7-fc9145a3169b@free.fr>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <17ba2709-0a0e-859f-2fa2-fd09747273d9@sit.fraunhofer.de>
Date: Tue, 18 Sep 2018 16:18:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <b3aa7b71-a80a-78fc-aef7-fc9145a3169b@free.fr>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.164.33]
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/XwgqUwFqxcPqeuiftC6A1ZnzJb0>
Subject: Re: [EAT] 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 14:18:16 -0000

Hi Denis,

there are a lot of topics addressed by your reply. First of all, thank 
you for the the feedback!

We attempted to create a document that is as inclusive as possible - 
within reason. Hence, it is also solution agnostic.

As Andreas just said, Proof-of-Possession of a secret key is intended to 
be captured by Implicit Attestation. In other words: if you are able to 
use that secret key to sign something, it implies (that is the 
"implicitness" here) that "that device has some well known properties".
The definition of implicit attestation might require some improvement, I 
assume (and I don't mean by adding even more words).

I am a bit confused by the use of "attestation certificate", "private 
key" and "origin of data exchange" in your reply.

If "certificate" in your 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.

means identity document, the concepts of "Singular Identity", "Shared 
Identity", and "Group Identity" are already subsumed in the IETF by the 
definition of "Identity" in RFC4949. Maybe that fact is a little bit too 
hidden at the end of the Background section that refers to 
"cryptographic identities". Highlighting that more up front and 
referencing RFC4949 explicitly could address that issue.

Correspondingly, the same secret key can be enrolled on multiple 
devices, but that is not the same thing as enrolling the same 
(group/shared) identity document on multiple devices.

The smallest identity document I can think of would be a signed public 
key. More commonly today, it would be an ASN.1-based identity document, 
I assume.


Jumping a bit to the end:

Local Attestation is described in the Background section and is referred 
to again in the Scope section as out-of-scope.
That said, as Local Attestation can be a prerequisite for Remote 
Attestation and it also might require some provisioning (via network 
protocols) in order to work, provisioning protocols that enable local 
attestation are currently considered in-scope.

The fact that the definition of Attestation Evidence is difficult to 
understand could be the biggest issue here, I think. Especially, because 
it is the basis for the definition of Remote Attestation, as you 
highlighted. I will come back to this topic as soon as I have a few more 
free cycles :)

Viele Grüße,

Henk


On 09/18/2018 12:41 PM, Denis wrote:
> 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
>> https://www.ietf.org/mailman/listinfo/eat
> 
> 
> 
> 
> _______________________________________________
> EAT mailing list
> EAT@ietf.org
> https://www.ietf.org/mailman/listinfo/eat
>