IETF Logo Mail Archive

Re: [Rats] Two types of secure attestation

Laurence Lundblade <lgl@island-resort.com> Sat, 23 November 2019 16:44 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5275B120827 for <rats@ietfa.amsl.com>; Sat, 23 Nov 2019 08:44:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 BPKWRfZgXV-O for <rats@ietfa.amsl.com>; Sat, 23 Nov 2019 08:44:08 -0800 (PST)
Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (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 102EF12081A for <rats@ietf.org>; Sat, 23 Nov 2019 08:44:08 -0800 (PST)
Received: from [10.86.0.74] ([45.56.150.43]) by :SMTPAUTH: with ESMTPA id YYVzi6w0eVvPWYYVzi8PG6; Sat, 23 Nov 2019 09:44:07 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <A9E1ED3A-80D1-4585-9029-A49CA5AE3AB6@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6EB700B8-AEAB-4397-823F-810217BE55C4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 23 Nov 2019 08:44:06 -0800
In-Reply-To: <def7a722-e357-a12a-1467-8ff8c442337e@sit.fraunhofer.de>
Cc: "rats@ietf.org" <rats@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "Smith, Ned" <ned.smith@intel.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
References: <B099349B-711D-4A11-9E58-0886307FB7AF@island-resort.com> <CAHbuEH6qtVbzRXUALKBrr3butc8qT8Y81X-nQ6+PjC1n08CkvA@mail.gmail.com> <5DB30E08-9AB2-452A-B8D6-55BFD0AE5264@island-resort.com> <CAHbuEH4R4GZQCq9E1Nza8uPC=jxiM-FkV4tMrv9B==GsjvCLtw@mail.gmail.com> <34EB67FD-E76A-4132-87C4-C89EA70C9365@intel.com> <DC9F1051-E33A-477F-A855-2FBA33F8E8DF@island-resort.com> <cbb5f662-b073-5b5b-e504-56ea66b72744@sit.fraunhofer.de> <5A3105EA-8E54-4BB9-B266-96B6645811A1@island-resort.com> <c4967ed2-e484-d8c9-406b-8e1bb1b3b88d@sit.fraunhofer.de> <FF6F2CEE-1049-4B6C-8E12-9E21FE92D2F2@island-resort.com> <3285c3da-0748-5607-90ed-ac024ac826d0@sit.fraunhofer.de> <0384FAEE-6C5B-4A99-BBA0-F080DD27AA9B@island-resort.com> <def7a722-e357-a12a-1467-8ff8c442337e@sit.fraunhofer.de>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfLuFRMuWylAqMhOJlI2uGYkSxR5PWVyhVzSnvxkZW8obtZEXEbMeTHCMyA6Tl8ymF106LleFJqhFPx4bk6RaUU5/h8G3FGzrMDy4c91ps/nYU6sNf0N1 f71RCYdCGA3+l3rOVpjtOGFk3qwzRcbe+Uar53zrVASmeWUZm6tMJCxDxq0hlXnS4ldIsk+odJJN4IND1vsD29YBfUifFXOYGjIo5b22i4IiyKZ+sYl7WlnV xYpyKrwoiDjRxazsWqXRQTEfsCTUspgNu8vBB+iFWmnJY89if2zkS37Q6LFfcxXp
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/v2TBxcpY4Dl-eFcTAjPVSkI6uY8>
Subject: Re: [Rats] Two types of secure attestation
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Nov 2019 16:44:09 -0000

> On Nov 21, 2019, at 6:26 PM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
> 
> There are no semantic difference between the "simple non-TPM EAT" scenario and the TPM-based implicit remote attestation scenario. They are if fact the "same types of secure attestation”.


I don’t have any need to drive taxonomic distinction when unnecessary, but note that the YANG module has to have explicit different facilities to be able to handle both.

The verifier implementations for these two types are also very different. in the "non-TPM EAT” scenario no known-good-values for SW hashes are need to be supplied to the verifier.

I don’t think these are the only differences that we’ll encounter in real implementations. 

This should probably all be described the architecture document. Seems as significant as the passport vs background check distinction.

LL

v2.23.0 | Report a Bug | By Email