Re: [EAT] Scope, Goals & Background for RATS

Henk Birkholz <> Fri, 21 September 2018 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B3A9130DBE; Fri, 21 Sep 2018 09:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0c-tYyHMwfPY; Fri, 21 Sep 2018 09:24:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 098E412777C; Fri, 21 Sep 2018 09:24:17 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w8LGOEWP032271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Sep 2018 18:24:15 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Sep 2018 18:24:09 +0200
To: Laurence Lundblade <>
CC: "" <>, "" <>
References: <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Fri, 21 Sep 2018 18:24:08 +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: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [EAT] Scope, Goals & Background for RATS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Sep 2018 16:24:23 -0000

Hello Laurence,

please find replies and comments in-line:

On 09/20/2018 10:18 PM, Laurence Lundblade wrote:
> It’s a bit buried, but I see you do intend that this include the EAT 
> work. Thus the work would not be TPM/TCG centric. It would include use 
> cases like FIDO and Android Keystore attestation that are often based on 
> TrustZone. It could also include EPID-related use cases. Please confirm.

I am not sure, if I am the authority to confirm this, as kickstarting 
RATS is a group effort. What I can do is to agree with the statement 
that RATS is abstracting from specific hardware solutions that provide, 
for example trust anchors and shielded locations (which keystores are a 
subset of, I think), or restrict secret key access (protection of 
execution, I think) based on system status (or more generic - system 

Conveyance of Attestation Claims is a big part of implicit attestation 
and the comparison of (amongst other information) claims wrt to 
appraisal of Attestation Evidence in explicit attestation. As EAT 
provides a data format to express these claim sets in a state-of-the art 
representation (and, if signed, via a state-of-the-art COSE envelope) 
they are compose a perfect option to address the data model part of 

> My preference would be to choose another name for the group that is 
> neither EAT or RATS to help make this clear. I don’t really think there 
> is a “procedure” with EAT. To be honest, I don’t really like “RATS” as a 
> name. My suggestions are “RA” for Remote Attestation or “CAT” for Common 
> Attestation Technology (and besides cats caused us to invent the 
> Internet so we share pictures of them (securely)).
> I propose a more high-level intro with examples:
>     The purpose of RA/CAT is to allow a Relying Party (e.g. a web
>     service, network management center...) to securely receive Claims
>     from an Entity requesting service (e.g. a phone, router, IoT
>     device...) that allow the Relying Party to determine if and how that
>     entity is trusted.  For example:
>       o An IoT management back-end receives a signed nonce that proves
>         the IoT device is the genuine article manufactured by the
>         expected OEM and is not a Linux box or such emulating such a device.
>       o A network management center receives a set of measurement claims
>         from a router to know that the configuration has not been
>         tampered with.
>       o An online banking service receives many claims about the device
>         including location, SW versions and measurements and determines
>         that it will allow a higher-than-usual value transaction.
>       o A government online document server receives claims indicating
>         manufacture and location of the device, determines they are from
>         the correct country and grants access to classified documents.
>     There are protocols for determining and securing the identity of a
>     server or service (TLS and IPsec). There are many protocols for
>     authenticating end users (SASL, TLS client auth, EAP…). There are no
>     general protocols for managing the characteristics, security and
>     identity of an end client device (an Entity). RA/CAT aims to address
>     that gap.
>     There is no goal here to set criteria for what is trustworthy or not
>     as that is an impossible task as it will vary widely from use case
>     to use case. The goal here is to securely provide information
>     (Claims) to the Relying Party so it can make that determination
>     based on its own criteria and needs.

RATS addresses a vital domain that I feel is missing here: critical 
infrastructure or safety critical systems.

Examples given: voting machines, rail-road object controllers, air plane 
cabin and avionic control systems & corresponding airports, cell-phone 
towers, or domains with high levels of confidentiality, in general.

Of course, there is the high demand to convey information to assess a 
system's trustworthiness in a trusted and resilient way coming from 
network equipment (or network function services) vendors. But managing 
the integrity (and actual composition) of a large number of end-user 
devices is also a requirement with continuously growing importances - 
not only for governments, but also for enterprises.

The scope of numbers of devices expanding due to encompassing 
constrained-node environments will render RATS a very interesting effort 
(that is why "offloading the burden of appraisal" and differentiating 
the roles of Verifier, Relying Party & "measured system (component)" is 
so vital, I think).

> I don’t think the intro should mention public key crypto. I know of 
> attestation solutions that do not use it.

This is a good point, we added proof-of-possession to enable readers to 
better intuitively grasp the context in the IETF. Could you reference 
some of the solutions? I think that would help address that comment.

> I tend to prefer “attestation” when the goal is whether and how a device 
> is to be trusted and “authentication” when the goal is how a human is to 
> be identified. FIDO, OAuth, SASL are all about users and use the word 
> authentication.

Yes - I think we are in agreement here. I am not sure if we can skip the 
term entirely, but the focus is on more than "stronger authentication".

> LL

Viele Grüße,


>> On Sep 18, 2018, at 1:26 AM, Henk Birkholz 
>> < 
>> <>> wrote:
>> Hi all,
>> we pushed an initial document to the RATS github in order to focus the 
>> discussion about remote attestation procedures a bit.
>> 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
>> <>