Re: [EAT] [Rats] Attestation BoF charter updates?

"Smith, Ned" <ned.smith@intel.com> Tue, 23 October 2018 17:10 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 5913E130E2B; Tue, 23 Oct 2018 10:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 9xZaN_6Uk7Fs; Tue, 23 Oct 2018 10:10:34 -0700 (PDT)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 05CA6130F74; Tue, 23 Oct 2018 10:10:33 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 10:10:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.54,416,1534834800"; d="scan'208,217";a="101798394"
Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga001.fm.intel.com with ESMTP; 23 Oct 2018 10:10:33 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.251]) by ORSMSX101.amr.corp.intel.com ([169.254.8.122]) with mapi id 14.03.0319.002; Tue, 23 Oct 2018 10:10:33 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUat5gF5XODrEVOE6MFEmu1KniJaUtENuA
Date: Tue, 23 Oct 2018 17:10:32 +0000
Message-ID: <048076C6-C8C4-4F14-961C-C990F154E174@intel.com>
References: <5D773C02-5083-4B10-A705-782E28FD8ADB@island-resort.com> <f84515dd-2e1a-7e66-7c23-b16f8f425d2a@sit.fraunhofer.de> <3347AA26-3FA1-4067-8378-51B533BA77FB@island-resort.com> <570FEF0C-FD3A-4EBF-B8E6-7B13D2FD8E22@qti.qualcomm.com> <7544.1540242117@localhost> <46150D67-97E7-457F-9C8B-D2B3060978CA@qti.qualcomm.com>
In-Reply-To: <46150D67-97E7-457F-9C8B-D2B3060978CA@qti.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [10.24.14.158]
Content-Type: multipart/alternative; boundary="_000_048076C6C8C44F14961CC990F154E174intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/mnY3IXkzkKz8kIM3EMpPB87J1Bc>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
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: Tue, 23 Oct 2018 17:10:37 -0000

SP800-164 is a useful reference for both concepts and terminology. In particular it follows terminology conventions that slightly differ from some terms suggested by this list. In particular,

- attestation: a set of claims which can be verified as originating in an entity.
SP800-164.attest: “Root of Trust for Measurement (RTM)—provides trusted measurement functions to be used by assertions that are protected via the RTI and attested to with the RTR.” [nms] Note: SP800-164.assertion appears to be synonymous with SP800-164.claim and SP800-164.evidence. The discussion on roots-of-trust makes it clear that the claims (evidence | assertions) are verifiable to have originated from a root-of-trust.

- claim:  as defined in RFC7519.
SP800-164.claim: “A device with integrity has the ability to assert specific claims about its configuration, health, or operating status in a way that Information Owners can confidently rely upon to make decisions about interacting with the device and Device Owner.” [nms] The SP800-164.claim doesn’t appear to conflict with RFC7519.claim semantics; although RFC7519.claim also defines a particular encoding scheme. Whereas SP800-164.claim is conceptual (only). It should be possible to allow for the use of “claim” in contexts that chose to define alternative encodings such as ASN.1. Note: SP800-164.assertion appears to be synonymous with SP800-164.claim and SP800-164.evidence.

- entity: a device or device sub-module that can generate a claim or set of
          claims which can be verified by a remote party.
SP800-164.root of trust: “RoTs are security primitives composed of hardware, firmware and/or software that provide a set of trusted, security-critical functions.” [nms] A root of trust appears to be a “sub-module” of a “device”. It might have been more correct for the suggested definition for attestation to have used the term “sub-module” instead of “entity” given SP800-164.root-of-trust term most closely resembles the suggested “sub-module”. Possibly it makes sense to use the term “device” to refer to a device and “root-of-trust” to refer to a “sub-module”?

- entity: a device or device sub-module that can generate a claim or set of
          claims which can be verified by a remote party.
SP800-164.entity: “An Information Owner is an entity whose…” and “a Device Owner is an entity that…” [nms] Since there isn’t a suggested alternative for SP800-164.entity, possibly it makes sense not to overload “entity” with “device” as entity also can refer to a person or organization.

- remote party: an actor remote from an entity that wishes to verify whether
          a claim or set of claims originated in a given entity.
SP800-164 doesn’t use the term “remote party” instead it uses a couple of terms that potentially could be used in place of “remote party”. These are “verifier” and “relying party”.

SP800-164.verifier: “The RTR will apply integrity and non-repudiation protections on the data so that subsequent software agents cannot alter or replay the data without detection. The established identities allow verifiers to verify the source of the data uniquely and without repudiation.”

SP800-164.relying party: “A device has integrity if its software, firmware, and hardware configurations are in a state that is trusted by a relying party.”

Since it makes sense for IETF attestation efforts to be aligned with accepted and cited NIST SP800-164 document. Possibly, the charter can use terminology introduced there and seek not to redefine or clarify. As long as the charter terminology is aligned with that of SP800-164, it should be possible for the Attestation BOF to discuss a WG charter without needless confusion and misinterpretation due to inconsistent and alternative use of terminology.

-Ned


On 10/23/18, 7:40 AM, "EAT on behalf of Jeremy O'Donoghue" <eat-bounces@ietf.org<mailto:eat-bounces@ietf.org> on behalf of jodonogh@qti.qualcomm.com<mailto:jodonogh@qti.qualcomm.com>> wrote:

The Working Group will identify security goals which it expects a trustworthy
execution context to address, which will assume the presence of Roots of
Trust (as defined by NIST [SP800-164]). The detailed specification of such
contexts is out of scope.