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, 07 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
- [EAT] Introduction Shawn Willden
- Re: [EAT] Introduction Smith, Ned
- Re: [EAT] Introduction Suresh Marisetty
- Re: [EAT] Introduction Shawn Willden
- Re: [EAT] Introduction Shawn Willden
- Re: [EAT] Introduction Carl Wallace
- Re: [EAT] Introduction Carsten Bormann
- Re: [EAT] Introduction Shawn Willden
- Re: [EAT] Introduction Shawn Willden
- Re: [EAT] [Rats] Introduction Ira McDonald
- Re: [EAT] Introduction Laurence Lundblade
- Re: [EAT] [Rats] Introduction AndreRein
- Re: [EAT] [Rats] Introduction Laurence Lundblade
- Re: [EAT] [Rats] Introduction Henk Birkholz
- Re: [EAT] [Rats] Introduction Michael Richardson