Re: [EAT] Attestation BoF charter updates?

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

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 broadly deployed in proprietary form, and which should be supported in an interoperable standards based manner.

From my perspective, there are a number of issues which lead to the need for charter text which is more inclusive of different approaches to attestation:


  *   TPM and systems based on measured file execution procedures have very limited presence in the mobile ecosystem, and any attestation standard of interest needs to be useful in the mobile space and highly constrained (microcontroller-class and smaller) IoT if we are to avoid fragmentation in future. The flexibility of EAT is a great strength here.
  *   In devices where the threat model may include the device owner - such as many mobile and IoT devices - attestation bound to the REE, as is typical in the TPM use-case, has some challenges. https://www.blackhat.com/docs/eu-17/materials/eu-17-Mulliner-Inside-Androids-SafetyNet-Attestation.pdf provides an example which is in the public domain.
  *   Systems based on run-time (as opposed to boot time) integrity measurement address trustworthiness over time - see https://dl.acm.org/citation.cfm?id=2660350. There are commercial examples of such systems in mass production on several different mobile SoCs. Information available to the public includes https://seap.samsung.com/faq/what-knox-tima-keystore. Eric Voit has already shared that such systems are also deployed in the network infrastructure space, so it seems to me that the charter text should cover this case.
  *   As noted in previous mail to the list, there is ongoing work in GlobalPlatform which plans to make use of the approach described in the EAT draft. I also have good reason to believe that other industry bodies are considering this approach, which provides a great opportunity to promote interoperability through the output of the eventual WG.

As it stands, the text is too specific to a particular approach for me to be able to support it. That said, and wishing to be constructive, I have attempted to merge the current charter text (commit 267b166) with Laurence' contribution below. Black text is the current draft; red text is mine and blue text is from Laurence.


Remote ATtestation ProcedureS (RATS) are included in network protocols to provide the basis for establishing claims about a device in a trustworthy manner exchanges with a device, 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. RATS expose such device characteristics in the form of trusted claim sets which allow remote parties to evaluate (based on Proof-of-Possession) to detailed Attestation Evidence (Proof-of-Protection) that enable a Verifying Parties to retrace every step that led to its current Operational State. A consequence of this retracing is that it is possible to appraise the trustworthiness of a device. RATS provide evidence that a device supports a certain set of operations and functions and/or that it is actually the exact device it is supposed to be (Attestation Provenance) via identity documents or passes. RATS ensure that the information conveyed is unique, complete, and fresh (exposing tampering, replay, and/or relay attacks).

RATS may include definition of procedures by which a remote party evaluates certain claims. For example, how some measurement or other claims are compared to expected values to evaluate the trustworthiness of the device. RATS further supports Various Roots of Trust (e.g. for Measurement, for Reporting, or for Verification) provide the foundation to enable Implicit Remote Attestation (the fact that a secret key is accessible implies a specific meaning and specific defined set of characteristics which therefore need not be supplied explicitly). assertions are optional) and Explicit Remote Attestation, which uses the  output of measured file execution as Attestation Evidence which can be used (along with event log details) to ratify that the device is actually a Trusted System.

RATS may include the definition of new protocols and/or the definition of secured data structures (e.g. signed) that are carried in existing protocols.

RATS is general purpose and aims to address a broad range of use-cases including online banking, payment transactions, critical infrastructure, network security functions, constrained-node devices, business and government enterprises and or the management of end-user devices, including scenarios where device and/or end-user privacy are required.

Like Laurence, I would prefer a new name to reflect the fact that we are merging different contributions, but I have retained RATS in the above to focus on the changes to the text.

Best regards
Jeremy

On 20 Oct 2018, at 06:54, Laurence Lundblade <[e-mail]<mailto:[e-mail]>> wrote:

I’d like to propose this for the Introduction in the charter. I tried pretty hard to write what I wanted through edits to the existing intro, but really couldn’t make it work, so this is mostly new text. Some phrases are re used. Apologies for not finding a better way to do this. I have tried to put all the ideas and concepts in Henk’s original charter intro in here, though I have gone for a more abstract conceptual level. A few more notes below.


RATS enables remote parties communicating with a device to evaluate the trustworthiness, device identity, origin of manufacture, system integrity, configuration, operational state and other characteristics of that device. Conceptually, the remote party ends up knowing a set of claims about the device and using them to make the evaluation. The claims may explicitly be transmitted or implicitly derived from other things known about the device. Various means are used to secure, or prove the security of, claims for the remote party. Signing of the claims is the most important but may not be the only means of securing the claims. These claims can provide evidence that a device supports a certain set of operations and functions and/or that it is actually the exact device it is supposed to be.

RATS includes the measurement of SW running on the device and securely conveying those measurements to the remote party.  These measurements enable tje remote party to evaluate device trustworthiness, that it operates as expected, does what is required and does not do other things.

RATS may include definition of procedures by which a remote party evaluates certain claims. For example, how some measurement or other claims are compared to expected values to evaluate trustworthiness of the device.

RATS may include the definition new protocols and/or definition of secured data structures (e.g., signed) that are carried in existing protocols.

RATS is general purpose and aims to address a broad range of uses cases including on-line banking, payment transactions, critical infrastructure, network security functions, constrained devices, business and government enterprises and management of end-user devices.

Notes:


  *   I have avoided the use of the formally defined terms in the introduction so it can stand more on its own, is easier to understand and is less presumption about architectures and designs. Seems like it is work for the WG to define the terms and create the designs.
  *   My use of the lower case “device”, “claim” and “remote party” are just as broad concepts to be able to get the general idea across. The WG documents should use the more formal and specific definitions.
  *   Hope I’ve covered both EAT and RATS concepts here. It was my goal.
  *   While I used the term RATS, I still want the WG name change to CREATE.

LL


On Oct 11, 2018, at 10:19 PM, Henk Birkholz <[e-mail]<mailto:[e-mail]>> wrote:

Hi all,

sorry for the delay. Please find an updated charter proposal here:

https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter..md<https://github.com/ietf-rats/charter/blob/RC2/ietf-rats-charter.md>

The BoF proponents tried to merge all comments and proposals on keystores, existing solutions, provenance & device characteristics, etc that were raised on the list - and align them in homogeneous fashion.

This draft is intended to focus the discussion and improve the wording.

Viele Grüße,

Henk

On 10/06/2018 08:23 AM, Laurence Lundblade wrote:
Hi Henk,
Bangkok IETF is getting close, will you be able to update the charter for the attestation BoF to properly include EAT?  I sent you some text that just needs to be pasted along with some comments. It doesn’t look like there’s been any updates.
LL

_______________________________________________
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