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

Denis <denis.ietf@free.fr> Tue, 18 September 2018 15:56 UTC

Return-Path: <denis.ietf@free.fr>
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 36468130E3B; Tue, 18 Sep 2018 08:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 DNVEZOIL34sZ; Tue, 18 Sep 2018 08:56:23 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 B72D2130E18; Tue, 18 Sep 2018 08:56:22 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 92056780306; Tue, 18 Sep 2018 17:56:20 +0200 (CEST)
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, eat@ietf.org, rats@ietf.org
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <b3aa7b71-a80a-78fc-aef7-fc9145a3169b@free.fr> <17ba2709-0a0e-859f-2fa2-fd09747273d9@sit.fraunhofer.de>
From: Denis <denis.ietf@free.fr>
Message-ID: <67234e9e-1543-5ecb-7fd8-3797d529744c@free.fr>
Date: Tue, 18 Sep 2018 17:56:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <17ba2709-0a0e-859f-2fa2-fd09747273d9@sit.fraunhofer.de>
Content-Type: multipart/alternative; boundary="------------061B7B95CBB06C9D54CE5451"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/_rvNN4emZLX1LTI1rhF4ZVPdmSw>
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 15:56:27 -0000

Hi Henk,

I fear that we don't understand each other.

> 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".

No. If you are able to use a secret key to sign something, it does not 
mean that you are using a device.
If a device is able to sign something, it does not necessarily mean that 
what is signed really comes from the device, unless "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.

It does not mean anything from the above list. My arguments have nothing 
to do with "Identity". Typically, an Attestation Certificate it is an 
X509 certificate, as in FIDO.

>
> 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 private key of a device is never enrolled but is placed in the 
device by the manufacturer of the device (or the entity that 
personalizes it before making it available to an end-user);

>
> 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.

My arguments are fully unrelated to "identity documents".

> 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.

This is fine.

> 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

Denis

>
>
> 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
>>