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

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 18 September 2018 18:10 UTC

Return-Path: <evoit@cisco.com>
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 31346130E9C; Tue, 18 Sep 2018 11:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 dk2Ix13S6wps; Tue, 18 Sep 2018 11:10:27 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0C0130E95; Tue, 18 Sep 2018 11:10:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31716; q=dns/txt; s=iport; t=1537294227; x=1538503827; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fwVhUAox/rBqC5pkb4GQw44+xsRZageOxLJxjFpdJ2g=; b=Pe4mQZ2rDOS4qN8yqvwZ5Js+cwlMmSt0wqjqWxQ0MTFZNaSa4WdRyj2/ dGZmZuAx1+6WrhhhByy8fn4ok2b014KbSZG8j3eQ7G3PpQhyO0LESCEbb KusJL+VsX5T2efdIAR9bDZHhrOZ2aj93PPFTibHaEaBBogzYEaVjkcZvJ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AAAfP6Fb/4wNJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYFSgQ93ZX8oCoNolESCDXiVVIF6CxgBCoRJAheDDyE2FgEDAQE?= =?us-ascii?q?CAQECbRwMhTgBAQEEAQEhCkELEAIBBgIVIwcDAgICJQsUEQIEDgUIgxqBHWQ?= =?us-ascii?q?PiTObTIEuH4loBYpeDxeBQT+BEoJdNYMbAQGBS0yCS4JXAogZhTwTjhpPCQK?= =?us-ascii?q?GQIJLOYZTH4FDh0+GAotriFgCERSBJSQOI4FVcBU7gmyGAYUUhT5vjCmBHgE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.53,390,1531785600"; d="scan'208,217";a="453858565"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2018 18:10:25 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id w8IIAPCS012379 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Sep 2018 18:10:25 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Sep 2018 14:10:20 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1395.000; Tue, 18 Sep 2018 14:10:20 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Denis <denis.ietf@free.fr>
CC: "eat@ietf.org" <eat@ietf.org>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [EAT] Scope, Goals & Background for RATS
Thread-Index: AQHUTyma541566FR7EiNVFRYq9/1R6T2HSEAgAAw5zA=
Date: Tue, 18 Sep 2018 18:10:20 +0000
Message-ID: <02b725bf46174a14bae86ae54424d5d3@XCH-RTP-013.cisco.com>
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
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.234]
Content-Type: multipart/alternative; boundary="_000_02b725bf46174a14bae86ae54424d5d3XCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/aaV5tTNe7rG4yJtiLPDa2Gy1PqE>
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 18:10:31 -0000

Hi Denis,

On the exchange below...

Henk >> Generally speaking, attestation is applied before data
Henk >> is exchanged to avoid disclosure to insufficiently trusted environments.

Denis > I don't believe so. There is the need to demonstrate that a data exchange
Denis > really originates from a secure device, acting as a client,
Denis > and that that device has some well known properties.

For attestation on a router/switch, some people treat the router/switch as only partially trusted.  With such an approach, certain attested PCRs will only be updated by restricted/protected root-of-trust-for-measurements, and perhaps only when certain conditions are met.

Such an approach allows us freedom to use resulting signed TPM quotes many ways.  We could use these quotes for local router/switch attestation (perhaps out of scope).  We could also pass the quotes to an SDN controller (which is in scope).

While I do agree that we need to ensure that the originating device of attested evidence is the same as the generating device, it is important to define attested data independent of device or client/server boundaries.

Eric

From: Denis, September 18, 2018 6:42 AM

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