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

Laurence Lundblade <lgl@island-resort.com> Thu, 20 September 2018 23:14 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 838A5130E5C for <eat@ietfa.amsl.com>; Thu, 20 Sep 2018 16:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6TBos7OMfpGF for <eat@ietfa.amsl.com>; Thu, 20 Sep 2018 16:14:48 -0700 (PDT)
Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net []) (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 2424112F1A5 for <eat@ietf.org>; Thu, 20 Sep 2018 16:14:48 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id 389nglwEpNcYN389ngU8i3; Thu, 20 Sep 2018 16:14:47 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <7F807C6B-BE51-45DB-B6F0-1F9BAF6A1944@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A5A0790-7B3E-46BB-BB40-07BF339E093C"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Thu, 20 Sep 2018 16:14:46 -0700
In-Reply-To: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de>
Cc: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de>
X-Mailer: Apple Mail (2.3445.8.2)
X-CMAE-Envelope: MS4wfJUSLiom2yLtiAjL2VjM7jQjoIAgKMADCVkoyrBqQV2CBYYLwhfYeXMwTp5C2HPywoC1XHvf9nIG4HT4J6ap9UcPADweRYGZUD1HOE8JhaJ1g7AQ9NvD BC87YAQNGLtNnLexgtcTKktMZpTOKmeUYP9SQj1jbI3jbz9NQIQyDSnHxBBolrykkgR5Naqpx4n+xUCuYby157MgX8c9zKG5ihkXF2Y7XbI9yMNI1AWI7AIy
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/tD1mH8gsEV5PALyc_GmMyaXssAg>
Subject: [EAT] 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: Thu, 20 Sep 2018 23:14:51 -0000

Here’s my comments / suggestion for simplifying and clarifying the terminology.  The fewer terms the better.

> Assertion: Defined by the ITU in X.1252 as "a statement made by an entity without accompanying evidence of its validity”.
Seems like we can do without this definition entirely. Trying to be simpler...

> 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.

> Attestation Evidence: Proof for one or more Attestation Claims (characteristics, attributes, ...) that affect device trustworthiness, such as its hardware identity, firmware, software, configuration or composition, compliance status and runtime state. Attestation Evidence may be consolidated through the use of cryptographic hash and key generation algorithms. Attestation Evidence veracity may be augmented by Claimant signatures over portions of the Attestation Evidence. Note that Claims are non-proven assertions as opposed to Attestation Evidence.
How about just “Signed Claims” or “Secure Claims". Same comment about “affect” as above. Definition can be just “Claims that have been signed or similarly secured for Conveyance.” 

> 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.

Think we should avoid the term “authentication” as seems more for protocols like SASL and EAP.. 

> Conveyance: The transfer of Attestation Evidence between Attester and Verifier, facilitated by network protocols that are reliable, secure and can prove the freshness of Evidence, if required.

> 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.

> Relying party: An entity that consumes and assesses Verifier results for the purpose of improved risk management, operational efficiency, security, privacy (natural or legal person) or safety. The Verifier and Relying Party functions may be tightly integrated.
I think the common and general definition is any server / service like an online bank, e-commerce site, enterprise document server and such whether or not the asses Claims.  I propose:

Relying Party: More generally any server or service like an online bank or e-commerce site. Here a server or service that consumes and assesses Verifier results for the purpose of improved risk management, operational efficiency, security, privacy (natural or legal person) or safety. The Verifier and Relying Party functions may be tightly integrated.

> Remote Attestation: The procedure of supplying Attestation Evidence to a communication partner via an Attester using network protocols for Conveyance.
I’d kind of prefer to leave this out as the whole document is about it. If it is kept in, I think it should refer to the whole end-end process.

> 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.

> 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. 

Finally, I’d like to add:
Token: a collection of Signed Claims that is Conveyed from the Attester to the Verifier
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.


> On Sep 18, 2018, at 1:26 AM, Henk Birkholz <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
> 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
> https://www.ietf.org/mailman/listinfo/eat