]> Independent

ietf@nritz.com

ARM

ionut.mihalcea@arm.com

University of the Bundeswehr Munich

Neubiberg Bavaria 85577 Germany hannes.tschofenig@gmx.net

Nokia

kondtir@gmail.com

Security Secure Evidence and Attestation Transport remote attestation TLS-terminating proxy HPKE extended key update CMW RATS Privacy Framework This document specifies a transport-layer mechanism to establish an end-to-end cryptographic channel across a cooperative secure channel protocol intermediary, such as a TLS-terminating proxy. The mechanism enables Remote Attestation Evidence to remain bound to the true end-to-end endpoints even when the initial secure channel handshake is mediated by an intermediary. It uses an ephemeral HPKE challenge exchange, intra-handshake Evidence delivery, and an attestation-bound key update to evict the intermediary from Layer 7 visibility before application data is exchanged. Discussion Venues Discussion of this document takes place on the Secure Evidence and Attestation Transport Working Group mailing list (seat@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document operates within the Remote ATtestation procedureS (RATS) architecture and addresses a specific deployment constraint: the presence of a TLS-terminating intermediary in the path between a RATS Attester and its Relying Party. A prominent class of deployments where this condition fails is the enterprise environment. Organizations deploying MDM-enrolled, enterprise-controlled devices routinely route device-to-service traffic through TLS-terminating infrastructure -- corporate reverse proxies, API gateways, mobile device management policy enforcement points, and enterprise web application firewalls. In these environments, the device holds a TLS connection to enterprise-managed infrastructure, not to the remote attested origin with which it ultimately communicates. Major platform vendors, including cloud productivity and device management providers, regularly publish lists of endpoints for which TLS inspection must be disabled, sometimes referred to as compliance modes. These exclusions are necessary to prevent the intermediary from interfering with the trust mechanisms those endpoints depend on. These existing modes provide an opportunity to integrate Remote Attestation, replacing "administrative trust" with cryptographic proof that an intermediary is not party to sensitive application data. When a TLS-terminating intermediary is present, the client establishes a TLS connection to the intermediary, and the intermediary establishes a separate connection to the origin. The two connections have independent handshake transcripts. Intra- handshake attestation protocols that cryptographically bind Evidence to the connection transcript are therefore binding to the client-to- intermediary connection, not to the connection to the origin. Any attestation produced by the origin references a different cryptographic context than the one the client holds. The end-to-end binding on which transport-layer attestation depends is severed at the proxy boundary. This document defines a cryptographic transport and proxy eviction mechanism. It does not define attestation Evidence profiles, claim formats, or identity document structures. The mechanism establishes binding for both intra-handshake attestation (for example, Early Attestation ) and post-handshake attestation (for example, EXPAT ). These are named as examples; the mechanism is agnostic to the specific attestation protocol. For intra-handshake Evidence delivery, this document uses the attestation extension defined in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the following terms.

Cooperative intermediary:

A TLS-terminating proxy that forwards the signalling defined in this document during connection establishment and that honours the transition to Layer 4 forwarding upon key rotation. A cooperative intermediary is not part of the origin's Trusted Computing Base.

Client (Relying Party, RP):

The endpoint that verifies the origin's attested properties.

Origin (Attesting Server):

The endpoint whose attested properties the client wishes to verify, reachable only through one or more intermediaries.

Ephemeral KEM key pair (skE / pkE):

A Key Encapsulation Mechanism key pair generated fresh by the client for a single session and never reused, used as the recipient key for HPKE Base Mode (Mode 0) operations.

Origin KEM key (pkR):

The origin's KEM public key, distributed in an Identity Document and authenticated by the client prior to the handshake as described in the Origin Key Provisioning section.

Identity Document:

A signed document such as an EAT Attestation Result (EAR) . The Identity Document carries pkR. The signature provides a self-contained integrity guarantee, allowing the document to be fetched over untrusted channels.

Challenge nonces (cnC, cnR):

Ephemeral random values exchanged between client and origin under HPKE. cnC is generated by the client and sealed to pkR; cnR is generated by the origin and sealed to pkE.

psk_attest:

A symmetric secret derived from cnC and cnR. It is injected into the Extended Key Update key schedule to rotate traffic keys, evicting the intermediary from the session.

Attestation Binder:

The cryptographic value bound into the attestation Evidence, ensuring per-session freshness and end-to-end connection binding. In this document, it is derived from the ephemeral KEM public keys exchanged during the HPKE challenge, replacing the severed TLS transcript hash as the session anchor.

Overview A TLS-terminating intermediary severs the RA+TLS channel binding on which attestation depends, regardless of when attestation occurs. Major platform vendors already define endpoint sets for which TLS inspection must be disabled in order to preserve endpoint-specific trust properties. This document reuses that operational pattern and replaces administrative exclusion with a cryptographic mechanism: the proxy cooperates during handshake-time signalling, forwards encrypted Evidence without decrypting it, and is then mechanically evicted from Layer 7 visibility by an attestation-bound key update. The mechanism is designed against the trust-boundary requirements identified for proxy-fronted attested channels. An implementation conforming to this document:

1. MUST establish a channel identity that is cryptographically bound to the attested origin endpoint even though connection establishment traverses a TLS-terminating intermediary.
2. MUST use object-layer encryption for Evidence payloads to maintain confidentiality from the Layer 7 intermediary.

Architectural Advantages No nested encryption. Post-eviction, application data flows over standard TLS traffic keys on the origin-bound channel. No outer tunnel wraps an inner tunnel; the attested connection carries application data without additional encapsulation overhead. Broad deployment without per-application modification. Attestation is handled at the proxy and TLS library layer. Every application communicating through a cooperative intermediary receives attestation coverage without modification, extending equally to legacy and modern software in the same estate. Evidence privacy. Evidence is encrypted independently of the TLS session using object-level encryption. The privacy motivation for object-level protection in RATS deployments is discussed in . The cooperative intermediary can read plaintext CMW routing headers but cannot access the Evidence payload, maintaining confidentiality of an Attester's measurements from infrastructure outside the broader network of trust.

State Machine A session proceeds through the following states:

Session state transitions

Proxy Handshake Behavior The following diagram and algorithm define the complete behavior of a cooperative intermediary executing a proxy-traversal session under the Background Check Model. The diagram borrows the message notation of Figure 5; content fully specified by that document is shown as .... In the diagram, [EA §6 extensions] denotes the attestation negotiation extensions defined in Section 6 of .

Proxy handshake message flow (Background Check Model) | [DETECT] | | | ClientHello | | | + nonce_challenge_ext | | | (pkE, ctC) [fwd] | | |------------------------>| | | | |<======= ServerHello, both legs ================>| | | | | | {EncryptedExtensions} | | | + nonce_challenge_ext | | | (ctR) | | |<------------------------| | {EncryptedExtensions} | | | + nonce_challenge_ext | | | (ctR) [relayed] | | |<----------------------| | | | {Certificate*} | | | + attestation* | | |<------------------------| | {Certificate*} | | | + attestation* | | | [cmw routed] | | |<----------------------| | | | | |<===== {CertVerify*} + {Finished}, both legs ===>| | | [ARMED] | | {Certificate*} | | | + attestation* | | |---------------------->| | | | {Certificate*} | | | + attestation* | | | [cmw routed] | | |------------------------>| |<===== {CertVerify*} + {Finished}, both legs ===>| | | | | ExtendedKeyUpdate | | | [psk_attest] | | |---------------------->| [TRIGGERED] | | | ExtendedKeyUpdate | | | [fwd, Buffer Drain] | | |------------------------>| | | | | [Application Data -- end-to-end encrypted] | |<===============================================>| | (proxy: opaque L4 forwarder) | ]]>

