]> Independent

ietf@nritz.com

Security Secure Evidence and Attestation Transport attestation RATS TLS This document describes FACTS (Factor-based Attestation and Credential Transport Scheme) over TLS 1.3. Conceptually acting as "multi-factor authentication" for machine identities, factor-based attestation derives session trust from multiple independent cryptographic inputs rather than a single point of failure. Specifically, it utilizes a dual-key scheme that binds identity to attestation evidence through the use of key encapsulation material keys (KEM) and traditional identity signing keys (IK), establishing per-session freshness. About This Document Status information for this document may be found at . Discussion of this document takes place on the Secure Evidence and Attestation Transport Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Remote attestation enables an entity to demonstrate the integrity of its runtime environment to a remote peer. When combined with TLS , attestation allows a relying party to verify that the TLS endpoint operates within a Trusted Execution Environment (TEE) with known-good software before exchanging application data. This document combines the latency properties of intra-handshake attestation with the security binding of post-handshake attestation through a dual-key authentication architecture that introduces four targeted architectural changes that preserve the standard TLS 1.3 state machine and key schedule:

1. LTK and KEM Keys: Introduction of a dedicated encapsulation key (pubKEM), alongside the usual long-term signing or identity key (pubIK / LTK).
2. Early authentication: Accessing signed identity documents (e.g. signed JWT/CWT) just before starting the TLS handshake enables cryptographic binding of pubKEM to the server identity and pubIK jointly, closing the identity/key confusion gap that diversion attacks exploit.
3. Dual-Nonce Encapsulation: Encapsulation of mutual 'challenge' and 'counter-challenge' nonces (CN1, CN2) to the Server's pubKEM and the Client's per-session pubKEM, respectively.
4. Session-Specific Quote Encryption: Encrypting the attestation quote under psk_attest (derived from both challenge nonces), with the rdata committing to the full suite of parameters (pubIK_S, CN1, CN2, pubKEM_C).

The pre-handshake Identity Document is formatted as a JSON Web Token carrying keys in a JWKS cnf claim . No novel cryptographic structures are introduced by this document. JWT provides a self-contained, channel-independent integrity guarantee suitable for distribution over untrusted transports such as DNS.

Conventions and Definitions 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. The reader is assumed to be familiar with the vocabulary and concepts defined in , , and . FACTS relies on the RATS Conceptual Message Wrapper (CMW) for encapsulating attestation payloads and supports both the background-check and passport topologies defined in .

TLS Identity Key (privIK / pubIK aka LTK):

A long-term signing key pair used by a TLS peer for authentication during the handshake via CertificateVerify. In the threat model of this document, privIK is assumed to be potentially compromisable by an adversary with sufficient access to the software layer.

Encapsulation Key (privKEM / pubKEM):

A key pair used for Authenticated Hybrid Public Key Encryption (AuthHPKE, mode 2 of ). In the threat model of this document, privKEM is assumed to be potentially compromisable independently of privIK.

Attestation Key (privAK / pubAK):

A hardware-bound key pair rooted in the TEE's hardware root of trust (e.g., a TPM endorsement key, an Intel TDX report signing key, or an Arm CCA platform attestation key). The private component (privAK) MUST NOT be extractable from the hardware security boundary. This key pair is the trust anchor for the protocol's Evidence integrity.

Challenge Nonce (CN1, CN2):

Ephemeral random values exchanged between client and server during the handshake using AuthHPKE. CN1 is generated by the client and sealed to the server's pubKEM. CN2 is generated by the server and sealed to the client's pubKEM. Together they provide mutual freshness and form the basis for attestation key derivation.

Session Binding Commitment (rdata / eat_nonce):

The 32-byte SHA-256 digest SHA-256(pubIK_S || CN1 || CN2 || pubKEM_C) that binds the attester's identity key, both challenge nonces, and the client's ephemeral KEM key into a single compound nonce. No single party controls all four inputs. This value is conveyed in the platform-specific report data field of the TEE attestation report (where it is referred to as rdata) and as the eat_nonce claim when serialized as an EAT. Both carry the identical digest; the distinction is purely one of serialization layer.

Attestation Key Material (psk_attest):

A symmetric key derived from both challenge nonces. psk_attest is used to encrypt Evidence during the handshake and is subsequently injected into the Extended Key Update to rotate session traffic keys.

