Re: [EAT] [Rats] Terminology definitions (was Re: Scope, Goals & Background for RATS)

"Smith, Ned" <ned.smith@intel.com> Fri, 21 September 2018 16:26 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 0F47E130DBE; Fri, 21 Sep 2018 09:26:20 -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 dmUAFlcWzgPq; Fri, 21 Sep 2018 09:26:17 -0700 (PDT)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 CE2B212777C; Fri, 21 Sep 2018 09:26:16 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2018 09:26:16 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.54,285,1534834800"; d="scan'208,217"; a="88206798"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga002.fm.intel.com with ESMTP; 21 Sep 2018 09:26:01 -0700
Received: from orsmsx111.amr.corp.intel.com (10.22.240.12) by ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 21 Sep 2018 09:26:01 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.80]) by ORSMSX111.amr.corp.intel.com ([169.254.12.139]) with mapi id 14.03.0319.002; Fri, 21 Sep 2018 09:26:00 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Laurence Lundblade <lgl@island-resort.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [Rats] Terminology definitions (was Re: [EAT] Scope, Goals & Background for RATS)
Thread-Index: AQHUUTfMALfTzJK6XkqiLHztvYPNWqT67R4A
Date: Fri, 21 Sep 2018 16:26:00 +0000
Message-ID: <8BEEF9EB-EF69-4291-8FB5-711520ABBD3E@intel.com>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <7F807C6B-BE51-45DB-B6F0-1F9BAF6A1944@island-resort.com>
In-Reply-To: <7F807C6B-BE51-45DB-B6F0-1F9BAF6A1944@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-originating-ip: [10.255.84.8]
Content-Type: multipart/alternative; boundary="_000_8BEEF9EBEF6942918FB5711520ABBD3Eintelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/Bg3JnbBPwexmyy10ascoa_Ichq0>
Subject: Re: [EAT] [Rats] Terminology definitions (was Re: Scope, Goals & Background for RATS)
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, 21 Sep 2018 16:26:20 -0000

[nms] See inline below.


On 9/20/18, 4:15 PM, "RATS on behalf of Laurence Lundblade" <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org> on behalf of lgl@island-resort.com<mailto:lgl@island-resort.com>> wrote:
[nms] --- snip ---
·         Attestation Claim: Information about some characteristics or attributes that affect device trustworthiness.
Would just prefer to use “Claim”.  Add examples: measurements of running SW, GPS location, boot state, HW and SW Versions.

A Claim is used by the Relying Party to evaluate device trustworthiness. Saying it affects device trustworthiness is confusing. Claims do not change the device.


[nms] Agree claims do not change the device. Claims are referring to immutable(?) properties of the device. Properties that influence a verifier to trust the device to some degree or purpose different than if the claims were not made known. If ‘affect’ is too strong maybe ‘influence’ is better?


[nms] --- snip ---

·         Attester: An endpoint that has a root-of-trust for reporting (RTR) and implements a conveyance protocol, authenticates using an Attestation credential, collects Attestation Evidence about itself and presents it to a consumer of evidence (e.g. a Relying Party or a Verifier).
·         Claimant: An entity that make an assertion to a certain property regarding the trustworthiness of an entity. This may be the binding of an Attester to an RTR or any other kind of property.
Commenting on Attester and Claimant together. We need a term for the “subject” of the Claims, so I propose replacing “Claimant” with “Entity”

·         Entity: that about which the Claims are made. Often referred to as a device. Examples are a phone, IoT Device or Router. It can also be a submodule of a device.
·         Attester: the part of an Entity that secures the claims (securing is typically done by signing). It turns “Claims” into “Signed Claims”.  A TPM is an example of this.
[nms] This seems to be conflating different entities into a single entity (which should not be an objective). Attester is the entity that assembles claims about the attesting environment. Claimants often are entities in the manufacturing and supply chain that do something to indeed ‘affect the trustworthiness’ of the device. It may be some form of packaging, hardening, validation or compliance tests. There may be multiple disparate entities involved. When those entities construct a claim (aka verifiable claim) they become known as a ‘claimant’ – or at least that is the intent of the use here. An attester assembles the various claims (authored by multiple claimants) and even provide its own self-asserted claims and present them as evidence in the context of a conveyance.

[nms] --- snip ---

·         Reference Values: Information that can be matched with collected Attestation Evidence to determine if the device's operational state complies with an intended/expected operational state (e.g. Reference Integrity Measurements).
Prefer "Reference Claims" so they are clearly tied to the term Claim. I could live without definition entirely if we really wanted to be simple.


[nms] Agree it may not be needed. The motivation for not calling them reference claims is that the verifier should apply a policy to reference claims that determines how to respond to the verification step. For example, if a claim states that the device is common criteria certified to level 3. A reference claim from the CC evaluation lab may assert the device meets level 3+. If a verifier policy specifies a range of acceptable CC reference values (e.g. 2 – 3+) then the reference claim (3+) isn’t the same as the attested claim (3) nor is it the same as the reference values (range: 2, 2+, 3, 3+).

[nms] --- snip ---
·         Root of Trust: The base entity for a chain of trusts that builds up trust in an overall system.
Some people think roots-of-trust are the boot ROM, embedded secret keys and such in a device.  Other people think they are X.509 root certificates published by CAs used for verifying chains.  It’s not clear which you are referring to. That said, I think we should just remove this definition from the charter. It doesn’t seem essential.

[nms] Agree that definition of root-of-trust could be reserved for a terminology draft.

·         Verifier: An endpoint that has a root-of-trust for verification and implements a conveyance protocol, verifies Attestation credentials and may authenticate using Attestation Evidence or other credentials, appraises Attestation Evidence against Reference Values or policies and makes verification results available to Relying Parties.
I propose:
·         Verifier: A server or service that receives Signed Claims and processes them by verifying the signature and possibly comparing to Reference Claims.
[nms] Aside from the subtle differences between reference claims and reference values and that a verifier doesn’t need to be a server/service (as it could be a client or peer), the proposed definition is simpler and easier to comprehend.

Finally, I’d like to add:
·         Token: a collection of Signed Claims that is Conveyed from the Attester to the Verifier
[nms] I don’t object to a definition of token, but there is already a definition and use context in the form of JWT and CWT. This definition differs slightly. To avoid re-defining an existing IETF term. It might make sense to move this to a terminology draft. I’m not sure it is essential for inclusion in a charter document.
·         Entity Manufacturer: The company that made the Entity. The Entity Manufacturer configures the Attester with signing keys. It may also be the Verifier or supply signature verification keys to the Verifier.
[nms] I think this definition conflates ‘device’ with ‘entity’. Entity can refer to a manufacturer or other participant of a supply chain. The term ‘entity’ is intended to be an abstraction that avoids having to enumerate the complexities of supply chains and deployment architectures.

LL






On Sep 18, 2018, at 1:26 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>> wrote:

Hi all,

we pushed an initial document to the RATS github in order to focus the discussion about remote attestation procedures a bit.


https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter.md<https://github.com/ietf-rats/charter/blob/master/ietf-rats-charter..md>

We included a background section to better highlight the meaning of the term "attestation" in general. Hence, there is a trade-off between clarity and conciseness, which is one of the things we would like to get feedback about.

Naturally, we are also very interested in feedback about the illustrated difference between explicit attestation and implicit attestation.

Viele Grüße,

Henk





_______________________________________________
EAT mailing list
EAT@ietf.org<mailto:EAT@ietf.org>
https://www.ietf.org/mailman/listinfo/eat