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

[Jeremy O'Donoghue <[e-mail]>]

On 22 Oct 2018, at 22:01, Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:


Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>> 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:

https://datatracker.ietf.org/wg/6lo/about/
https://datatracker.ietf.org/wg/6tisch/about/
https://datatracker.ietf.org/wg/suit/about/

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<https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md> 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.
     *   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 <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat