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

Laurence Lundblade <> Thu, 20 September 2018 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FC4D129C6A for <>; Thu, 20 Sep 2018 13:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id StVgalGeANT4 for <>; Thu, 20 Sep 2018 13:18:43 -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 A01B81200D7 for <>; Thu, 20 Sep 2018 13:18:43 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id 35POgWjZyntoI35POggi7Y; Thu, 20 Sep 2018 13:18:43 -0700
From: Laurence Lundblade <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FBF8246A-AA2E-4EC8-A017-01585F384A18"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Thu, 20 Sep 2018 13:18:42 -0700
In-Reply-To: <>
Cc: "" <>, "" <>
To: Henk Birkholz <>
References: <>
X-Mailer: Apple Mail (2.3445.8.2)
X-CMAE-Envelope: MS4wfK54aHwovr1NJBDre+ye/aRcsuyMEWMd95JHZcZHxRoXisN0KiKu6Xb988dZs63/87o8+ejgedpqNz2khAwFCBzo4xl7nfiKZ3eIMHlHLp3zTSunz2zH /W1KLBWrI50SBB03pBE3731+Nauh4WBtsDuw2bkLn2/069gbip7K1mnwrncswDPiPETeSqRKLgI0lNfnsPWQl1PfiuBsc/8hlDU8q9WMAbBNhiHnB7gIqVfG
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: Thu, 20 Sep 2018 20:18:46 -0000

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.

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:
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.
A network management center receives a set of measurement claims from a router to know that the configuration has not been tampered with.
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.
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.

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

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. 


> 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