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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Fri, 21 September 2018 13:09 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 47E2B130E78; Fri, 21 Sep 2018 06:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MWeQxsp7rV7R; Fri, 21 Sep 2018 06:09:16 -0700 (PDT)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 481B1130E73; Fri, 21 Sep 2018 06:09:15 -0700 (PDT)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w8LD9AGv016678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Sep 2018 15:09:11 +0200
Received: from [134.102.163.186] (134.102.163.186) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Sep 2018 15:09:05 +0200
To: Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <7F807C6B-BE51-45DB-B6F0-1F9BAF6A1944@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <92996be3-67cb-1581-0f60-46ede56034af@sit.fraunhofer.de>
Date: Fri, 21 Sep 2018 15:09:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7F807C6B-BE51-45DB-B6F0-1F9BAF6A1944@island-resort.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.163.186]
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/y4w5w0x80Wd9gEEz_e9OrLA3Eis>
Subject: Re: [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: Fri, 21 Sep 2018 13:09:20 -0000

Hello Laurence,

please find replies and comments in-line:

On 09/21/2018 01:14 AM, Laurence Lundblade wrote:
> 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...

True. To scope the discussion we pulled in a terminology section to 
agree upon what we mean and create a common understanding of the scope.

Assertion was pulled in, as not every claim (sets) are essentially 
assertions and they can be elevated in expressiveness via signing to 
become Attestation Claims, but not every Attestation Claim is 
Attestation Evidence. E.g. GPS coordinates cannot typically be verified 
via reference values (which is already a term abstracted for discussion 
- reference integrity measurement manifests - RIMM - would be more 
precise), unless the system is supposed to stay, for example, in exactly 
on place, or city, or country, I'd assume. Typically RIMM provide values 
that have to match. Reference values that define a scope that would 
match I have yet to encounter.

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

Trustworthiness is a characteristic assessed by the Verifier (root of 
trust for verification) based on Attestation Evidence. In different 
domains, the trustworthiness of the exact same thing using RATS can be 
assessed differently (depending of the policies, e.g. critical 
infrastructure domain vs. eCommerce . In general, the creation of 
Attestation Claims of course 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.”

As stated above, a signed claim (set) is not automatically a semantic 
equivalent to evidence. Attestation Evidence can only be produced by a 
RoT of Reporting, while (signed) claim sets are produced by a RoT of 
Measurement.

tl;dr very specific and detailed example on software component integrity 
in this comment

To give a very concrete common example: In the domain of software 
component integrity, where (Co)SWID can be used as RIMM, a Linux-based 
OS is capable of producing IMA (Integrity Measurement Architecture) logs 
(other OS have equivalent capabilities). In a nutshell, the OS creates 
hash values about every software component executed (typically from FS, 
with smaller things these are blockdevice identifier, addresses/offsets) 
in the order of execution over time. Measured/Verified Boot procedures 
(formerly called Secure Boot, a now deprecated term) allow the same kind 
of measurements of Computing Contexts started before the OS (prominent 
examples include UEFI/BIOS or Bootloaders). The point is, these staged 
Computing Contexts all have their own Claimants, none of them can create 
CWT today or in the foreseeable future, but in a Measured Boot 
architecture, they are able to take on the role of root of trust of 
measurement (RTM) and can create Attestation Claims.

At some point, an "inbox-API" for a root of trust for reporting (RTR) is 
available in a Computing Context. This can be a, for example, a specific 
proto-enclave, a CC-certified trust-zone, or a TPM Trusted Software 
Stack - the exact technology underneath does not matter, but a set of 
specific capabilities are required, e.g. including but not limited to: 
based on root of trusts, a physical coupling to the system that is 
"measured", protection of execution, and a shielded location. 
Attestation Claims (in this example the IMA logs) can be consumed by a 
RTR "inbox-API" - in the temporal sequence they were created in - in 
order to produce a very specific hash value that can only be created, if 
these exact Attestation Claims in that order are measured by the RTMs 
and then available to the RTR. Wrt Software Component Integrity, the 
output of the RTR is Attestation Evidence that can only be created, if 
the correct software components are executed in the intended order - and 
no other software component is executed. Consumer of that Attestation 
Evidence is a Verifier (root of trust of verification). On the Verifier 
side: A corresponding RIM wrt to the Attestation Evidence would be the 
expected hash values that are created by the RTR (Attester). A 
corresponding RIMM wrt to the Attestation Claims would be an appropriate 
Manifest of (Co)SWIDs.

Typically, there are points in time at which especially interesting 
Attestation Evidence (in our example the RTR hash values) can be 
created: after each staged Computing Context, for example (and in this 
example, this would be the already mentioned UEFI, bootloader, kernel, 
etc.).

If the RTR does not produce the exact Attestation Evidence that is 
expected, the Attestation Claims (e.g. secure audit logs) can provide 
more insight into which software component was "out of line".

In summary - in this example there are multiple Claimants that create 
Attestation Claims, are RTMs, and cannot create tokens. There is also a 
hardware RTR that consumes (a large volume of) Attestation Claims in 
order to create very specific Attestation Evidence about the current 
integrity of software components that are or were in execution.

Interoperable network protocols are required to convey Attestation 
Claims, Attestation Evidence, RIM(M)s, and the policies of local 
attestation (see Andrea's and Monty's replies before) in a way that a 
verifier can create an assessment of a communication partners 
trustworthiness.

> 
> 
>>   * 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”

Measurment's about a different system than yourself or "on behalf" of 
another system is a gap that we did not address explicitly in the text 
yet. But I think that is a very good proposal. As implied by the example 
above, I'd strongly recommend to retain the role of Claimant, but add 
the "subject" of the Claim as a term. Entity though is one of the most 
generic term right after "thing" - and I would like to see a little more 
specialized term.

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

I see your point. We were struggling about "authentication" a lot, as 
attestation is often misinterpreted to scoped to enable "stronger 
authentication". Remote Attestation Procedures include the scope of 
establishing trust in the identity of the communication partner and also 
the endorsement of capabilities of, for example, a component that is an 
Attester (RTR). But Remote Attestation is not limited to this specific 
subset of capabilities/semantics. We should try to word-smith text that 
avoids the term authentication, I think.

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

As, for example, signed (Co)SWID can be Reference Values (in that case 
RIMM) and as those exceed the semantic of a single claim, I really am 
not comfortable with reducing the scope of Reference Values to Claims.

The Creation of Attestation Evidence ranges from simple to rather 
complex, I think. That is why creating appropriate network protocols 
also requires a lot of running code and modularity.

> 
> 
>>   * 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:

As the role of Relying Party can, but does not have to be coupled with 
the role of Verifier (appraisal of Attestation Claims can be a very 
computing intensive task and can require a large volume of Reference 
Values), I'd still recommend to make a distinction between entities that 
consume Attestation Claims and Attestation Evidence.

The assumption here is that a relying party can process Attestation 
Claims that do not have to be appraised, but are considered trusted due 
to implicit attestation.

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

I am unsure about this. A concise definition might really help, but I 
assume this one can be worded better? How do other individuals think 
about this?

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

This point of view I do not share. Roots of trusts (the last "s" is 
intentional) are an essential part of this effort, I think. If they are 
often mistaken (as are, for example certificates and identities), I 
think we should rather make the effort and create standards that (at 
least in the RATS domain) make very precisely clear what intent, scope 
and audience are.

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

Please see the example above and the intended separation of duty 
("offloading the burden of appraisal").

> 
> 
> Finally, I’d like to add:
> 
>   * Token: a collection of Signed Claims that is Conveyed from the
>     Attester to the Verifier

If I am not mistaken, EA-Tokens do not have to be signed (which is good, 
as some specific technologies deployed for the foreseeable future cannot 
sign a CWT). Also, I think the separation of Attestation Claim and 
Attestation Evidence is a necessity and mandated by their disjunct semantic.

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

I agree that an endorsement of the capability of an entity (or system 
component - entity is quite generic, see RFC4949. I am an entity, I 
think, and my parents have nothing to do with this) is very important. 
If that is your intent here, I totally agree, but think that more 
word-smithing will be required.

> 
> 
> LL
> 
> 

Viele Grüße,

Henk

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