Re: [EAT] [Rats] Attestation BoF charter updates?

Henk Birkholz <> Wed, 24 October 2018 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10D27129619; Wed, 24 Oct 2018 05:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0OjSkPr7AZGS; Wed, 24 Oct 2018 05:55:56 -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 57C13128DFD; Wed, 24 Oct 2018 05:55:55 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9OCtlnY012826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Oct 2018 14:55:48 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Oct 2018 14:55:41 +0200
To: "Jeremy O'Donoghue" <>, "Eric Voit (evoit)" <>, "" <>
CC: Michael Richardson <>, "" <>
References: <> <> <> <> <7544.1540242117@localhost> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Wed, 24 Oct 2018 14:55:41 +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] [Rats] Attestation BoF charter updates?
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: Wed, 24 Oct 2018 12:56:01 -0000

Hi all,

based on Jeremy's proposal we did another big refactoring - also tried 
to address everybody's comments, inputs and concerns.


Please note that this charter text is intended to be a first phase, 
which is the reason why, for example, there still is no mentioning about 
provisioning, profiles, or more details about out-of-band dependencies.

As Michael highlighted, most types of content belong into drafts. That 
said - on one hand the charter is a kind of "contract" wrt to scope and 
output, on the other hand we do not want to boil the ocean (at least not 
all at once...).

Viele Grüße,


On 10/24/2018 01:36 PM, Jeremy O'Donoghue wrote:
> HI Eric,
>> On 23 Oct 2018, at 19:04, Eric Voit (evoit) < 
>> <>> wrote:
>> Hi Jeremy,
>> Thanks for taking a cut at this charter simplification.  There are a 
>> few areas covered within theGitHub Goals 
>> <>which 
>> I can’t easily map to your text below.  Could you talk about how these 
>> elements are covered (or not)?   For context, I am working from the 
>> perspective ofremote attestation application 
>> <>developer 
>> trying to standardize the interfaces between a controller (which is 
>> acting as a claim verifier) and a network element (which includes TCG 
>> based subsystems.)
>> For my application to work properly, there are several things needed 
>> within a network controller to validate the asserted claims coming out 
>> of a router.  These include:
>> ·How do we expose the attestation evidence which can be used to 
>> validate asserted claims?
> I think that the need to address this is covered sufficiently for a WG 
> Charter by the statement "Produce a specification defining procedures 
> and corresponding architectures
 supporting verification of Claims".
