Re: [EAT] {RATS] Introduction

"Eric Voit (evoit)" <> Wed, 12 September 2018 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3964D130EC9; Wed, 12 Sep 2018 13:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h83sDpR-zfTW; Wed, 12 Sep 2018 13:17:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5158130EBC; Wed, 12 Sep 2018 13:17:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=19626; q=dns/txt; s=iport; t=1536783445; x=1537993045; h=from:to:cc:subject:date:message-id:mime-version; bh=ZckqLL7ix42wfuLeBX2Vv3wfFZ4pC5BHAjedMSA5ubs=; b=cmc3ErqGdgG8X1T9dD3d7xt3Ggr9uJKQEYUYC6EPilijiornD32ydEq/ EfC/zMh4Z9jr22CU8EVLxrh0fk1aw8siPG6PMXkC/m4wJnbPQWulkKl04 DmxiNuiHklItbZVXM6n8SG+0dkavp44W+mqKrJtC8nKa+1Y4Iz/N1Hh3/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AAB5c5lb/49dJa1GFhkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGBToERd2V/KAqDaIgVjimRCIU1FIFmC4RsAheDNiE0GAE?= =?us-ascii?q?CAQECAQECbSiFOAEDAyMKTBIBBgIRAwECFAISAwIEMBQJCQEEAQ0FCIMagR1?= =?us-ascii?q?kihSbS4Euig+KWA8XgUE/gRKDEoMbBIEaAgEsAjQWCYJCglcCjTiOGU8JApA?= =?us-ascii?q?AH457k3kCERSBJR04gVVwFYMnkFNvAYwwgS2BHgEB?=
X-IronPort-AV: E=Sophos;i="5.53,366,1531785600"; d="scan'208,217";a="441098095"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2018 20:17:24 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w8CKHNWX005217 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Sep 2018 20:17:24 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Sep 2018 16:17:23 -0400
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Wed, 12 Sep 2018 16:17:23 -0400
From: "Eric Voit (evoit)" <>
To: Carl Wallace <>, Shawn Willden <>, "Smith, Ned" <>
CC: "" <>, "" <>
Thread-Topic: {RATS] [EAT] Introduction
Thread-Index: AdRK1ZstPcHxxutnT72dokwlGBYmnw==
Date: Wed, 12 Sep 2018 20:17:23 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_c307729682c24fd18aea18551c2233ffXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [EAT] {RATS] Introduction
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Sep 2018 20:17:29 -0000

I think saving both the attestation data and the attested evidence is useful.  One RATS use case I have been interested in relates to proxy verification.  For example, what if changes in attested PCRs from one router’s TPM are provided both to an SDN controller (as part of a YANG Notification) and to a peer router (perhaps as EAP credentials over 802.1x).

This would allow the controller to use the same information to determine if a controlled device is trustworthy, as well as act as a RADIUS Server for the peer router.


From: Carl Wallace, September 7, 2018 7:55 AM

This gets at one difference between current attestation formats. Some require the generator to save the attestation if needed later, others are on demand.

From: EAT <<>> on behalf of Shawn Willden <<>>
Date: Friday, September 7, 2018 at 7:45 AM
To: "Smith, Ned" <<>>
Cc: "<>" <<>>
Subject: Re: [EAT] Introduction

Proof of protection is a good description of what Keystore attestation aims to accomplish, and timeliness or "freshness" is important.  Keystore achieves the latter with a challenge value supplied by the verifier.

On Thu, Sep 6, 2018 at 6:21 PM Smith, Ned <<>> wrote:
|--- snip ---
|So Keystore provides a valuable tool to authors of apps that require strong
|security. For example, for a key used to authenticate an account holder to
|a banking system. But this tool is much less valuable if the bank's server
|can't verify that the secret is managed in a trusted environment. Hence,
|Keystore attestation, which allows the trusted environment to prove that it
|secures the key material, and specifies the authorizations that define how
|it may be used.
--- snip ---
Right, the main objective of attestation is to provide evidence to a verifier regarding the trustworthiness properties of the environment that protects keys and other important things. It goes beyond traditional proof-of-possession.. I think of it as proof-of-protection (PoPr) though that term isn’t widely used. Distinguishing between storage and use may be important since protection techniques differ for each. At the end-of-the-day, attestation expects there is a ‘verifier’ – some entity that wants to check attestation evidence – who engages with the ‘attester’ following some sort of protocol to pass attestation evidence. Timeliness of evidence exchange can be important since, often, environments that protect key storage and use will change during deployment (after initial manufacturing). Attestation protocol is needed to facilitate a timely exchange of attestation evidence. I think these aspects are a primary area where IETF could add value to attestation infrastructure.