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 >
- [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Denis
- Re: [EAT] [Rats] Scope, Goals & Background for RA… Fuchs, Andreas
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Denis
- Re: [EAT] Scope, Goals & Background for RATS Carsten Bormann
- Re: [EAT] Scope, Goals & Background for RATS Michael Richardson
- Re: [EAT] Scope, Goals & Background for RATS Michael Richardson
- Re: [EAT] Scope, Goals & Background for RATS Eric Voit (evoit)
- Re: [EAT] Scope, Goals & Background for RATS Carsten Bormann
- Re: [EAT] Scope, Goals & Background for RATS Melinda Shore
- Re: [EAT] Scope, Goals & Background for RATS Smith, Ned
- Re: [EAT] Scope, Goals & Background for RATS Laurence Lundblade
- [EAT] Implicit vs Explicit Attestation (was Re: S… Laurence Lundblade
- Re: [EAT] Scope, Goals & Background for RATS Diego R. Lopez
- [EAT] Terminology definitions (was Re: Scope, Goa… Laurence Lundblade
- Re: [EAT] Terminology definitions (was Re: Scope,… Henk Birkholz
- Re: [EAT] Implicit vs Explicit Attestation (was R… Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] [Rats] Terminology definitions (was Re:… Smith, Ned
- Re: [EAT] Scope, Goals & Background for RATS Laurence Lundblade
- Re: [EAT] Scope, Goals & Background for RATS Henk Birkholz
- Re: [EAT] Scope, Goals & Background for RATS Diego R. Lopez
- Re: [EAT] Implicit vs Explicit Attestation (was R… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Fuchs, Andreas
- Re: [EAT] Implicit vs Explicit Attestation (was R… Henk Birkholz
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Wheeler, David M
- Re: [EAT] Implicit vs Explicit Attestation (was R… Laurence Lundblade
- Re: [EAT] [Rats] Implicit vs Explicit Attestation… Smith, Ned
- [EAT] Naming (was Re: Scope, Goals & Background f… Laurence Lundblade
- [EAT] EAT additions to Charter (was Re: Scope, Go… Laurence Lundblade
- Re: [EAT] EAT additions to Charter (was Re: Scope… Suresh Marisetty
- Re: [EAT] Naming (was Re: Scope, Goals & Backgrou… Diego R. Lopez
- Re: [EAT] EAT additions to Charter (was Re: Scope… Carl Wallace
- Re: [EAT] Naming (was Re: Scope, Goals & Backgrou… Laurence Lundblade