Re: [EAT] Introduction

Carl Wallace <carl@redhoundsoftware.com> Fri, 07 September 2018 11:55 UTC

Return-Path: <carl@redhoundsoftware.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 2A17B130DD5 for <eat@ietfa.amsl.com>; Fri, 7 Sep 2018 04:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 S_aGlHiwkACP for <eat@ietfa.amsl.com>; Fri, 7 Sep 2018 04:55:22 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6AB1128CF2 for <eat@ietf.org>; Fri, 7 Sep 2018 04:55:21 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id o15-v6so15871756qtk.6 for <eat@ietf.org>; Fri, 07 Sep 2018 04:55:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=PpWW2w4qyygiQS+Ogu0iibroKNwtwxT86fwgufraNvo=; b=Z95kwnd9PYRkfME1yk62uhkcJZ3Q6cZtUjLhZ5AKE86zINUwBEZ2YFqAC5izKhjuDm uOBEKXUxdmobperl1aXdOZobOA2RkWkkRUg8kh1kmgMHKgcPib4DzxPUl4ShuWo8Sjzp fZp1K4ITH8dvIYBi4GZTvAu2OQ1nD1leNRSBM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=PpWW2w4qyygiQS+Ogu0iibroKNwtwxT86fwgufraNvo=; b=WdK29hvVXqC0QoReNF1cDVv1XNVDhTJHAPe52dCzaM98YpOyQeHHV5op7egdTD0k8v VanEFoZ/zRxsgFIJwDzqJbmXwHeimnZLwOC8p99mNLzXyJrlwFaB1xB47Cr2OeJXO3LG j/MFMxiP1HiL5zzv+noxvqIwE27s08yUj6r16zuiRcIHoo4rhttvZkKZMe9AFixHOJ+Z eRDTGvjAh14oaQWHq/i+o6seKuKSIyuf+erSR7QxdQfvPejDVVrPll0wAFpaSr90XLyN wgIxduuBx/FdHgYcnh92NrLbgpQP3vhDpJncJ8zPlPSEns6ocWbqAEPWDNgnNeB7rosJ 9qUQ==
X-Gm-Message-State: APzg51BCaf4P42d+ci7sYDrUqcOr07Poww3wY78+9cYqCDH4TDEzNicd Fao10959HVpvwR4Wp/wUR4bkwQ==
X-Google-Smtp-Source: ANB0VdaRBzx/jD87Oh6u2tN6+gQUzxd/maXciSCmf24OOqhqO5M9waZCBJMq1r9cEiG6NmJ9CHo4HQ==
X-Received: by 2002:ac8:2ffa:: with SMTP id m55-v6mr5852016qta.202.1536321320929; Fri, 07 Sep 2018 04:55:20 -0700 (PDT)
Received: from [192.168.2.246] (pool-108-28-91-61.washdc.fios.verizon.net. [108.28.91.61]) by smtp.googlemail.com with ESMTPSA id x14-v6sm4027503qkf.59.2018.09.07.04.55.17 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 07 Sep 2018 04:55:19 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Fri, 07 Sep 2018 07:55:14 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Shawn Willden <swillden=40google.com@dmarc.ietf.org>, "Smith, Ned" <ned.smith@intel.com>
CC: "eat@ietf.org" <eat@ietf.org>
Message-ID: <D7B7DF47.C074A%carl@redhoundsoftware.com>
Thread-Topic: [EAT] Introduction
References: <C5900D6C-256C-409C-AEA1-407AD1EF4FEF@contoso.com> <CAFyqnhUmbhccX+VwTm1A+dOe0Nfk=kKzQDznhGB+minuDdC-ow@mail.gmail.com>
In-Reply-To: <CAFyqnhUmbhccX+VwTm1A+dOe0Nfk=kKzQDznhGB+minuDdC-ow@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3619151718_13066425"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/61cWm6byj-9tItyjUIi3PyGsCJk>
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 11:55:26 -0000

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 <eat-bounces@ietf.org> on behalf of Shawn Willden
<swillden=40google.com@dmarc.ietf.org>
Date:  Friday, September 7, 2018 at 7:45 AM
To:  "Smith, Ned" <ned.smith@intel.com>
Cc:  "eat@ietf.org" <eat@ietf.org>
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 <ned.smith@intel.com> 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.
>> _______________________________________________
>> EAT mailing list
>> EAT@ietf.org
>> https://www.ietf.org/mailman/listinfo/eat
> -- 
> Shawn Willden | Staff Software Engineer | swillden@google.com | 801-477-4296
> _______________________________________________ EAT mailing list EAT@ietf.org
> https://www.ietf.org/mailman/listinfo/eat