Trust Authority (TA / CA):

A trusted third party that signs the Identity Document, establishing a verifiable chain of trust. This document uses "CA" for simplicity.

Platform Measurements (quote):

The set of cryptographic measurements characterizing the Trusted Computing Base (TCB) of the platform, reduced to a 32-byte SHA-256 commitment (the Evidence Commitment) for use as input to key derivation.

Protocol Architecture

FACTS Architectural Topology

FACTS proceeds in three phases, preceded by an enrollment step that executes once per server instance. The protocol's trust model rests on two independently operating dimensions: the attestation ordering (which peer attests first) and the appraisal topology (how evidence is evaluated). These dimensions combine freely.

FACTS Decision Flow +---------------+ | | Enrollment/CA | |<--(AR Issued)----+---------------+ v +-------------------+ | Client Fetches AR | +---------+---------+ | v +-------------------+ | TLS Handshake | | (FACTS Phase 2) | +---------+---------+ | v / Server Policy: \ | Attest Now? | \ / | | (Yes) (No) | | v v +----------------+ +---------------+ | Standard Flow | | Cond. mTLS | | Server Attests | | Client Attests| +--------+-------+ +------+--------+ | | v v +-----------------------------------+ | Phase 3: EKU & PSK Injection | +-----------------+-----------------+ | v / Server Attest \ | Pending? | \ / | | (Yes) (No) | | v v +------------------+ (Mutual Attest Done) | Post-Handshake | | (SEAT Expat) | +--------+---------+ | v (Mutual Attest Done) ]]>

Enrollment. A device with no valid AR generates its identity and encapsulation key pairs and produces an EAT signed by its hardware-bound attestation key. The Verifier appraises the platform measurements and, if accepted, issues an AR carrying the dual-key binding: cnf for pubIK (signing) and attested_kem for pubKEM (encapsulation). This AR is distributed via DNS, HTTPS, or any untrusted channel; the Verifier's signature protects integrity. See for the enrollment protocol and for the AR and EAT claim structures. Phase 1 -- Identity Lookup. The client fetches and verifies the AR, extracting pubIK_S and pubKEM_S. It generates an ephemeral pubKEM_C, unique to this session and never reused. Phase 2 -- Attested TLS Handshake. The client seals a challenge nonce (CN1) to pubKEM_S; the server proves possession of privKEM_S by unsealing it, then seals its counter-challenge (CN2) to the client's ephemeral pubKEM_C. Both peers derive psk_attest. The handshake then branches on server policy. In the standard flow, the server includes its encrypted evidence in the Certificate message. In the conditional mTLS flow, the server withholds its evidence and issues a facts_attest_req, requiring the client to attest first. The choice between Passport and Background Check topologies is orthogonal to this ordering and applies independently to either flow. Phase 3 -- EKU with PSK Injection. After evidence appraisal, an Extended Key Update mixes psk_attest into the traffic keys. Any adversary lacking privKEM_C cannot derive the rotated keys and is evicted. Post-Handshake. If the server deferred attestation, it delivers evidence via Exported Authenticators over the rotated channel. Periodic reattestation is available to any flow via the same mechanism.

Protocol Flow The following diagram illustrates the 3 phase flow:

The 3 phase flow of FACTS-TLS | | | | [4] Decapsulate + Verify | | +---------------------------------+ | | hpkeOpen(ct, aad_ct, privKEM_S) | | | verify psk_binder; new CN2 | | +---------------------------------+ | | | [5] ServerHello | | + key_share | | <------------------------------------------------- | | | | [6] {EncryptedExtensions} | | + facts_challenge(HPKE{CN2}_{pubKEM_C})| | <------------------------------------------------- | | | | [7] Decapsulate CN2 | \ +---------------------------------------+ | | | hpkeOpen(cn2_ct, aad_ee, privKEM_C) | | [Phase 2] | `psk_attest` = derive(CN1, CN2) | | | +---------------------------------------+ | / | | | [8] {Certificate} | | + facts_attestation | | + (pubIK, selfsign, | | + AEAD{quote}_{psk_attest}) | | <------------------------------------------------- | | | | [9] Verify Certificate | +---------------------------------------+ | | verify(pubCA, identity_doc, sig) | | | attest_open(encQuote, `psk_attest`) | | | verify(pubAK, dataSign, sig) | | | check hash(pubIK,CN1,CN2,pubKEM_C) | | +---------------------------------------+ | | | | [10] {CertificateVerify} | | <------------------------------------------------- | | | | [11] {ServerFinished} | | <------------------------------------------------- | | | | [12] {ClientFinished} | | -------------------------------------------------> | | | | - - - - - - - - - Post Handshake - - - - - - - - - | | | | [I-D.ietf-tls-extended-key-update, | | (requires EKU-PSK extension) | | | | [13] Derive post-rotation key for PFS | \ +-------------------------------------------+ | | | eku_key = (eku_dh_shared || `psk_attest`) | | [Phase 3] +-------------------------------------------+ | | | [14] {EKU Request} =========================> | / | [15] {EKU Response} <========================= | | | | <===============================================> | | [16] Application Data | | [17] Periodic re-Attestation health checks | | [e.g., I-D.fossati-seat-expat] | | <===============================================> | | | ]]>