> If verification of Claims requires specific forms of attestation 
> evidence (e.g. a set of measurements generated by a TPM), then it is 
> properly a matter for an RFC to specify this, as Michael suggests.
>> ·How do we know which root of trust which was used to generate the 
>> attestation evidence (e.g., application event logs), and how does a 
>> verifier differentiate this from the root-of-trust which asserts 
>> claims made upon this evidence?
> Again, I think this is a matter for specification rather than charter. 
> There are a number of different ways in which Roots of Trust can be 
> realised and many possible device architectures. The EAT draft allows 
> one RoT to include an attestation generated by a different RoT, for 
> example. I believe the RATS draft also provides technical mechanisms by 
> which this can be achieved.
>> ·What entities are allowed to read the info asserted claims?  What 
>> subset of these can see the raw attestation evidence?
>> These questions are significant because routers/switches are not 
>> monolithic devices.  In fact, they are composed of subsystems with 
>> different levels of trustworthiness. As the IETF often aims at 
>> protocol specifications at the inter-device level, I am looking for 
>> coverage of such questions in the charter.
> I agree with you here as the same issue applies to claims with privacy 
> implications. As an example, I may wish to present a unique device ID to 
> a social media website but not my location.
> I have added bullet point 3 to the draft - which I will post separately. 
> Let me know if you think this addresses your concerns sufficiently.
> Best regards
> Jeremy
>> Thanks,
>> Eric
>> *From:*Jeremy O'Donoghue, October 23, 2018 10:40 AM
>> On 22 Oct 2018, at 22:01, Michael Richardson < 
>> <>> wrote:
>>     Jeremy O'Donoghue <
>>     <>> wrote:
>>         This is a very useful contribution, Laurence.
>>         The current draft text is too strongly biased towards
>>         attestation based
>>         on measurement, and does not adequately cover other mechanisms
>>         which
>>         are already
>>     But, it's for the charter, for the WG, it's not a treatise on
>>     attestation
>>     itself.
>>     This is all supposed to be *meta* text about attestation, about
>>     what we want
>>     to say about attestation in the documents, not about what
>>     attestation is.
>>     Please go read some other IETF charters:
>> Fair comment.
>> We have two existing proposals - EAT and RATS - which address a 
>> similar problem space but using different mechanisms. While I believe 
>> the RATS and EAT contributors are in broad agreement that there is 
>> significant benefit in bringing both work streams under a single 
>> umbrella, trying to properly incorporate EAT through incremental 
>> modification to the draft RATS WG charter text is proving challenging.
>> The below probably diverges too far from the current text for some 
>> tastes, but it may address your point and provide a basis for 
>> discussion (at this point the GitHub draft 
>> <> seems 
>> a long way behind the list). It is deliberately significantly shorter 
>> than the current draft - I have tried to re-use as much existing text 
>> as possible, but it is heavily re-organised and abridged.
>> I have taken on board the comment from Carsten that perhaps a minimum 
>> level of terminology is acceptable in charter text, but deliberately 
>> tried to keep the language simple and fairly generic to enable the 
>> proper work of terminology definition to take place in the 
>> requirements document as you suggest.
>> Introduction
>> ------------
>> Remote attestation procedures can be incorporated in network protocols to
>> provide the basis for establishing claims about an entity in a trustworthy
>> manner. Such claims may include, but are not limited to, device identity,
>> manufacturing origin, system integrity, configuration, operational 
>> state and
>> measurements of steps which led to the operational state. Such procedures
>> expose entity characteristics in the form of claim sets which allow remote
>> parties to establish the trustworthiness of a device, provide evidence 
>> that a
>> particular set of operations and functions are supported and/or that the
>> entity is actually what it claims to be.
>> In the absence of such procedures, while domain-specific attestation
>> mechanisms such as TCG TPM, FIDO Alliance attestation and Android Keystore
>> attestation exist, there is no common way for a remote party to tell 
>> if data
>> originates from a trustworthy device (e.g. a Trusted System designed to
>> support a specific set of operations/functionalities) or not.
>> The following minimal terminology is defined for the purposes of 
>> clarifying the
>> Working Group charter text:
>> - attestation: a set of claims which can be verified as originating in an
>>           entity.
>> - claim:  as defined in RFC7519.
>> - entity: a device or device sub-module that can generate a claim or 
>> set of
>>           claims which can be verified by a remote party.
>> - remote party: an actor remote from an entity that wishes to verify 
>> whether
>>           a claim or set of claims originated in a given entity.
>> Description of the Working Group
>> --------------------------------
>> The Working Group will define:
>> - Standardized and interoperable mechanisms to establish a sufficient 
>> level
>>   of confidence that data originates from a trustworthy entity designed to
>>   support a specific set of operations/functionalities.
>> - Standardized and interoperable mechanisms building on (1) to allow 
>> remote
>>   parties to know the provenance and characteristics of an entity that 
>> may be
>>   requesting services.
>> The Working Group will identify security goals which it expects a 
>> trustworthy
>> execution context to address, which will assume the presence of Roots of
>> Trust (as defined by NIST [SP800-164]). The detailed specification of such
>> contexts is out of scope.
>> The Working Group will maintain close relationships with bodies 
>> undertaking
>> complementary work streams in the area of remote attestation such as
>> GlobalPlatform, Trusted Computing Group and FIDO Alliance.
>> The Working Group will cooperate with the TEEP Working Group, which may
>> generate requirements for claims relevant to TEE.
>> Work Items
>> ----------
>> The Working Group will develop specifications supporting the creation of
>> interoperable remote attestation procedures for entities which 
>> incorporate
>> Roots of Trust. The main deliverables are as follows.
>> - Produce a requirements document establishing a common vocabulary for 
>> remote
>>   attestation, identifying mechanisms which will be supported for 
>> establishing
>>   trust between an entity and a remote party, and enumerating sample 
>> use-cases
>>   for remote attestation.
>> - Produce specification text defining interoperable cross-platform 
>> claims which
>>   provide information about an entity in support of the required 
>> use-cases, and
>>   extending the set of claims defined in RFC7519 and RFC8392. The 
>> specification
>>   will describe the syntax for each claim in at least the following 
>> formats:
>>     - CBOR [RFC7049]
>>     - JSON [RFC7159]
>>     - YANG [RFC6020]
>> - Produce specification text defining procedures and corresponding 
>> architectures
>>   supporting verification of claims within an attestation based on 
>> measured file
>>   execution procedures and supporting:
>>     - Explicit attestation wherein a set of claims is transported in 
>> the attestation;
>>     - Implicit attestation wherein a set of claims is implied by 
>> possession of a secret.
>> - Produce specification text defining procedures and corresponding 
>> architectures
>>   supporting verification of claims encapsulated in:
>>     - CBOR Web Token structures [RFC8392]
>>     - JSON Web Token structures [RFC7519]
>> - Perform privacy analysis of both claims and the cryptographic 
>> procedures used to
>>   establish trust. This information will be included as appropriate in the
>>   deliverable specifications, and may imply extension of procedures 
>> defined in
>>   other specifications in support of privacy goals.
>> It seems to me that there are two ways to produce the main 
>> specification deliverables. I have deliberately left the text above 
>> slightly vague on this.
>>   * A claims specification common to RATS and EAT with separate RATS
>>     and EAT procedure specifications.
>>   * A claims specification also incorporating EAT procedures and a
>>     separate RATS procedure specification. This would be my preferred
>>     option.
>>       o I believe there are very few procedures needed for EAT other
>>         than the possible need to support a nonce to ensure freshness
>> Jeremy
>>     Notice how by about the second paragraph (6tisch takes a bit
>>     longer), each
>>     gets into what the WG will do?
>>     --
>>     Michael Richardson <
>>     <>>, Sandelman Software Works
>>     -= IPv6 IoT consulting =-
>>     _______________________________________________
>>     EAT mailing list
>> <>
> _______________________________________________
> EAT mailing list