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

"Eric Voit (evoit)" <> Tue, 23 October 2018 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D4BB130E4D; Tue, 23 Oct 2018 11:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pgCGQet6swN1; Tue, 23 Oct 2018 11:04:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E223612D4F0; Tue, 23 Oct 2018 11:04:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=37616; q=dns/txt; s=iport; t=1540317856; x=1541527456; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YMYrSE9z9rH/hwNlf5QtcJZNZgdP9iLipNmU6+DyK7I=; b=ETEGgpM34rUnBEiJXDnEHYUQR0eLFcX65PXejJObFvD/CC/usbJuXdCY PkYjgun0JpEkzxomh2HztGo6UMTnOy+KP/fdIvvbwKQT0s5IuGLC9KC2E K0ZzZN2GIfLhVIRtuZEMNDCZAzKA9DiPA3gOaZEzeecG5h9xv6J2CLeTW 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAbYs9b/5JdJa1ZAQkZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFUAQEBAQEBCwGBDU0qZn8oCoVKklaCDZkMAwsBARg?= =?us-ascii?q?BB4FXgT6BNwKFKiE3Cg0BAwEBAgEBAm0cDIU6AQEBAgIBAStBBAcQAgEIFSM?= =?us-ascii?q?BBgcnCxQRAgQBDQUIgk5MgR1kD6kRhCwBEUCFHgWLUw8XgUE/gRGDEoMbAQE?= =?us-ascii?q?BAoEzAQNdhSQCiG+FSIYSigcJAoZhhjODVh+BUiKEUoMUhlaMXIloAhEUgSY?= =?us-ascii?q?zIoFVcBU7gjgBM4F2hA+FFIU+bwGKXwIkB4EBgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,417,1534809600"; d="scan'208,217";a="190436528"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 18:04:14 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9NI4DqE032524 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 18:04:14 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 14:04:08 -0400
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 14:04:09 -0400
From: "Eric Voit (evoit)" <>
To: "Jeremy O'Donoghue" <>, Michael Richardson <>
CC: "" <>, "" <>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUakqqBJn3KZZVPEe4vVODtnqbzKUsxo8AgAA3c3A=
Date: Tue, 23 Oct 2018 18:04:08 +0000
Message-ID: <>
References: <> <> <> <> <7544.1540242117@localhost> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_f6602afcf1b0440d98f5ded158bfe572XCHRTP013ciscocom_"
MIME-Version: 1.0
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: Tue, 23 Oct 2018 18:04:19 -0000

Hi Jeremy,

Thanks for taking a cut at this charter simplification.  There are a few areas covered within the GitHub 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 of remote 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?

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

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


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

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.

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

     *   I believe there are very few procedures needed for EAT other than the possible need to support a nonce to ensure freshness


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