Split-Session Alternative An alternative design uses a sacrificial bootstrap handshake followed by PSK-DHE resumption on a new TCP connection, rather than EKU within a single connection.

Split-Session Alternative: Bootstrap + PSK-DHE Resume |---------------------->| | | SH + EE + CRT + | | | facts_attestation | |<---------------------|<----------------------| | | | | Verify Evidence | | | Derive psk_attest | | | Exporter + CN1,CN2 | | | Finished NOT sent | | | | | |- - ABORT Session 0.5 - - - - - - - - - - - - | |- - - Session 1.0: PSK-DHE Resume - - - - - - | | (new TCP connection) | | | | CH2 + PSK binder | | + 0-RTT EarlyData | | ============================================>| | <=========================================== | | | ]]>

The EKU-based design is the practical extension of this concept: it replaces the connection tear-down and PSK-DHE resumption with an in-band EKU exchange, saving one TCP round-trip (SYN/SYN-ACK) plus the second ClientHello flight. Both produce equivalent post-rotation security. The split-session variant is useful for legacy stacks without EKU support.

Key Schedule Integration FACTS integrates with the TLS 1.3 key schedule at two points: the Early Secret (for PSK binder validation) and the Extended Key Update (for traffic key rotation).

Early Secret Binding CN1 is used to derive a PSK that feeds into the Early Secret computation, enabling PSK binder validation in the ClientHello.

psk_attest Derivation Both peers derive the attestation key material from the concatenation of both challenge nonces: psk_attest serves two purposes: it encrypts Evidence during the handshake (via AEAD), and it is injected into the EKU key schedule after Evidence appraisal.

AAD Construction Two distinct AAD values are used, one per HPKE operation. Both MUST be computed as specified here; deviations invalidate the session-binding properties of the protocol. aad_ct — used when sealing CN1 in facts_challenge (ClientHello): This binds the CN1 ciphertext to the target server's KEM key, the client's fresh random, and the negotiated parameters. An adversary cannot replay the ciphertext to a different server or across sessions. aad_ee — used when sealing CN2 in facts_challenge (EncryptedExtensions): This binds the CN2 ciphertext to the full handshake transcript up to that point (log_SH). The CN2 ciphertext is therefore specific to the handshake in flight and cannot be transferred to any other session. Implementations MUST use the negotiated handshake hash algorithm for both computations. The NegotiationOffer in aad_ct is the offer value from the key exchange negotiation as carried in the ClientHello.

Evidence Binding The attester binds the TEE Evidence to the TLS session by including session-specific data in the TEE-signed attestation report.

Report Data Construction The report data (rdata) binds the Evidence to both the attester's identity key, the mutually exchanged nonces and the Client's own ephemeral per-session pubKEM KEM.

Extended Key Update with PSK Injection After Evidence appraisal succeeds, the client initiates an Extended Key Update that injects psk_attest into the key schedule, rotating the traffic keys to values that incorporate attestation-derived keying material.

Procedure

1. The client generates an ephemeral key pair for the EKU exchange: (eku_x, g^eku_x).
2. The client sends an EKU request containing g^eku_x.
3. The server generates its ephemeral key pair: (eku_y, g^eku_y).
4. Both peers compute the EKU Diffie-Hellman shared secret: eku_dh = DH(g^eku_x, eku_y) (equivalently, DH(g^eku_y, eku_x)).
5. Both peers construct the combined input keying material: combined_ikm = eku_dh || psk_attest
6. Both peers derive new traffic keys:

