SEAT T. Reddy Internet-Draft Nokia Intended status: Standards Track H. Tschofenig Expires: 25 December 2026 UniBw M. 23 June 2026 Application-Layer Transport for Exported Authenticators and Attestation draft-reddy-seat-expat-transport-00 Abstract This document defines a binary, application-layer transport protocol for exchanging Exported Authenticator messages between two peers over TLS. It provides the signaling required to initiate and complete post-handshake authentication exchanges at the application layer, without requiring modifications to the TLS layer itself. While primarily intended to support attestation exchange, the transport is generic and can be used independently for any Exported Authenticator exchange. The document further specifies how protocol messages are conveyed as Capsules over an HTTP connection established using the Extended CONNECT method, with support for both HTTP/2 and HTTP/3. In addition, it defines how the protocol can operate directly over TLS or DTLS 1.3 without an HTTP binding, using a so-called "Shim Mode". Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 December 2026. Reddy & Tschofenig Expires 25 December 2026 [Page 1] Internet-Draft ALTEA June 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Message Definitions . . . . . . . . . . . . . . . . . . . . . 6 3.1. AuthMessageType . . . . . . . . . . . . . . . . . . . . . 6 3.2. AuthCapabilities . . . . . . . . . . . . . . . . . . . . 7 3.3. AuthenticatorRequest . . . . . . . . . . . . . . . . . . 8 3.3.1. Request ID . . . . . . . . . . . . . . . . . . . . . 9 3.4. AuthenticatorResponse . . . . . . . . . . . . . . . . . . 9 3.5. AuthError . . . . . . . . . . . . . . . . . . . . . . . . 10 4. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 12 4.2. Connection Establishment . . . . . . . . . . . . . . . . 12 4.3. Capsule Framing . . . . . . . . . . . . . . . . . . . . . 12 4.4. Capsule Type to Message Mapping . . . . . . . . . . . . . 13 4.5. Bidirectionality . . . . . . . . . . . . . . . . . . . . 13 4.6. TLS Requirement . . . . . . . . . . . . . . . . . . . . . 13 4.7. Operation over HTTP/2 and HTTP/3 . . . . . . . . . . . . 14 4.8. Path Configuration . . . . . . . . . . . . . . . . . . . 14 5. Use with draft-fossati-seat-expat . . . . . . . . . . . . . . 14 6. DTLS 1.3 Considerations . . . . . . . . . . . . . . . . . . . 14 7. Direct TLS and DTLS Usage (Shim Mode) . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.1. Transport Security . . . . . . . . . . . . . . . . . . . 16 8.2. Capability Mismatch . . . . . . . . . . . . . . . . . . . 16 8.3. Capability Downgrade . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9.1. HTTP Upgrade Token Registration . . . . . . . . . . . . . 17 9.2. HTTP Capsule Types . . . . . . . . . . . . . . . . . . . 17 9.3. Well-Known URI Registration . . . . . . . . . . . . . . . 18 9.4. AuthMessageType Registry . . . . . . . . . . . . . . . . 18 9.5. AuthErrorCode Registry . . . . . . . . . . . . . . . . . 19 Reddy & Tschofenig Expires 25 December 2026 [Page 2] Internet-Draft ALTEA June 2026 9.6. Attestation Model Registry . . . . . . . . . . . . . . . 20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Normative References . . . . . . . . . . . . . . . . . . . . . 21 Informative References . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 23 Appendix B. Motivating Example: STET . . . . . . . . . . . . . . 23 Appendix C. Document History . . . . . . . . . . . . . . . . . . 23 C.1. draft-reddy-seat-expat-transport-00 . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction TLS Exported Authenticators [RFC9261] provide a mechanism for post- handshake authentication over an established TLS 1.3 connection. Either peer may request an Exported Authenticator from the other after the TLS handshake has completed. However, [RFC9261] defines only the authenticator mechanism itself; it does not define how authenticator requests, responses, or errors are signaled between peers. Each application protocol is therefore responsible for defining its own transport and signaling mechanism. [I-D.fossati-seat-expat] extends Exported Authenticators to carry attestation Evidence and Attestation Results, enabling attestation to be performed after the TLS handshake. As with [RFC9261], it defines the semantics and content of the messages, but not the application- layer transport used to carry them. This document defines such a transport. It specifies a binary application-layer protocol for exchanging Exported Authenticator messages between two peers over an established TLS connection. The protocol is generic: although it is primarily motivated by attestation exchange, it can be used for any Exported Authenticator exchange. The specification defines: * Binary message structures, using the presentation language of [RFC8446], for carrying Exported Authenticator requests, responses, and errors. * A capability negotiation mechanism that allows peers to determine the supported attestation message patterns and Conceptual Message Wrapper (CMW) encoding formats before exchanging Exported Authenticator messages. Reddy & Tschofenig Expires 25 December 2026 [Page 3] Internet-Draft ALTEA June 2026 * An HTTP binding in which protocol messages are carried as Capsules [RFC9297] over an HTTP connection established using the Extended CONNECT method [RFC8441] [RFC9220]. * A direct TLS and DTLS 1.3 binding, referred to as Shim Mode, for use cases where the protocol is run directly over the secure transport without an HTTP binding. In the HTTP binding, the client sends an Extended CONNECT request using the upgrade token "exported-authenticator". Once the connection has been established, both peers exchange protocol messages as Capsules on the resulting HTTP stream. This design supports both HTTP/2 and HTTP/3 and allows the Exported Authenticator exchange to be multiplexed with other application traffic. The protocol supports re-attestation on an HTTPS connection. Either peer may request a fresh Exported Authenticator at any time. However, re-attestation is not supported in Shim Mode. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. * "TLS" refers to TLS 1.3 and DTLS 1.3 unless otherwise specified. References to TLS connections, exporters, and Exported Authenticators apply equally to DTLS as defined in [RFC9261]. In the context of Shim Mode (Section 7), "TLS" also encompasses DTLS. * The term "terminate the connection" refers to closing the underlying secure transport connection carrying this protocol. 2. Protocol Overview The client initiates the protocol using one of the two bindings defined in this document: * In the TLS binding (Section 7), the client establishes a TLS connection with the server. The attestation exchange begins immediately after the TLS handshake completes, with no additional connection setup step. Reddy & Tschofenig Expires 25 December 2026 [Page 4] Internet-Draft ALTEA June 2026 * In the HTTP binding (Section 4), the client sends an Extended CONNECT request with the HTTP upgrade token "exported- authenticator" and the Capsule-Protocol header field set to true. The server signals acceptance with a 2xx response that also includes the Capsule-Protocol header field. If attestation features are used, once the connection is established, the server sends an auth_capabilities (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) message advertising its supported attestation models and CMW types. The client replies with an auth_capabilities message containing its selected attestation model and CMW type chosen from the server's advertised list. If no common attestation model or CMW type exists, the client sends an auth_error (EXPAT_AUTH_ERROR Capsule in the HTTP binding) message and terminates the connection. Once capabilities are exchanged successfully, either peer may act as Initiator and send an auth_request (EXPAT_AUTH_REQUEST Capsule in the HTTP binding) message at any time. The other peer (the Responder) replies with either an authenticator (EXPAT_AUTHENTICATOR Capsule in the HTTP binding) message or an auth_error (EXPAT_AUTH_ERROR Capsule in the HTTP binding) message. Server Client | | | [TLS binding] | |<===TLS Handshake======================>| | | | [if attestation features are used] | | | +----auth_capabilities------------------>| |<---auth_capabilities-------------------+ | | | [either peer may now initiate] | | | |<---auth_request(id=1) -----------------+ +----authenticator(id=1) --------------->| | | +----auth_request(id=0x8001) ----------->| |<---authenticator(id=0x8001) -----------+ Figure 1: Protocol overview: TLS binding (Shim Mode) Reddy & Tschofenig Expires 25 December 2026 [Page 5] Internet-Draft ALTEA June 2026 Server Client | | | [HTTP binding] | |<---Extended CONNECT (upgrade token)----+ +----200 OK (Capsule-Protocol: ?1)------>| | | | [if attestation features are used] | | | +----EXPAT_AUTH_CAPABILITIES Capsule---->| |<---EXPAT_AUTH_CAPABILITIES Capsule-----+ | | | [either peer may now initiate] | | | |<---EXPAT_AUTH_REQUEST(id=1) -----------+ +----EXPAT_AUTHENTICATOR(id=1) --------->| | | +----EXPAT_AUTH_REQUEST(id=0x8001) ----->| |<---EXPAT_AUTHENTICATOR(id=0x8001) -----+ Figure 2: Protocol overview: HTTP binding 3. Message Definitions All structures use the presentation language of TLS 1.3 [RFC8446]. All multi-byte integers are in network byte order. A peer MUST NOT have more than one outstanding AuthenticatorRequest in each direction at any time. A peer awaiting a response MUST be prepared to receive and process an AuthenticatorRequest from the other peer. A peer MUST treat any message that does not conform to the sequencing and matching rules defined in this document, or that does not match an outstanding request where required, as a protocol_error. 3.1. AuthMessageType enum { auth_request(1), authenticator(2), auth_error(3), auth_capabilities(4), (255) } AuthMessageType; Reddy & Tschofenig Expires 25 December 2026 [Page 6] Internet-Draft ALTEA June 2026 Values 5-254 are unassigned and available for future assignment via the IANA registry defined in Section 9.4. The AuthMessageType enum applies to the Shim Mode framing (Section 7) and DTLS binding (Section 6); in the HTTP binding, message type discrimination is performed by the Capsule Type field instead (see Section 9.2). 3.2. AuthCapabilities enum { background_check(1), passport(2), (255) } AttestationModel; opaque cmw_type<1..255>; struct { AuthMessageType msg_type; /* auth_capabilities(4) */ AttestationModel models<1..255>; /* RATS models */ cmw_type cmw_types<1..2^16-1>; /* CMW media types */ } AuthCapabilities; If attestation-related features defined in [I-D.fossati-seat-expat] are to be used, the server MUST send an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) immediately after accepting the Extended CONNECT request (i.e., after sending the 2xx response) in the HTTP binding, or immediately after the TLS handshake completes in Shim Mode, before any other message. The client MUST reply with its own AuthCapabilities message before sending any other message. Whether attestation features are used on a given connection is determined by the TLS-layer negotiation defined in [I-D.fossati-seat-expat], specifically via the TLS flag registered in that document. A server MUST NOT send an AuthCapabilities message on a connection where that TLS flag was not negotiated during the TLS handshake. Both fields MUST be non-empty. A peer that receives an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) with an empty models or cmw_types field MUST send an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with error_code protocol_error(1) and terminate the connection. The cmw_types field contains a vector of UTF-8 media type strings (e.g., "application/cmw+cbor"), each individually length-prefixed as defined by the cmw_type type above. Reddy & Tschofenig Expires 25 December 2026 [Page 7] Internet-Draft ALTEA June 2026 The AuthCapabilities message sent by the client conveys the selected attestation model and CMW type for the connection. The client MUST select a single attestation model and a single CMW type from the server's advertised lists and include only the selected values in its AuthCapabilities message. If the client does not support any attestation model or CMW type advertised by the server, it MUST send an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with error_code protocol_error(1) and terminate the connection. If the client selects an attestation model or CMW type that was not advertised by the server, the server MUST send an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with error_code protocol_error(1) and terminate the connection. A peer that sends an AuthCapabilities message and does not receive a corresponding response MUST treat this as a protocol_error and terminate the connection. This rule applies to the HTTP binding and Shim Mode over TLS 1.3; the analogous behaviour for Shim Mode over DTLS 1.3 is described in Section 6. If the AuthCapabilities exchange is omitted, peers MUST NOT use attestation-related features defined in [I-D.fossati-seat-expat]. A peer that receives an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) outside of the initial capability exchange MUST treat it as a protocol_error. A client that requires attestation and does not receive an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) as the first message from the server MUST send an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with error_code protocol_error(1) and terminate the connection. When determining whether an AuthCapabilities message was received as the first message, unknown Capsule Types that are silently ignored per [RFC9297] MUST NOT be counted. 3.3. AuthenticatorRequest struct { AuthMessageType msg_type; /* auth_request(1) */ uint16 request_id; /* request identifier */ opaque authenticator_request<1..2^24-1>; /* certificate request */ } AuthenticatorRequest; Reddy & Tschofenig Expires 25 December 2026 [Page 8] Internet-Draft ALTEA June 2026 The authenticator_request field contains a CertificateRequest or ClientCertificateRequest message encoded as a TLS handshake message, as defined in [RFC9261]. The request_id is used to correlate protocol messages, while the certificate_request_context contained within authenticator_request is used by [RFC9261] for binding the resulting Authenticator. 3.3.1. Request ID The request_id namespace is split on the high bit to avoid collision when both peers initiate requests concurrently: * Client-initiated requests: 0x0001 to 0x7FFF * Server-initiated requests: 0x8001 to 0xFFFF * 0x0000 and 0x8000 are reserved for use in AuthError messages (EXPAT_AUTH_ERROR Capsules in the HTTP binding) when no specific request is implicated. A Client MUST use 0x0000 and a Server MUST use 0x8000 for these messages. Any AuthError message received during the AuthCapabilities exchange MUST use these reserved values. A receiver that receives an AuthError message with a reserved request_id that does not correspond to the sender's role (i.e., 0x0000 from the server or 0x8000 from the client) MUST treat it as a protocol_error and terminate the connection. The Initiator MUST NOT reuse a request_id that is currently pending, except when retransmitting a request over DTLS 1.3 as described in Section 6. When the maximum value in its range is reached, the Initiator wraps around within its assigned range and MUST select the next request_id that is not currently in use by a pending request. 3.4. AuthenticatorResponse struct { AuthMessageType msg_type; /* authenticator(2) */ uint16 request_id; opaque authenticator_blob<1..2^24-1>; /* RFC 9261 */ /* Authenticator */ } AuthenticatorResponse; The request_id MUST match the corresponding AuthenticatorRequest. Reddy & Tschofenig Expires 25 December 2026 [Page 9] Internet-Draft ALTEA June 2026 The authenticator_blob contains the Authenticator structure. When used with [I-D.fossati-seat-expat], the Certificate message within the Authenticator carries the cmw_attestation extension. A receiver that receives an AuthenticatorResponse message (EXPAT_AUTHENTICATOR Capsule in the HTTP binding) when no request is outstanding, or with a request_id that does not match any outstanding request, MUST treat it as a protocol_error. A receiver that receives more than one AuthenticatorResponse message (EXPAT_AUTHENTICATOR Capsule in the HTTP binding) for the same request_id MUST treat it as a protocol_error. The Initiator MUST verify the Authenticator as specified in [RFC9261] and abort the request if verification fails. 3.5. AuthError enum { protocol_error(1), authenticator_failed(2), request_id_conflict(3), internal_error(4), attestation_service_unavailable(5), attestation_validation_failed(6), attestation_policy_violation(7), (255) } AuthErrorCode; struct { AuthMessageType msg_type; /* auth_error(3) */ uint16 request_id; /* 0x0000 (client) or 0x8000 (server) */ /* if no request is implicated */ AuthErrorCode error_code; } AuthError; AuthError messages (EXPAT_AUTH_ERROR Capsules in the HTTP binding) are bidirectional: either peer may send one at any time. Error code semantics: protocol_error(1): A message was malformed, received out of sequence, or violated a requirement of this specification (including capability mismatch at session setup). authenticator_failed(2): Reddy & Tschofenig Expires 25 December 2026 [Page 10] Internet-Draft ALTEA June 2026 The sender was unable to produce a valid Authenticator because the required attestation Evidence could not be collected. request_id_conflict(3): The received request_id is already in use for an outstanding request (e.g., due to protocol violation or peer misbehavior). internal_error(4): An unrecoverable internal error occurred that prevents further processing of the protocol. attestation_service_unavailable(5): The attestation service (TEE or Verifier) is unreachable or timed out. attestation_validation_failed(6): A cryptographic check on the received Authenticator failed (e.g., signature invalid or Attestation Binder mismatch). attestation_policy_violation(7): The Authenticator is cryptographically valid but does not satisfy the Relying Party's attestation policy. Upon sending or receiving an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with any error_code other than attestation_service_unavailable(5), the peer MUST terminate the connection immediately. If the error_code is attestation_service_unavailable(5), the connection MAY remain open as the failure is transient. The initiator MUST retry with a new AuthenticatorRequest message (EXPAT_AUTH_REQUEST Capsule in the HTTP binding) using a new request_id. The initiator MUST apply an exponential backoff strategy between retries to avoid overwhelming the attestation service. A receiver that receives an AuthError message (EXPAT_AUTH_ERROR Capsule in the HTTP binding) with a request_id that does not correspond to any outstanding request and is not a reserved value (0x0000 or 0x8000) MUST terminate the connection immediately. Any AuthError message sent with a reserved request_id (0x0000 or 0x8000) MUST be treated as a session-level error and results in immediate termination. Reddy & Tschofenig Expires 25 December 2026 [Page 11] Internet-Draft ALTEA June 2026 4. HTTP Binding 4.1. HTTP Upgrade Token The HTTP upgrade token defined by this document is: exported-authenticator This token is registered in the "HTTP Upgrade Token Registry" as defined in Section 9.1. 4.2. Connection Establishment The client initiates the protocol by sending an Extended CONNECT request [RFC8441][RFC9220] with the following pseudo-header fields and header fields: :method = CONNECT :protocol = exported-authenticator :scheme = https :path = :authority = Capsule-Protocol: ?1 The server MUST respond with a 2xx (successful) response that also includes: Capsule-Protocol: ?1 If the server does not support the "exported-authenticator" upgrade token, it MUST respond with a 4xx or 5xx response. The client MUST treat any non-2xx response as a failure and MUST NOT send any Capsules on the stream. Once a 2xx response has been received, both client and server switch to the Capsule Protocol [RFC9297] on the HTTP stream. All subsequent bytes on that stream are Capsules as defined in Section 3.2 of [RFC9297]. 4.3. Capsule Framing Each protocol message defined in Section 3 MUST be sent as exactly one Capsule. The Capsule Type field identifies the message type as specified in Section 9.2. The Capsule Value field contains the body of the message: all fields of the relevant struct from Section 3, excluding the msg_type field, which is replaced by the Capsule Type. Reddy & Tschofenig Expires 25 December 2026 [Page 12] Internet-Draft ALTEA June 2026 Unknown Capsule Types MUST be silently ignored per Section 3.2 of [RFC9297]. This provides forward compatibility: future extensions MAY define new Capsule Types without requiring version negotiation. 4.4. Capsule Type to Message Mapping The following table maps Capsule Type names to the protocol messages defined in Section 3: +=========================+=======================+ | Capsule Type Name | Protocol Message | +=========================+=======================+ | EXPAT_AUTH_REQUEST | AuthenticatorRequest | +-------------------------+-----------------------+ | EXPAT_AUTHENTICATOR | AuthenticatorResponse | +-------------------------+-----------------------+ | EXPAT_AUTH_ERROR | AuthError | +-------------------------+-----------------------+ | EXPAT_AUTH_CAPABILITIES | AuthCapabilities | +-------------------------+-----------------------+ Table 1 Capsule Type values are assigned in the IANA registry defined in Section 9.2. 4.5. Bidirectionality After the connection is established, both client and server MAY send any Capsule Type at any time, subject to the sequencing and request_id rules in Section 3. Either peer MAY initiate an EXPAT_AUTH_REQUEST Capsule, consistent with the request_id namespace split defined in Section 3. 4.6. TLS Requirement This protocol MUST be used only over TLS 1.3 or later versions. When operating over HTTP/3, TLS 1.3 is used internally by QUIC as specified in [RFC9001], satisfying this requirement. DTLS is not applicable to the HTTP transport; DTLS 1.3 is supported only for the Shim Mode defined in this document. Reddy & Tschofenig Expires 25 December 2026 [Page 13] Internet-Draft ALTEA June 2026 4.7. Operation over HTTP/2 and HTTP/3 When operating over HTTP/2 [RFC9113] or HTTP/3 [RFC9114], the Extended CONNECT mechanism is used as defined in [RFC8441] and [RFC9220], respectively. In both cases, the server MUST advertise the SETTINGS_ENABLE_CONNECT_PROTOCOL setting with value 1 before the client MAY send an Extended CONNECT request with the "exported- authenticator" upgrade token. 4.8. Path Configuration The path is carried in the :path pseudo-header field of the Extended CONNECT request. This document registers the well-known URI suffix "expat" (see Section 9.3), yielding the default path /.well-known/ expat/. 5. Use with draft-fossati-seat-expat When used with [I-D.fossati-seat-expat]: * An auth_capabilities (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) message MUST advertise at least one AttestationModel and one CMW media type (e.g., "application/cmw+cbor" or "application/ cmw+json"). * The authenticator_blob in an authenticator (EXPAT_AUTHENTICATOR Capsule in the HTTP binding) message contains an Authenticator whose Certificate message carries the cmw_attestation extension with Evidence (background-check model) or an Attestation Result (passport model). * The Initiator applies the Authenticator validation procedure defined in [I-D.fossati-seat-expat] to the received Authenticator. For re-attestation on long-lived connections, either peer MAY send a new auth_request (EXPAT_AUTH_REQUEST Capsule in the HTTP binding) message at any time. Re-attestation is not supported in Shim Mode; implementations requiring re-attestation MUST use the HTTP binding. 6. DTLS 1.3 Considerations When this protocol is used in Shim Mode over DTLS 1.3 [RFC9147], message loss and reordering may occur. In such environments, retransmission of messages may be required. The Capsule Protocol and the HTTP binding are not used over DTLS; all references in this section are to the Shim Mode framing defined in Section 7. Reddy & Tschofenig Expires 25 December 2026 [Page 14] Internet-Draft ALTEA June 2026 If a peer does not receive a response to an AuthCapabilities message, it MUST retransmit using the same exponential backoff and timeout mechanism as the DTLS handshake retransmission defined in [RFC9147]. If no response is received after the retransmission timeout expires, the peer MUST treat it as a protocol_error and terminate the connection. If a peer does not receive a response (AuthenticatorResponse or AuthError) for an outstanding AuthenticatorRequest within an implementation-defined timeout, it MAY retransmit the request. A retransmitted AuthenticatorRequest MUST use the same request_id and authenticator_request value as the original. A receiver that receives a duplicate AuthenticatorRequest with the same request_id and identical authenticator_request value MUST treat it as a retransmission and MAY resend the corresponding AuthenticatorResponse. A receiver that receives duplicate AuthenticatorResponse messages for the same request_id and identical authenticator_blob MUST treat them as retransmissions and ignore duplicates. A receiver MUST ensure that retransmission does not result in multiple distinct cryptographic operations for the same request_id. To achieve this, the receiver SHOULD cache the generated AuthenticatorResponse for a period sufficient to handle potential retransmissions. If a duplicate AuthenticatorRequest is received, the cached AuthenticatorResponse SHOULD be returned. Fatal AuthError messages require best-effort coordinated termination. A peer that receives a fatal AuthError MUST stop sending application data and SHOULD send a close_notify alert. The sender of a fatal AuthError MAY retransmit the error if it continues to receive any records from the peer. If no records are received for a period exceeding the retransmission timeout, the sender SHOULD assume the peer has terminated and terminate the connection locally. 7. Direct TLS and DTLS Usage (Shim Mode) Shim Mode is intended for short-lived TLS connections where attestation exchange is performed immediately after the TLS handshake is complete. Re-attestation on long-lived connections is not supported in this mode; implementations requiring re-attestation MUST use the HTTP binding instead. Reddy & Tschofenig Expires 25 December 2026 [Page 15] Internet-Draft ALTEA June 2026 This protocol MAY be used directly over a TLS 1.3 connection without the HTTP binding defined in this document. In this mode, the messages defined in Section 3 are exchanged immediately after the TLS handshake completes and before any application data is sent. Each message MUST be framed as an AuthFrame. A receiver MUST verify the magic field is equal to 0x414C5441. If the first 4 bytes of a message in Shim Mode do not match 0x414C5441, the receiver MUST terminate the connection immediately. This prevents the misinterpretation of application-layer data (e.g., HTTP methods) as large ALTEA frame lengths. As per [RFC8446] Section 3.4, the body field is encoded with a 4-byte length prefix in network byte order. Receivers MUST use this length to delimit message boundaries and parse msg_type from the first byte of the body. struct { uint32 magic; /* Constant: 0x414C5441 ("ALTA") */ opaque body<1..2^32-1>; } AuthFrame; Note: The magic value 0x414C5441 is the ASCII encoding of "ALTA" and serves solely as a framing guard against misinterpretation of application-layer data. Peers MUST complete the protocol exchange before sending application protocol messages (e.g., HTTP request/response). Messages defined in this document MUST NOT be interleaved with application data. After the protocol exchange is complete, all subsequent data on the connection is interpreted as application protocol data. 8. Security Considerations 8.1. Transport Security Although [RFC9261] supports both TLS 1.2 and TLS 1.3, this protocol restricts use to TLS 1.3 as TLS 1.2 is deprecated. When attestation features defined in [I-D.fossati-seat-expat] are used, TLS 1.3 is further required because the attestation binding depends on the TLS exporter defined in TLS 1.3. When operating over HTTP/3, TLS 1.3 is provided by QUIC [RFC9001]. 8.2. Capability Mismatch Capability mismatch at session setup is treated as a fatal error. This prevents silent downgrade to unauthenticated operation. Reddy & Tschofenig Expires 25 December 2026 [Page 16] Internet-Draft ALTEA June 2026 8.3. Capability Downgrade Implementations that require attestation MUST ensure that the AuthCapabilities exchange is performed. Failure to receive or process an AuthCapabilities message (EXPAT_AUTH_CAPABILITIES Capsule in the HTTP binding) when attestation is expected MUST be treated as a protocol_error to prevent downgrade attacks. 9. IANA Considerations 9.1. HTTP Upgrade Token Registration IANA is requested to register the following entry in the "HTTP Upgrade Token Registry" defined in Section 16.7 of [RFC9110]: Value: exported-authenticator Description: Exported Authenticator Transport Expected Version Tokens: None Reference: This document 9.2. HTTP Capsule Types IANA is requested to register the following entries in the "HTTP Capsule Types" registry defined in Section 5.4 of [RFC9297]. Registration policy: Specification Required. +=======+=========================+===============+ | Value | Capsule Type Name | Reference | +=======+=========================+===============+ | TBD1 | EXPAT_AUTH_REQUEST | This document | +-------+-------------------------+---------------+ | TBD2 | EXPAT_AUTHENTICATOR | This document | +-------+-------------------------+---------------+ | TBD3 | EXPAT_AUTH_ERROR | This document | +-------+-------------------------+---------------+ | TBD4 | EXPAT_AUTH_CAPABILITIES | This document | +-------+-------------------------+---------------+ Table 2 Reddy & Tschofenig Expires 25 December 2026 [Page 17] Internet-Draft ALTEA June 2026 9.3. Well-Known URI Registration IANA is requested to register the following Well-Known URI in the "Well-Known URIs" registry defined in [RFC8615]: URI Suffix: expat Change Controller: IETF Specification Document: This document Related Information: For use with the "exported-authenticator" HTTP upgrade token. 9.4. AuthMessageType Registry IANA is requested to create a new registry "Transport Message Types" under a new "Exported Authenticator Transport" registry group. This registry maps conceptual message type names to their struct definitions, for use in the Shim Mode framing (Section 7) and DTLS binding (Section 6). In the HTTP binding, message type discrimination is performed by the Capsule Type field; see Section 9.2. Registration policy: Specification Required for values 5-254. Reddy & Tschofenig Expires 25 December 2026 [Page 18] Internet-Draft ALTEA June 2026 +=======+===================+===============+ | Value | Name | Reference | +=======+===================+===============+ | 0 | Reserved | This document | +-------+-------------------+---------------+ | 1 | auth_request | This document | +-------+-------------------+---------------+ | 2 | authenticator | This document | +-------+-------------------+---------------+ | 3 | auth_error | This document | +-------+-------------------+---------------+ | 4 | auth_capabilities | This document | +-------+-------------------+---------------+ | 5-254 | Unassigned | | +-------+-------------------+---------------+ | 255 | Reserved | This document | +-------+-------------------+---------------+ Table 3 9.5. AuthErrorCode Registry IANA is requested to create a new registry "Error Codes" under the same registry group. Registration policy: Specification Required for values 8-191; Private Use for 192-254. Reddy & Tschofenig Expires 25 December 2026 [Page 19] Internet-Draft ALTEA June 2026 +=========+=====================================+===============+ | Value | Name | Reference | +=========+=====================================+===============+ | 0 | Reserved | This document | +---------+-------------------------------------+---------------+ | 1 | protocol_error | This document | +---------+-------------------------------------+---------------+ | 2 | authenticator_failed | This document | +---------+-------------------------------------+---------------+ | 3 | request_id_conflict | This document | +---------+-------------------------------------+---------------+ | 4 | internal_error | This document | +---------+-------------------------------------+---------------+ | 5 | attestation_service_unavailable | This document | +---------+-------------------------------------+---------------+ | 6 | attestation_validation_failed | This document | +---------+-------------------------------------+---------------+ | 7 | attestation_policy_violation | This document | +---------+-------------------------------------+---------------+ | 8-191 | Unassigned (Specification Required) | | +---------+-------------------------------------+---------------+ | 192-254 | Private Use | | +---------+-------------------------------------+---------------+ | 255 | Reserved | This document | +---------+-------------------------------------+---------------+ Table 4 9.6. Attestation Model Registry IANA is requested to create a new registry "Attestation Models" under the same registry group. Registration policy: Specification Required for values 3-254. Reddy & Tschofenig Expires 25 December 2026 [Page 20] Internet-Draft ALTEA June 2026 +=======+=====================================+===============+ | Value | Name | Reference | +=======+=====================================+===============+ | 0 | Reserved | This document | +-------+-------------------------------------+---------------+ | 1 | background_check | This document | +-------+-------------------------------------+---------------+ | 2 | passport | This document | +-------+-------------------------------------+---------------+ | 3-254 | Unassigned (Specification Required) | | +-------+-------------------------------------+---------------+ | 255 | Reserved | This document | +-------+-------------------------------------+---------------+ Table 5 Acknowledgements Thanks to Ionut Mihalcea and Thomas Fossati for the comments. References Normative References [I-D.fossati-seat-expat] Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y., Tschofenig, H., and I. Mihalcea, "Remote Attestation with Exported Authenticators", Work in Progress, Internet- Draft, draft-fossati-seat-expat-02, 26 February 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", RFC 8441, DOI 10.17487/RFC8441, September 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Reddy & Tschofenig Expires 25 December 2026 [Page 21] Internet-Draft ALTEA June 2026 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . [RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3", RFC 9220, DOI 10.17487/RFC9220, June 2022, . [RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261, DOI 10.17487/RFC9261, July 2022, . [RFC9297] Schinazi, D. and L. Pardue, "HTTP Datagrams and the Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August 2022, . Informative References [I-D.draft-ietf-httpbis-secondary-server-certs] Gorbaty, E. and M. Bishop, "Secondary Certificate Authentication of HTTP Servers", Work in Progress, Internet-Draft, draft-ietf-httpbis-secondary-server-certs- 02, 17 June 2026, . [STET] Google LLC, "STET: Split-Trust Encryption Tool", n.d., . Reddy & Tschofenig Expires 25 December 2026 [Page 22] Internet-Draft ALTEA June 2026 Appendix A. Design Rationale [I-D.draft-ietf-httpbis-secondary-server-certs] defines a mechanism for HTTP/2 and HTTP/3 servers to present additional certificate-based credentials after TLS connection establishment using TLS Exported Authenticators [RFC9261]. However, it has several limitations that prevent its use for mutual post-handshake attestation. The protocol is strictly unidirectional: the client is explicitly prohibited from sending certificate frames, and there is no mechanism for the server to challenge the client to present a certificate. Once a CERTIFICATE frame is received and validated, it is cached for the lifetime of the connection with no mechanism to request re-authentication, making re- attestation impossible. For these reasons, this document does not use the mechanism defined in [I-D.draft-ietf-httpbis-secondary-server-certs]. Appendix B. Motivating Example: STET The Split-Trust Encryption Tool (STET) [STET] requires attestation as a precondition for key release from a KMS, and implements this using a four-message gRPC protocol (BeginSession, Handshake, NegotiateAttestation, Finalize) with attestation evidence bound to the TLS session via Exported Keying Material. The result is an application-specific implementation that does not support re- attestation on an established TLS connection or server attestation. Appendix C. Document History C.1. draft-reddy-seat-expat-transport-00 Initial version. Authors' Addresses Tirumaleswar Reddy Nokia Bangalore Karnataka India Email: k.tirumaleswar_reddy@nokia.com Hannes Tschofenig University of the Bundeswehr Munich Neubiberg Germany Email: hannes.tschofenig@gmx.net Reddy & Tschofenig Expires 25 December 2026 [Page 23]