Re: [EAT] Introduction

"Smith, Ned" <ned.smith@intel.com> Fri, 07 September 2018 00:21 UTC

Return-Path: <ned.smith@intel.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 BA190130F73 for <eat@ietfa.amsl.com>; Thu, 6 Sep 2018 17:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Cw-XS11SsnOP for <eat@ietfa.amsl.com>; Thu, 6 Sep 2018 17:21:51 -0700 (PDT)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 A4175130F7C for <eat@ietf.org>; Thu, 6 Sep 2018 17:21:51 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2018 17:21:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.53,340,1531810800"; d="scan'208,217"; a="68998474"
Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga008.fm.intel.com with ESMTP; 06 Sep 2018 17:21:43 -0700
Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 6 Sep 2018 17:21:42 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.80]) by ORSMSX158.amr.corp.intel.com ([169.254.10.59]) with mapi id 14.03.0319.002; Thu, 6 Sep 2018 17:21:42 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [EAT] Introduction
Thread-Index: AQHURkDAuA2UbpbZR0GK333YO0C7LQ==
Date: Fri, 07 Sep 2018 00:21:42 +0000
Message-ID: <C5900D6C-256C-409C-AEA1-407AD1EF4FEF@contoso.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-originating-ip: [10.252.200.249]
Content-Type: multipart/alternative; boundary="_000_C5900D6C256C409CAEA1407AD1EF4FEFcontosocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/G5WvKAAXc16ixn30MbcfErLmUQ4>
Subject: Re: [EAT] Introduction
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: Fri, 07 Sep 2018 00:21:54 -0000

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