[Teep] Proposal to Carry Raw Report Data in TEEP Protocol messages

[Ken Takayama <[e-mail]>]

To: TEEP Protocol authors
Cc: RATS WG (relates to the EAR document),

This is Ken Takayama.
Since the IETF 124 hackathon, our team has been working on a TEEP+RATS
integrated reference implementation to provide better feedback to the
WGs.
During this effort, we have run into an integration issue with
commodity TEE remote attestation mechanisms (e.g., Intel SGX/TDX and
AMD SEV-SNP).
In this email, I'll propose adding `? raw_report_data => bstr` to TEEP
Protocol messages.


## Background and Motivation
In the current TEEP Protocol specification, the method for agreeing on
the cryptographic keys used by the security wrapper between the TAM
and the TEEP Agent is not explicitly specified.
This seems reasonable because multiple key agreement mechanisms may be
used depending on the deployment.
However, when Remote Attestation is part of establishing trust between
the TAM and the TEEP Agent, additional information may be required to
reliably bind the attestation Evidence to the key material used by the
TEEP Agent.

In widely deployed TEE technologies (Intel SGX, AMD SEV-SNP, Intel
TDX), Remote Attestation works as follows (in RATS terminology):

- The Attesting Environment produces attestation Evidence (e.g., a
Quote or Report).
- The Target Environment can supply up to 64 bytes of report_data,
which the Attesting Environment incorporates into the Evidence.
- When a Verifier successfully validates the Evidence (e.g.,
certificate chain and signatures), the Relying Party can confirm that
the report_data embedded in the Evidence exactly matches the value
provided by the Target Environment.

This mechanism is commonly used to cryptographically bind
application-specific data to Attestation Results.


## What We Are Trying to Achieve
We would like the TAM to verify that the TEEP Agent's public key was
generated inside a trustworthy TEE using Remote Attestation.
The intended flow is:

1. The TEEP Agent (running inside the Target Environment) generates a
key pair inside the TEE.
2. The TAM sends a QueryRequest containing a challenge.
3. The TEEP Agent encodes the following information as an EAT claim set:
```
EAT {
  cnf: TEEP Agent public key to claim proof-of-possession,
  eat_nonce: challenge-value the TAM sent in QueryRequest
}
```
4. Because this structure generally exceeds the 64-byte limit of
report_data, the hash of the EAT structure is placed into the
report_data field.
5. The Attesting Environment then produces the Evidence including this
report_data.

This approach is commonly used in existing Remote Attestation
implementations; for example, in Intel SGX-based flows [1].

[1] https://github.com/Azure-Samples/microsoft-azure-attestation/blob/master/sgx.attest.sample.oe.sdk/genquotes/common/attestation.cpp#L17-L61


## Problem Statement
In the current TEEP Protocol:

- QueryResponse allows the TEEP Agent to send Evidence to the TAM via
attestation-payload.
- However, when Evidence such as an Intel SGX Quote is included, there
is **no field** to carry the original data that was hashed into
report_data (i.e., the EAT structure containing the TEEP Agent's
public key and the TAM's challenge).

As a result, even after the Evidence is successfully verified by a
Verifier, the TAM cannot recompute the hash over the original EAT
content and compare it with the report_data embedded in the Evidence.


## Proposed Change
Add the following optional field to TEEP Protocol messages which carry
the Evidence (i.e., both QueryRequest and QueryResponse):
```cddl
? raw_report_data => bstr
```

Note: While Evidence typically appears in QueryResponse (TAM -> Agent
challenge, Agent -> TAM Evidence), bidirectional attestation is also
possible (e.g., the Agent challenges the TAM and carries Evidence in
QueryRequest). The optional raw_report_data field therefore applies to
a QueryRequest message that carries Evidence.


## Benefits
In the Background-Check Model, this enables the following verification flow:

1. The TAM forwards the Evidence from QueryResponse to a Verifier.
2. Upon successful verification, the TAM computes the hash of raw_report_data.
3. The TAM compares that hash with the report_data value embedded in
the Evidence.
4. If they match, the TAM can confirm that:
  - The Evidence was generated in response to the specified challenge, and
  - The TEEP Agent public key was generated inside a trustworthy TEE.

This provides a clear cryptographic binding between the Evidence, the
challenge, and the TEEP Agent's public key.


## Discussions
Q1. Is raw_report_data valuable also for the Passport Model?
A1. Yes, we believe that raw_report_data is valuable also for the
Passport Model.
Even if Evidence were embedded directly into the Attestation Results
by using mechanisms such as ear.raw-evidence defined in EAR [2], it
appears that EAR currently does not define any field that corresponds
to raw_report_data itself.
In other words, while EAR allows raw Evidence to be carried, it does
not seem to provide a way to convey the original report_data from
which that Evidence was derived.
>From this perspective, preserving raw_report_data still has value,
even in the context of the Passport Model.

[2] https://datatracker.ietf.org/doc/html/draft-ietf-rats-ear#section-3-5.8.1

Q2. Why is this not proposed for the Update message?
A2. In the Update message, the attestation-payload is limited to
Attestation Results, which are consumed by the "Other Relying Party"
described in Figure 1 of the TEEP Protocol draft [3].
Even if the Other Relying Party were to require all of
raw_report_data, Evidence, and Attestation Results, both
raw_report_data and Evidence are already held by the TEEP Agent.
Therefore, it is unnecessary to return them again via the Update message.

There may be some Attestation Results for which the Other Relying
Party cannot verify the binding among Attestation Results, Evidence,
and raw_report_data.
However, such limitations may arise from differences in the
information available to the TAM and to the Other Relying Party, and
the binding mechanisms that each of them can realistically employ.
For example, when a TAM submits Evidence to a Verifier via an HTTP
POST and receives the corresponding Attestation Results in the
response, the TAM may establish the binding between Evidence and
Attestation Results through the association of the HTTP request and
response messages themselves.
In such cases, it is meaningful for the Verifier to return Attestation
Results that include raw Evidence using mechanisms such as
ear.raw-evidence defined in EAR [2].
By doing so, the Attestation Results can carry an explicit,
cryptographically verifiable linkage to the Evidence, enabling the
Other Relying Party to securely bind the Attestation Results and the
Evidence without relying on the original transport context.
>From this perspective, recommending the use of ear.raw-evidence in the
EAT Profile of the TEEP Protocol would be reasonable.

If, on the other hand, only Attestation Results that cannot provide
such explicit bindings are available to the Other Relying Party,
handling those cases can be considered out of scope for the TEEP
Protocol, rather than extending the Update message to carry additional
data.

[3] https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol#figure-1

Best regards,
Ken