Re: [EAT] Introduction

Shawn Willden <swillden@google.com> Fri, 07 September 2018 13:49 UTC

Return-Path: <swillden@google.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 EDCFC130E10 for <eat@ietfa.amsl.com>; Fri, 7 Sep 2018 06:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.712
X-Spam-Level:
X-Spam-Status: No, score=-16.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 nNo4NrHMvpAq for <eat@ietfa.amsl.com>; Fri, 7 Sep 2018 06:49:25 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 2B3EF130E04 for <eat@ietf.org>; Fri, 7 Sep 2018 06:49:25 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id m26-v6so12113587lfb.0 for <eat@ietf.org>; Fri, 07 Sep 2018 06:49:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PguI4Rcyu+6FAxIMIo5TVjPP9RhH8A3vVkr18kk1cuI=; b=EhUyv7WLGI9ec5iuR1IY9hUBF/6BJN2Tv+qgg47MKlcwYekV8D9GLPQNJ+e0VLbRV0 Rw0t4qh5HqzNKLiioUQ4d//AVfYNYwozzg05IWRnmqZpHkA9nuFPAEAROJ6AOPfRs456 Y+n8PNMWteLD9UdAf0wxQQANDyQ45J3rbef5BTVfZqjy6gLFH/WZgr9Ayw2Z1vwbLWBz EE1Fuxm0YI0KI2cHBwg+8F7hGInJBqFcMWQKy5iT1/I/enBt+PmIystcg0CKRRgDliTm HtoxECxjn93XQG13zIuQleET6YCXTtraCRKvMi2h+07k8eOUoFQMf+IqILp/cobFzJRW 5Vcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PguI4Rcyu+6FAxIMIo5TVjPP9RhH8A3vVkr18kk1cuI=; b=n5rALNSjVE9gtKtpoUVTPYR9Qh3Cb2uGWqvPpA6Rkah/YDnUoIhKNpmVRHgSq+M4dt UHJ5KXlPvEy3EtRJhLMUdEBcpSZiQfkoxRe6pony3tYNMELuwEvN+RLNOo9V7+XFNngZ KdUbXSSsKL0YeB0dCxH7muBUUvPvu+aZRx2WTvcmDQASCBDkqcc2mn4lZNnYC+Qlj1lD iDcZda0mto4Xb6MnfbAquvWGE3wW8QGiXSX+B/n8rJJQ+BLs2NK1ayQV97kTW7kIEHj+ 4+6tUQ5HuQuMLgh3EtSlChKNlYV4qv4ONF5cVsvYLG0+EoAelR8Qv08+Y/XZovNVHQ0I vUEQ==
X-Gm-Message-State: APzg51AhkBfCw7sYCLNF1S25OcBgVFedXbkayd/2n9xm6S0eyEWPIDHR hrohZbvi0GGtEyh04OmVxiXu07GXyh2dCROI9bmU+g==
X-Google-Smtp-Source: ANB0Vdb09EBrzhRN+B67mNhp5nljStL39YK2VdZJoSTqcFVGJrsTioELOfCpMvT2yNgwbM6pAEXsG+YeCr2cskJQds8=
X-Received: by 2002:a19:5410:: with SMTP id i16-v6mr5069032lfb.122.1536328162896; Fri, 07 Sep 2018 06:49:22 -0700 (PDT)
MIME-Version: 1.0
References: <C5900D6C-256C-409C-AEA1-407AD1EF4FEF@contoso.com> <CAFyqnhUmbhccX+VwTm1A+dOe0Nfk=kKzQDznhGB+minuDdC-ow@mail.gmail.com> <D7B7DF47.C074A%carl@redhoundsoftware.com>
In-Reply-To: <D7B7DF47.C074A%carl@redhoundsoftware.com>
From: Shawn Willden <swillden@google.com>
Date: Fri, 7 Sep 2018 07:49:10 -0600
Message-ID: <CAFyqnhWC-eh+Q=2ZFyGvTUU8drLpZ1HXe-Y6UN=QXskLtCzjBQ@mail.gmail.com>
To: Carl Wallace <carl@redhoundsoftware.com>, rats@ietf.org
Cc: "Smith, Ned" <ned.smith@intel.com>, "eat@ietf.org" <eat@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006915780575484632"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/DLhm7QsThVrdKUBtsabpytArymk>
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 13:49:28 -0000

+rats@ietf.org <rats@ietf.org>

On Fri, Sep 7, 2018 at 5:55 AM Carl Wallace <carl@redhoundsoftware.com>
wrote:

> 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 <eat-bounces@ietf..org>> on behalf of
> Shawn Willden <swillden=40google.com@dmarc.ietf..org
> <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 <(801)%20477-4296>
> _______________________________________________ EAT mailing list
> EAT@ietf.org https://www.ietf.org/mailman/listinfo/eat
>
> --
Shawn Willden | Staff Software Engineer | swillden@google.com | 801-477-4296