The proxy MUST execute the following steps:

1. Receive ClientHello from the RP. If the ClientHello contains an nonce_challenge_ext extension alongside one or more of the attestation negotiation extensions defined in Section 6 of , enter DETECT state. Otherwise, process as a standard TLS connection.
2. Initiate the Leg B connection to the Attesting Server. Construct a ClientHello carrying all negotiation extensions from the RP's ClientHello. The nonce_challenge_ext extension MUST be forwarded with pkE and ctC unchanged.
3. Relay the ServerHello received from the Attesting Server to the RP without modification.
4. Relay the EncryptedExtensions received from the Attesting Server to the RP. The nonce_challenge_ext extension carrying ctR MUST be forwarded unchanged.
5. Receive the Certificate message from the Attesting Server. Inspect the plaintext CMW ind header of the cmw_payload carried in the attestation extension to determine routing. Forward the cmw_payload to the RP without decrypting the Evidence payload.
6. Relay CertificateVerify and Finished from the Attesting Server to the RP. Enter ARMED state.
7. Receive the Certificate message from the RP. Inspect the plaintext CMW ind header and route the cmw_payload to the Attesting Server. The Evidence payload MUST NOT be decrypted.
8. Relay CertificateVerify and Finished from the RP to the Attesting Server.
9. Receive ExtendedKeyUpdate from the RP. Enter TRIGGERED state. Forward the ExtendedKeyUpdate to the Attesting Server. Execute the Buffer Drain procedure defined below. Activate Layer 4 transparent forwarding for all subsequent records on both connections.

Mechanical Eviction Before the key update, the intermediary holds the application traffic keys of the terminated connection and can read and rewrite application records at Layer 7. After the key update, the live traffic keys are derived from main_secret_N+1, which is a function of combined_ikm and therefore of psk_attest. An entity that cannot derive cnR cannot derive psk_attest, cannot compute main_secret_N+1, and cannot derive any traffic key from it. The DETECT, ARMED, and TRIGGERED state transitions governing eviction are defined in the Proxy Handshake Behavior section.

Buffer Drain:

Before activating Layer 4 forwarding, the intermediary MUST complete the following steps in the order given:

1. The intermediary MUST cease reading from both the client-facing and origin-facing transport connections.
2. Any bytes received from the client-facing connection that have been buffered beyond the final Extended Key Update record boundary MUST be written to the origin-facing connection in order, without modification or decryption.
3. Any bytes received from the origin-facing connection that have been buffered beyond the final Extended Key Update record boundary MUST be written to the client-facing connection in order, without modification or decryption.
4. Only upon confirming that both transport directions have been fully drained MUST the intermediary activate Layer 4 transparent forwarding for all subsequent records on both flows of that session.

The intermediary MUST NOT activate Layer 4 forwarding before completing steps 1 through 4. Bytes forwarded in steps 2 and 3 are post-rotation ciphertext that the intermediary cannot decrypt; they MUST be treated as opaque octets.

The Ephemeral HPKE Challenge Exchange The challenge exchange is carried in a single TLS extension, nonce_challenge_ext, which appears with distinct contents in the ClientHello and in the EncryptedExtensions. Its presence is the capability signal for this mechanism; an intermediary that does not recognise it forwards it unmodified, and an origin that does not support it omits the EncryptedExtensions variant.

Origin Key Provisioning Before initiating the handshake, the client MUST obtain and authenticate the origin's KEM public key pkR. Clients MUST maintain a trust anchor store from which the Identity Document can be authenticated; trust anchors MAY be self-signed certificates, raw public keys, or JWK keys . The details of trust anchor maintenance and path validation are outside the scope of this document. pkR is distributed in an Identity Document, such as an EAR whose ear_managed_keysets claim carries pkR as a JWK with key_ops set to ["encrypt"], under the keyset name "hpke-kem-key". Because the EAR's Verifier signature provides a self-contained integrity guarantee, the fetch MAY occur over untrusted channels. The client MUST verify the EAR signature against its trust anchor store and extract pkR from the "hpke-kem-key" entry of ear_managed_keysets before proceeding with ClientHello processing.

ClientHello Processing Prior to the handshake the client obtains pkR as described in the Origin Key Provisioning section above. The client generates a fresh, single-use ephemeral KEM key pair (skE, pkE), generates a random challenge nonce cnC, and seals it to the origin using HPKE Base Mode (Mode 0) as defined in Section 5.1 of . The client places pkE and ctC in the nonce_challenge_ext extension of the ClientHello. aad_ct binds the ciphertext to the target origin's KEM key, the client's fresh random, and the negotiated key-exchange parameters, so the ciphertext cannot be replayed to a different origin or across sessions. The intermediary forwards the ClientHello to the origin. Because the intermediary does not hold skR, it cannot recover cnC.

EncryptedExtensions Processing The origin recovers the nonce by decapsulation using HPKE Base Mode: Successful opening proves the origin's possession of skR. The origin generates its counter-challenge cnR and seals it to the client's ephemeral key, again using HPKE Base Mode: The origin returns ctR in the nonce_challenge_ext extension of the EncryptedExtensions. The client recovers cnR: Only the holder of skE -- the client -- can recover cnR.

Derivation of psk_attest and Attestation Binder Both endpoints now hold both nonces. The end-to-end Attestation Binder is derived from the ephemeral KEM public keys exchanged during the HPKE challenge: Hash is the hash of the negotiated TLS 1.3 cipher suite. By incorporating the respective ephemeral KEM public key into the context hash, the Attestation Binder locks the resulting Evidence to the specific HPKE parameters used to traverse the proxy, binding the Evidence to the true end-to-end participants and replacing the severed proxy transcript.

Intra-Handshake Evidence Delivery Evidence is delivered during the TLS handshake via the attestation extension in the Certificate message, as defined in . However, to ensure the cooperative intermediary can route the evidence without violating the confidentiality of the workload, the payload MUST be structured as follows:

1. Evidence Generation: The Attester generates its Evidence (e.g., an EAT) and binds it to the session by placing rdata in the eat_nonce claim, where rdata is computed as: This commits the signed Evidence to both the KEM public keys (via s_attest_binder) and the dual-nonce session secret (via psk_attest), ensuring the quote is bound to the full end-to-end exchange. To cryptographically commit to the proxy-traversing HPKE exchange and prevent the TEE from acting as a blind signing oracle, the Evidence MUST explicitly include the public parameters of the origin KEM key (pkR) within the standardized cnf claim.
2. Object-Level Encryption: To preserve confidentiality from the terminating intermediary, the Evidence MUST be encrypted to the public key of the receiving endpoint, for example using COSE_Encrypt0. This follows the object-level confidentiality architecture discussed in .
3. CMW Encapsulation: The encrypted envelope is placed inside a Conceptual Message Wrapper (CMW) Record . The outer CMW headers (such as the ind field indicating Evidence) remain in plaintext.

Because the cooperative intermediary terminates TLS, it generates its own Certificate message for the backend connection to the origin and MUST actively move the attestation extension between the two connections. Adapting the routing role of the Lead Verifier to a zero-trust posture, the intermediary acts only as a router and never as a Verifier: it MUST NOT decrypt, decode, or appraise the inner Evidence. The complete routing procedure is defined in the Proxy Handshake Behavior section, steps 5 and 7.

Key Schedule Integration and Proxy Eviction Immediately upon completion of the TLS handshake, the client initiates an Extended Key Update that injects psk_attest into the key schedule. This rotates the application traffic keys to values that incorporate attestation-derived keying material inaccessible to the intermediary.

PSK-Injected Key Derivation The Extended Key Update performs a fresh (EC)DHE (or KEM) exchange yielding the shared secret eku_dh_shared. In the standard EKU key schedule, Derive-Secret(main_secret_N, "derived", "") serves as the HKDF-Extract salt, chaining the new secret to the prior session state. Because the proxy terminated the original TLS connection, the client and origin do not share a common main_secret_N; applying that derivation would produce mismatched keys at the two endpoints. This document therefore mandates a key schedule reset: the HKDF-Extract salt MUST be set to 0, severing the chain to the proxy-terminated session, and the input keying material MUST be the concatenation of eku_dh_shared and psk_attest. A zero salt instructs the key schedule to treat this rotation as a fresh derivation anchored entirely in combined_ikm, analogous to how TLS 1.3 derives its Early Secret from a PSK with no prior session state.

Key Derivation Hierarchy with Key Schedule Reset HKDF-Extract = main_secret_N+1 | +-----> Derive-Secret(., "c ap traffic", | transcript_hash_N+1) | = client_application_traffic_secret_N+1 | +-----> Derive-Secret(., "s ap traffic", | transcript_hash_N+1) | = server_application_traffic_secret_N+1 | +-----> Derive-Secret(., "exp master", | transcript_hash_N+1) = exporter_secret_N+1 ]]>

Post-Handshake Re-Attestation After eviction the client and origin share a common main_secret_N+1 and the connection is an ordinary end-to-end TLS session. Any subsequent Extended Key Update is therefore a normal end-to-end exchange: the proxy is already a Layer 4 forwarder and plays no cryptographic role, so the key schedule reset used at eviction does not apply and standard EKU chaining is used. Each such rotation produces a fresh transcript_hash_N+1 and a fresh exporter_secret_N+1, suitable for anchoring a new round of attestation: an intra-handshake-style mechanism re-anchors to the transcript, and a post-handshake-style mechanism re-anchors to the exporter. For example, EXPAT performs its initial attestation immediately after the handshake completes and re-attests by initiating a fresh Exported Authenticator exchange. This mechanism aligns its Extended Key Update to that same post-handshake instant; the resulting exporter_secret_N+1 is the end-to-end exporter the EXPAT binder consumes, which the evicted intermediary cannot reproduce. No element of the post-handshake protocol is otherwise modified.

Security Considerations The adversary of concern is a TLS-terminating intermediary that attempts to retain unauthorised Layer 7 visibility after the point at which it is expected to step down to Layer 4 forwarding, or attempts to read sensitive Evidence payloads.

Key Separation The mechanism relies on the separation between the key-encapsulation role (the KEM key pair) and the TLS identity/authentication role. The ephemeral skE is generated by the client, never transmitted, and never reused. An intermediary that terminates TLS observes every plaintext handshake message, including the EncryptedExtensions carrying ctR, yet cannot open ctR without skE.

Transcript and Replay Binding Because the TLS-terminating intermediary breaks the native TLS transcript hash by terminating the connection, the end-to-end Attestation Binder is derived from the out-of-band HPKE exchange instead. aad_ct binds ctC to pkR, the ClientHello random, and the negotiated parameters, preventing replay to a different origin or session. aad_ee is Hash(cnC): because cnC was HPKE-sealed to pkR and is never transmitted in the clear, the intermediary cannot observe it, making aad_ee opaque to the proxy despite the severed transcript. An adversary cannot transfer either ciphertext to a different origin or a different handshake.

Object-Level Confidentiality Because the proxy terminates TLS, the Certificate message is visible to the proxy in plaintext. The confidentiality of the Attester's Evidence relies entirely on the object-level encryption (e.g., COSE_Encrypt0) applied to the Evidence payload. The proxy can only view the unencrypted outer CMW routing headers. This confidentiality guarantee is independent of transport security: the Evidence payload remains confidential from the intermediary regardless of whether it is cooperative or hostile, because confidentiality is a property of the object, not the channel. The privacy architecture motivating this object-level protection is discussed in .

Non-cooperative and Malicious Intermediaries A non-cooperative intermediary that suppresses the nonce_challenge_ext extension or refuses the Extended Key Update eviction trigger cannot derive post-rotation traffic keys. The session terminates rather than continuing on a compromised channel, providing fail-secure behaviour against both misconfigured and malicious intermediaries without requiring explicit detection of adversarial intent.

Interaction with Post-Handshake Attestation Intra-handshake Evidence delivery and the Extended Key Update complete before any post-handshake protocol window opens. For mechanisms such as EXPAT that depend on an end-to-end channel, this ordering structurally closes the race condition that arises when Exported Authenticators operate over a proxy-terminated session. Section 5.2.2 of explicitly states that if the party generating an Exported Authenticator does so on a different connection than the party validating it -- including situations in which application data is sent via a TLS-terminating proxy -- the Handshake Context will not match and the CertificateVerify will not validate. The tls-exporter binding defined in is unique to each TLS connection; a terminating proxy creates two independent sessions with independent EKM values, producing exactly this condition. EXPAT , which builds on Exported Authenticators, therefore cannot function across a TLS-terminating proxy without the end-to-end channel this document restores. The mechanism defined here is a prerequisite for EXPAT to function in proxy-fronted deployments.

Key Substitution and Oracle Protection Key binding to an attested execution environment is a complementary concern addressed by . In proxy-fronted topologies, the TLS handshake is terminated by the intermediary, removing the standard transport-layer proofs of possession. If the origin TEE signs an Attestation Binder provided by the untrusted host OS without cryptographically committing to the key exchange material, an active attacker could execute the HPKE challenge exchange themselves and use the TEE as a blind signing oracle, producing valid-looking Evidence bound to attacker-controlled KEM parameters. To mitigate this, the Evidence MUST explicitly carry the public parameters of the key that executed the HPKE decapsulation (pkR) using the EAT cnf claim. By enforcing this parameter-by-parameter match, the protocol guarantees that the private component of the key executing the HPKE exchange is physically confined within the exact execution context being attested, wholly mitigating key substitution.

IANA Considerations IANA is requested to register the following entry in the "TLS ExtensionType Values" registry : Requested TLS ExtensionType registration

Value	Extension Name	TLS 1.3	DTLS-Only	Recommended
TBD1	nonce_challenge_ext	CH, EE	N	Y

The nonce_challenge_ext extension is permitted in the ClientHello (CH) and in the EncryptedExtensions (EE); its contents differ per message as defined in this document. Its presence in EncryptedExtensions is conditional on its presence in the corresponding ClientHello.

References Normative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Siemens Münster Univ. of Applied Sciences Nokia Siemens Zscaler TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh execution of the key exchange negotiated during the initial handshake within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. Intuit Arm Limited Arm Limited Linaro Nokia The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using remote attestation which is a process by which an entity produces Evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of TLS extensions that enable the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Linaro Cisco Arm Limited Fraunhofer SIT This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of Channel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677. Arm Ltd Huawei Technologies France S.A.S.U. Huawei Technologies France S.A.S.U. Fraunhofer SIT IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. Cryptic Forest Software University of the Bundeswehr Munich University of Applied Sciences Bonn-Rhein-Sieg This document extends the RATS Architecture to consider "coercive uses of RATS" where a malicious Verifier or Relying Party uses RATS protocols to extract sensitive information from an Attester or a victim Verifier that it would not otherwise be inclined to disclose. This over-disclosure can include revealing sensitive measurements, stable identifiers, device fingerprints, vendor information, or conclusions derived from Evidence. This document defines a privacy framework for Remote Attestation that identifies this threat surfaces; classifies claims produced by Attesters and Presenters; restricts sensitive Evidence disclosure to authorized Trusted Verifiers using confidentiality protection; and describes privacy- preserving Attestation Results based on data minimization, Selective Disclosure, and Zero-Knowledge Proofs. TU Dresden Linaro Nokia Intuit University of the Bundeswehr Munich Arm Limited This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. Nokia Independent This document extends the WIMSE workload-to-workload authentication architecture with a mechanism for conveying attestation across TLS- terminating proxies, a deployment topology where TLS-layer attestation mechanisms lose their end-to-end security properties. Cisco Cisco Cisco Arm Ltd. Consultant This document specifies how TLS and DTLS can be used at the application layer for the purpose of establishing secure end-to-end encrypted communication security. Encodings for carrying TLS and DTLS payloads are specified for HTTP and CoAP to improve interoperability. While the use of TLS and DTLS is straight forward we present multiple deployment scenarios to illustrate the need for end-to-end application layer encryption and the benefits of reusing a widely deployed and readily available protocol. Application software architectures for building, and network architectures for deploying application layer TLS are outlined. Inria Ericsson AB This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. Nokia University of the Bundeswehr Munich Linaro Arm Limited This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim defined in [RFC9711]. The proof of possession of the subject key is obtained from the surrounding protocol, such as TLS certificate-based authentication or CSR signature verification. Because the EAT is signed by a hardware-backed Attestation Key (AK), successful verification of the EAT signature together with protocol-level proof of possession establishes a cryptographic binding between the private key and the attested platform state. This mechanism addresses key substitution attacks that arise when attestation evidence and the certificate private keys are validated independently.

