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

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

Thanks for the feedback on my text. The text below makes the following changes, addressing comments from list contributors:


  *   aligns more closely with NIST terminology - note that NIST does not have a clear set of definitions for all of the terminology used, so some of the text is my interpretation of the content of SP 800-64, aided by the input from Ned.
  *   adds text addressing the possible need to protect come claims from unauthorised disclosure for privacy or security reason
  *   adds text supporting ASN.1 as a syntax for claims.

I have used some simple markup to identify the changes.

Introduction
------------

Remote Attestation procedures can be incorporated in network protocols to
provide the basis for establishing Claims about a Device 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 Device characteristics in the form of Claim sets which allow a Relying

Party, using a Verifier, to establish the trustworthiness of a Device, provide
evidence that a
 particular set of operations and functions are supported and/or
that the Device is actually what it declares itself 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 Relying Party to tell if Claims originate
from a trustworthy device (e.g. a trusted system designed to
support a specific
set of operations/functionalities) or not.

Terminology from NIST [SP800-64] is used with the following definitions in this
charter.

- Attestation: a set of Claims for which a Verifier can establish the source
  uniquely and without repudiation.
- Claim: A reliable assertion about the trusted state of a Device such as
  its configuration, health, or operating status. Also used in [RFC7519].
- Device: an object having some specific purpose, or a sub-module of such an
  object, that can generate a Claim or set of
 Claims whose source and integrity
  can be established by a Verifier.
- Relying Party: an actor remote from a Device that wishes to verify whether
a
  Claim or set of Claims originated in a given Device.
- Verifier: an actor trusted by the Relying Party to establish the source of a
  Claim or set of Claims uniquely and without repudiation,
- Root of Trust: a security primitive providing a set of trusted,
  security-critical functions.

Description of the Working Group
--------------------------------

The Working Group will define:

1. Standardized and interoperable mechanisms to establish a sufficient level
of
   confidence that Claims originate from a trustworthy Device designed to

   support a specific set of operations/functionalities.

2. Standardized and interoperable mechanisms building on (1) to allow Relying
   Parties to know the provenance and characteristics of a Device that may be

   requesting services.
3. Standardized and interoperable mechanisms to protect Claims which may need to
   be protected from unauthorised disclosure for privacy and/or security
   reasons.

The Working Group will identify security goals which it expects a trustworthy
execution context to address, which will assume the presence of one or more
Roots of
Trust. 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.

The Working Group will identify use-cases for interoperability with PKI
infrastructure and will work with the editor of SCEP and the ACME Working Group
to address technical solutions for these.

Work Items
----------

The Working Group will develop specifications supporting the creation
of
 interoperable Remote Attestation procedures for devices which incorporate
at
 least one Root of Trust.

- Produce a requirements document establishing a common vocabulary for remote

  Attestation, identifying mechanisms which will be supported for establishing

  trust between a Device and a Relying Party, and enumerating sample use-cases

  for Remote Attestation.
- Produce a specification defining interoperable cross-platform Claims which

  provide information about a Device 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]
  - ASN.1
- Produce a specification 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 a specification 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.


On 24 Oct 2018, at 12:36, Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>> wrote:

HI Eric,

On 23 Oct 2018, at 19:04, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jeremy,

Thanks for taking a cut at this charter simplification.  There are a few areas covered within the GitHub Goals<https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md>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<https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf> 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 <[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

_______________________________________________
EAT mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eat