FACTS Key Schedule for Extended Key Update

EKU Key Schedule with PSK Injection HKDF-Extract(stored, combined_ikm) | main_secret_N+1 / \ ' ' Derive Derive "c_app_traffic_N+1" "s_app_traffic_N+1" | | eku_cts eku_sts ]]>

Because combined_ikm includes psk_attest, which requires knowledge of CN2, any entity that cannot derive CN2 (because it lacks privKEM_C to unseal the server's Ctx2) cannot compute main_secret_N+1 or any traffic keys derived from it.

Interaction with draft-ietf-tls-extended-key-update The PSK injection mechanism defined in this section extends the EKU key schedule specified in . The standard EKU derivation uses only the DH shared secret as IKM; FACTS concatenates psk_attest to the DH shared secret before extraction. All other aspects of the EKU exchange (message formats, transcript construction, key switch timing) remain as specified in .

Extension Definitions

The facts_hello Extension The facts_hello extension is carried in the ClientHello and serves as the capability signal for FACTS. Its presence indicates that the client supports the FACTS protocol and is prepared to send facts_challenge. It optionally carries a hw_id hint that identifies the hardware platform, enabling the CA or Verifier to select the correct endorsement key bundle, manufacturer reference values, and appraisal policy before the attestation quote arrives. ; /* opaque platform identifier */ case no_hw_id: /* empty */ }; } FactsHello; ]]> version MUST be facts_hello_v1. Servers that do not recognize the version MUST ignore the extension. hw_id is an opaque value whose encoding is platform-specific. It is not a credential and is not secret. It is transmitted in the clear in ClientHello. Deployments with elevated privacy requirements SHOULD use no_hw_id and rely on the facts_attest_req context for platform identification, or deliver platform identity inside the encrypted facts_attestation payload instead.

The facts_challenge Extension The facts_challenge extension carries HPKE-sealed challenge nonces. It appears in two messages with distinct structures and HPKE modes.

ClientHello Variant ; /* ID_C: connecting peer identity */ opaque pubKEM_C<1..2^16-1>; /* ephemeral per-session KEM public key */ opaque ct<1..2^16-1>; /* sealed CN1 */ } FactsChallengeClient; ]]> The ciphertext ct MUST be computed as: where aad_ct is computed per . The server MUST verify that pubKEM_C is a valid public key for the negotiated KEM group before proceeding.

EncryptedExtensions Variant ; /* sealed CN2 */ } FactsChallengeServer; ]]> The ciphertext ct MUST be computed as: where aad_ee is computed per . The facts_challenge extension in EncryptedExtensions MUST NOT appear unless the corresponding facts_challenge was present in the ClientHello. Servers that receive facts_challenge in ClientHello without a facts_hello extension MUST abort with missing_extension.

The facts_attestation Extension The facts_attestation extension is carried in the Certificate message and delivers the encrypted TEE Evidence along with the self-signed key binding. It is the sole extension defined by this document that is permitted in the Certificate message. ; /* attester's identity public key */ opaque selfsign<1..2^16-1>; /* sign(privIK, (pubIK || encEvidence)) */ opaque encEvidence<1..2^16-1>; /* AEAD{CMW-wrapped quote}_{psk_attest} */ } FactsAttestation; ]]> pubIK MUST match the public key in the Certificate's leaf entry. The client MUST abort with illegal_parameter if they differ. selfsign is a signature over the concatenation of pubIK and encEvidence, produced by privIK. It binds the identity key to the encrypted Evidence payload within the same Certificate message, preventing substitution of one attester's Evidence under another attester's certificate. encEvidence is the attestation quote encrypted under psk_attest using AEAD (ChaCha20-Poly1305 per ). The plaintext is a RATS CMW-wrapped Evidence payload per .

Enrollment Certificate enrollment has a foundational chicken-and-egg problem in TEE environments: a client needs credentials to authenticate to a CA, but obtaining credentials is the reason it is connecting to the CA in the first place. FACTS uses the mTLS handshake wire format to deliver the client's X.509 certificate over a channel that is cryptographically proven to terminate at the verified hardware boundary: the CA's challenge nonce (CN2) is sealed to the client's ephemeral pubKEM_C, the client's TEE evidence binds that nonce and the client's fresh pubLTK_C in the hardware-signed quote, and the resulting certificate arrives over traffic keys that only a party holding privKEM_C could have derived.