Related Work This appendix positions the transport-layer proxy eviction mechanism defined in this document relative to adjacent work on application-layer attestation, gateway-mediated attestation, and multi-verifier appraisal.

Relationship to WIMSE Workload Attestation addresses the same deployment topology at the HTTP application layer, requiring no changes to TLS or proxy infrastructure. This document operates at the transport layer and is applicable independently of application protocol. WIMSE Workload Attestation addresses deployments where application-layer carry of attestation information is readily available or where cooperative TLS intermediaries are not available.

Relationship to Application-Layer TLS Application-Layer TLS (ATLS) addresses end-to-end confidentiality across gateways and TLS-terminating middleboxes by running TLS or DTLS at the application layer and carrying the resulting TLS records over transports such as HTTP or CoAP. In that model, the middlebox remains part of the transport path but cannot inspect the application-layer protected content. This document addresses a related middlebox problem at a different layer and focuses on remote attestation. Rather than nesting an end-to-end TLS session inside an application-layer transport, it preserves the transport-layer interface used by RA+TLS mechanisms, establishes an attestation-bound key update, and then causes the cooperative intermediary to step down to transparent Layer 4 forwarding. ATLS is therefore most applicable when the application can explicitly carry an inner TLS record stream, whereas this document targets deployments that want attestation-bound end-to-end protection without requiring per-application encapsulation.

Relationship to Remote Attestation over EDHOC The structural problem this document addresses is not specific to TLS. Remote Attestation over EDHOC defines an Attestation Binder derived from the EDHOC transcript, serving the same relay-attack mitigation function as the transcript-based binder in TLS. When a gateway terminates EDHOC between an Attester and its ultimate Relying Party, that binding is severed at the gateway boundary, creating conditions for a relay attack regardless of whether the Evidence payload is sensitive. The cooperative blind-routing pattern defined in this document is architecturally applicable to this scenario; however, that treatment is out of scope for the current revision of this document (-00).

Applicability to Multi-Verifier Deployments In the hierarchical multi-verifier topology defined in , a Lead Verifier coordinates appraisal of a Composite Attester by receiving all Composite Evidence, decomposing it, and routing Partial Evidence to the appropriate Component Verifiers. This structural position gives the Lead Verifier visibility into Evidence it may not be authorised to appraise -- a concern explicitly identified in the Privacy Considerations of , which notes that Evidence containing sensitive information should be encrypted so that it can only be accessed by the intended Verifier. The cooperative blind-routing pattern defined in this document is applicable at the appraisal layer: object-level encryption of Partial Evidence to the target Component Verifier's key, with CMW plaintext headers carrying the routing directive, allows the Lead Verifier to route Evidence it cannot read -- converting an operational recommendation into a cryptographic guarantee.

Acknowledgments TODO