Re: [EAT] [Rats] Attestation BoF charter updates? - Charter introduction section

"Smith, Ned" <> Wed, 24 October 2018 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 742E212777C; Wed, 24 Oct 2018 10:50:46 -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 pumYeEXAHSDV; Wed, 24 Oct 2018 10:50:44 -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 1A1D3124C04; Wed, 24 Oct 2018 10:50:44 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 10:50:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.54,421,1534834800"; d="scan'208";a="85281192"
Received: from ([]) by with ESMTP; 24 Oct 2018 10:50:43 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 24 Oct 2018 10:50:42 -0700
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Wed, 24 Oct 2018 10:50:42 -0700
From: "Smith, Ned" <>
To: Henk Birkholz <>, Jeremy O'Donoghue <>, "Eric Voit (evoit)" <>, "" <>
CC: Michael Richardson <>, "" <>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates? - Charter introduction section
Thread-Index: AQHUa8IVLU0WKPVOlUqOqmiRiqHnQg==
Date: Wed, 24 Oct 2018 17:50:42 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates? - Charter introduction section
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 17:50:46 -0000

[nms] The introduction includes the following list of information objects to which attestation might pertain:
"To improve the confidence in a communication partner's trustworthiness a relying party requires trusted claims or specific evidence about:

* device identity,
* claim origination/provenance,
* manufacturing origin,
* system integrity,
* configuration, or
* operational state and measurements of steps which led to the operational state."

A reasonable interpretation could exclude sub-module environments (e.g. TrustZone, SGX Enclave, VM) as potentially having different "trusted claims or specific evidence" than the "device". Hence, it might make sense to add "sub-modules or roots-of-trust" to the list.


On 10/24/18, 5:56 AM, "EAT on behalf of Henk Birkholz" < on behalf of> wrote:

    Hi all,
    based on Jeremy's proposal we did another big refactoring - also tried 
    to address everybody's comments, inputs and concerns.
[nms] Note: this reference doesn't disambiguate the version of the charter md and I believe there are emails that have crossed where may be a more recent version somewhere.
    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
    EAT mailing list