Attestation over mTLS supplying RATS AR | | | | [8] Verify Client Cert | | +------------------------------+ | | attest_open(client_encQuote, | | | psk_attest) | | | verify(pubAK, dataSign, sig) | | | check hash(pubIK_S, CN1, | | | CN2, pubKEM_C) | | +------------------------------+ | | | [9] {CertificateVerify} | | -------------------------------------------------> | | | | [10] {ClientFinished} | | -------------------------------------------------> | | - - - - - - - - - Post Handshake - - - - - - - - - | | | | [I-D.ietf-tls-extended-key-update, | | (requires EKU-PSK extension) | | | | [11] {EKU Request} =========================> | | [12] {EKU Response} <========================= | | | | <===============================================> | | [13] Application Data | \ | + issued AR (ID_C, pubIK_C, pubKEM_C) | | | [14] Periodic re-Attestation health checks | [Attestation | | Result] | [e.g., I-D.fossati-seat-expat] | | | <===============================================> | / | | ]]>

The facts_attest_req Extension The facts_attest_req extension is carried in the CertificateRequest message. It signals that the server requires client attestation before it will release its own Evidence, and communicates the Evidence format requirements the client must satisfy. CA enrollment is one application of this signal; privacy-gated disclosure to unauthenticated clients is another.

Extension Structure ; } Extension; struct { FactsAttestRequestVersion version; FactsEvidenceFormat supported_formats<1..2^8-1>; opaque responder_identity<0..2^16-1>; /* responder's ID_S, for rdata binding */ opaque request_context<0..2^8-1>; /* opaque, echoed in client response */ } FactsAttestRequestParams; enum { facts_attest_req_v1(1), (255) } FactsAttestRequestVersion; enum { eat_cbor(1), /* EAT CBOR per RFC 9711 */ eat_json(2), /* EAT JSON */ cmw(3), /* RATS CMW per I-D.ietf-rats-msg-wrap */ csr_attestation(4),/* I-D.ietf-lamps-csr-attestation attribute format */ (255) } FactsEvidenceFormat; ]]> version identifies the facts_attest_req protocol version. Clients that do not recognize the version MUST abort with handshake_failure. supported_formats is an ordered list of Evidence formats the responder is willing to accept, in descending preference. The client MUST select the first format it supports. If no common format exists, the client MUST abort with handshake_failure. responder_identity carries the responder's ID_S value as it appears in its Identity Document. The client MUST verify this matches the ID_S bound in the pre-fetched Identity Document. This closes the identity confirmation loop: the responder explicitly asserts its identity inline rather than relying solely on the certificate chain. request_context is an opaque value chosen by the responder. The client MUST echo it verbatim in its response. It serves as a lightweight correlation handle and MAY encode responder-internal state such as a request identifier or policy selector. It MUST NOT be used as a freshness mechanism; freshness is provided by CN1 and CN2.

Server Behavior A server sending facts_attest_req in CertificateRequest:

1. MUST include facts_challenge in EncryptedExtensions. A facts_attest_req without a corresponding facts_challenge in EncryptedExtensions is a protocol error; the client MUST abort with missing_extension.
2. MUST deliver a valid X.509 certificate in its own Certificate message.
3. MUST omit facts_attestation from its own Certificate message. Server Evidence delivery is deferred to post-handshake Exported Authenticators once the client has been verified. See .

Client Behavior Upon receiving a CertificateRequest containing facts_attest_req, the client:

1. Verifies version is supported.
2. Selects an Evidence format from supported_formats.
3. Verifies responder_identity matches the pre-fetched Identity Document.
4. Derives psk_attest from CN1 and CN2 per .
5. Produces TEE Evidence bound to the session parameters, encrypts it under psk_attest, and delivers it in facts_attestation within its Certificate message per .

The enrollment-specific client steps (key pair generation, CRTEnroll construction, rdata binding), defined earlier in this section, are a specific application of this general mechanism. A client that is unable or unwilling to attest MUST send an empty Certificate message and MUST NOT send facts_attestation. The server MUST then abort with certificate_required.

Relationship to cert_req_context The standard TLS 1.3 CertificateRequest carries a certificate_request_context field that the client echoes in its Certificate message to prevent replay across connections. The request_context in facts_attest_req is distinct from and supplementary to this field. Both MUST be echoed. Implementations MUST NOT conflate them.

EAT/AR Claims as Identity Documents FACTS uses two identity documents to convey device identity and verifier appraisal: an Entity Attestation Token (EAT) produced by the attesting device, and an Attestation Result (AR) produced by the verifier. The EAT is signed by the device attestation key (privAK). The AR is signed by the verifier under a separate trust anchor. Both documents MAY be serialized in any format supported by the negotiated FactsEvidenceFormat; JWT serialization is one valid option. The claims and key binding structures defined in this section apply regardless of serialization format. The AR's cnf-based key binding follows the same proof-of-possession pattern established for OAuth token binding via mutual TLS and DPoP , extended with an attested_kem claim that provides a second, independent proof-of-possession channel through HPKE nonce encapsulation.

EAT Structure The EAT payload MUST include the following FACTS-specific claims: All other claims MUST conform to . eat_nonce carries the session binding commitment defined in . Its value MUST be the base64url-unpadded encoding of SHA-256(pubIK_S || CN1 || CN2 || pubKEM_C). Implementations MUST NOT place a verbatim verifier challenge in this field. How this value is conveyed to the underlying platform attestation primitive is defined in per-platform companion documents. The keys member is a JWKS array carrying exactly two JWK entries: " }, { "kty": "OKP", "crv": "X25519", "use": "enc", "kid": "pubKEM_S", "x": "" } ] ]]> The first entry carries pubIK_S with "use": "sig" and the second carries pubKEM_S with "use": "enc". Both MUST use the OKP key type per . The EAT presents these keys as part of the device's attested evidence; they are bound to the platform measurements by the TEE's signature over the complete EAT. Platform-specific EAT claims (ueid, oemid, hwmodel, hwversion, swname, swversion, secboot, dbgstat, and claims defined by the applicable attestation profile such as PSA IoT) MAY be included and are interpreted per the applicable platform profile.

AR Structure The AR is issued by the verifier during enrollment alongside the X.509 certificate. It enables the passport model for subsequent FACTS handshakes, permitting the device to present a cached attestation result without a live background-check round-trip to the verifier. The AR payload MUST include: The cnf claim MUST contain a jwk member carrying a single JWK entry with "use": "sig" carrying pubIK_S: " } } ]]> A relying party that receives an AR MUST verify that the cnf.jwk key matches the public key presented in the TLS Certificate message. This is the standard proof-of-possession confirmation: CertificateVerify proves the server holds the private key corresponding to the confirmed public key. The attested_kem claim carries the encapsulation key as a standalone JWK with "use": "enc": " } ]]> This key is the target for the client's HPKE-sealed challenge nonce (CN1) in the facts_challenge extension. Successful unsealing by the server constitutes proof-of-possession of the attested encapsulation key. Additional appraisal claims are implementation-specific and out of scope for this document.

Security Considerations

Idealized deployment topology assumptions

Infrastructure Topology

Threat Model FACTS is designed to mitigate compromise under adversarial conditions:

• The adversary is an active MitM: they can intercept, inject, modify, and replay protocol messages on the network.
• The distribution channel for AR is untrusted and may serve attacker-controlled content (such as DNS without DNSSEC).
• Various states of compromise are tested including combinations where privAK is compromised while privIK and privKEM are secured, or when privIK and privKEM are compromised but privAK holds.

ProVerif model (Work in Progress) A comprehensive ProVerif model, adapted from the open-source release of the formal analysis of has been extended to evaluate the security properties of FACTS over TLS 1.3 .

Key Separation The attacks demonstrated in arise from using a single key for both TLS authentication and attestation binding, enabling an adversary to relay evidence across sessions. FACTS separates these roles:

• The IK signs the TLS transcript (CertificateVerify) and the selfsign binding. Compromise of privIK enables TLS impersonation but does not yield a valid quote.
• The EK decapsulates challenge nonces and enables psk_attest derivation. Compromise of privKEM enables decryption of the quote but does not enable transcript forgery.
• The AK signs the TEE quote. Compromise requires breaching the hardware security boundary.

An adversary holding privKEM and privIK simultaneously can impersonate the TLS layer but cannot produce a quote with valid rdata for a session they did not participate in, because rdata binds (pubIK, CN1, CN2, pubKEM_C) and CN2 is sealed to the client's ephemeral pubKEM_C which the adversary does not control.

Compound Authentication The FACTS ProVerif model indicates compound injective-agreement between the Client and Server Pre-Finish ("Property G-C2") holds even when the private Attestation Key (AK) has been leaked. This suggests that the compound authentication property - both for the TLS session and the attestation evidence - refer to the same endpoint even under privAK compromise.

Pre-Handshake Identity Binding The Identity Document distributed via DNS closes the identity/key separation gap identified in . By binding pubKEM and pubIK to the server identity under a CA signature before the handshake begins, the client can verify that the keys used in the handshake correspond to the expected server identity. An adversary presenting keys not bound in a valid Identity Document will fail client verification.

Privacy Considerations

DNS Lookup Exposure Pre-fetching the Identity Document via DNS reveals the client's intent to connect to the target server to any observer with visibility into DNS traffic. This is equivalent to the exposure present in any DNS resolution prior to TLS establishment. Deployments with elevated privacy requirements SHOULD use encrypted DNS (DoH or DoT).

Evidence Disclosure The TEE quote is encrypted under psk_attest, which is derived from the challenge nonces exchanged between the two peers. The quote is therefore not visible to passive network observers. The client obtains the decrypted quote after step [9] and appraises it directly (background-check model per ) or forwards it to a Verifier. In the latter case, the Verifier learns the server's platform measurements and authentication timing.

Identity Document Opacity The Identity Document carries only public key values and standard JWT metadata. It does not contain platform measurements, hardware identifiers, or personally identifiable information. Distribution via DNS does not create a correlation surface beyond the server's domain name.

Conditional Evidence Disclosure observes that when the server acts as Attester, it can require client authentication before releasing Evidence, limiting exposure of hardware-level claims to authorized clients. This document adopts that principle within the handshake. In the standard FACTS flow, any client that completes the HPKE exchange obtains the server's decrypted TEE Evidence. The facts_attest_req extension () allows the server to withhold its own Evidence and require client attestation first. Server Evidence is subsequently delivered via Exported Authenticators post-handshake. Deployments where the server's platform measurements are sensitive SHOULD use facts_attest_req for connections from unauthenticated or untrusted clients. The decision to require client-first attestation is a server-local policy choice.

IANA Considerations

TLS ExtensionType Registry IANA is requested to register the following entries in the "TLS ExtensionType Values" registry :

Value	Extension Name	TLS 1.3	DTLS-Only	Recommended
TBD1	facts_hello	CH	N	Y
TBD2	facts_challenge	CH, EE	N	Y
TBD3	facts_attestation	CT	N	Y
TBD4	facts_attest_req	CR	N	Y

The facts_challenge extension is permitted in both ClientHello (CH) and EncryptedExtensions (EE). Its structure and HPKE mode differ per message as specified in . The presence of facts_challenge in EncryptedExtensions is conditional on its presence in the corresponding ClientHello, per . The facts_attestation extension is permitted only in the Certificate message (CT). It carries an encrypted CMW-wrapped Evidence payload and a self-signed key binding as specified in .

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. 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. 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. Independent 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, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. 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. 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. 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. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. 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 specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE). An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. 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 Diffie-Hellman exchange 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. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. 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 describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro 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 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 protocol extensions to the TLS 1.3 handshake that enables 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 mutually. 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. TU Dresden Linaro Nokia Intuit University of Applied Sciences Bonn-Rhein-Sieg 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. Cryptic Forest Software Siemens Fraunhofer SIT Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines an ASN.1 structure for remote attestation that can accommodate proprietary and standardized attestation mechanisms, as well as an attribute and an extension to carry the structure in PKCS#10 and Certificate Request Message Format (CRMF) messages, respectively.

Acknowledgments Thanks to Sardar et al. for the open-source release of the Identity Crisis model and for the detailed relay attack disclosures to the community. Thank you to the authors and contributors who have worked tirelessly on the foundational body of work for attested TLS, and for their insights on the IETF mailing lists that helped shape this approach. A special additional thanks to Usama Sardar for sharing valuable time for discussions.