]> Nokia

Bangalore Karnataka India k.tirumaleswar_reddy@nokia.com

University of the Bundeswehr Munich

Neubiberg Bavaria Germany hannes.tschofenig@gmx.net

Security SEAT Internet-Draft 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".

Introduction TLS Exported Authenticators 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, 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. extends Exported Authenticators to carry attestation Evidence and Attestation Results, enabling attestation to be performed after the TLS handshake. As with , 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 , 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.
• An HTTP binding in which protocol messages are carried as Capsules over an HTTP connection established using the Extended CONNECT method .
• 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.

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 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 . In the context of Shim Mode (), "TLS" also encompasses DTLS.
• The term "terminate the connection" refers to closing the underlying secure transport connection carrying this protocol.

Protocol Overview The client initiates the protocol using one of the two bindings defined in this document:

• In the TLS binding (), 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.
• In the HTTP binding (), 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.

Protocol overview: TLS binding (Shim Mode) | | | | [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) -----------+ ]]>

Protocol overview: HTTP binding | | | | [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) -----+ ]]>

Message Definitions All structures use the presentation language of TLS 1.3 . 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.

AuthMessageType Values 5-254 are unassigned and available for future assignment via the IANA registry defined in . The AuthMessageType enum applies to the Shim Mode framing () and DTLS binding (); in the HTTP binding, message type discrimination is performed by the Capsule Type field instead (see ).

AuthCapabilities ; 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 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. 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. 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 . If the AuthCapabilities exchange is omitted, peers MUST NOT use attestation-related features defined in . 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 MUST NOT be counted.

AuthenticatorRequest ; /* certificate request */ } AuthenticatorRequest; ]]> The authenticator_request field contains a CertificateRequest or ClientCertificateRequest message encoded as a TLS handshake message, as defined in . The request_id is used to correlate protocol messages, while the certificate_request_context contained within authenticator_request is used by for binding the resulting Authenticator.

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 . 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.

AuthenticatorResponse ; /* RFC 9261 */ /* Authenticator */ } AuthenticatorResponse; ]]> The request_id MUST match the corresponding AuthenticatorRequest. The authenticator_blob contains the Authenticator structure. When used with , 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 and abort the request if verification fails. An Initiator that does not receive a response (AuthenticatorResponse or AuthError) to an outstanding AuthenticatorRequest within an implementation-defined timeout MAY terminate the connection. This applies to the HTTP binding and to Shim Mode over TLS 1.3; the retransmission-based behaviour for Shim Mode over DTLS 1.3 is described in .

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):

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.

HTTP Binding

HTTP Upgrade Token The HTTP upgrade token defined by this document is: This token is registered in the "HTTP Upgrade Token Registry" as defined in .

Connection Establishment The client initiates the protocol by sending an Extended CONNECT request with the following pseudo-header fields and header fields: :authority = Capsule-Protocol: ?1 ]]> The server MUST respond with a 2xx (successful) response that also includes: 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 on the HTTP stream. All subsequent bytes on that stream are Capsules as defined in Section 3.2 of .

Capsule Framing Each protocol message defined in MUST be sent as exactly one Capsule. The Capsule Type field identifies the message type as specified in . The Capsule Value field contains the body of the message: all fields of the relevant struct from , excluding the msg_type field, which is replaced by the Capsule Type. Unknown Capsule Types MUST be silently ignored per Section 3.2 of . This provides forward compatibility: future extensions MAY define new Capsule Types without requiring version negotiation.

Capsule Type to Message Mapping The following table maps Capsule Type names to the protocol messages defined in :

Capsule Type Name	Protocol Message
EXPAT_AUTH_REQUEST	AuthenticatorRequest
EXPAT_AUTHENTICATOR	AuthenticatorResponse
EXPAT_AUTH_ERROR	AuthError
EXPAT_AUTH_CAPABILITIES	AuthCapabilities

Capsule Type values are assigned in the IANA registry defined in .

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 . Either peer MAY initiate an EXPAT_AUTH_REQUEST Capsule, consistent with the request_id namespace split defined in .

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 , 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.

Operation over HTTP/2 and HTTP/3 When operating over HTTP/2 or HTTP/3 , the Extended CONNECT mechanism is used as defined in and , 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.

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 ), yielding the default path /.well-known/expat/.

Use with draft-fossati-seat-expat When used with :

• 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 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. The Exported Authenticator exchange, including any re-attestation, is carried on its own Extended CONNECT stream and does not block other HTTP streams on the same connection. Whether a given application message must wait for a fresh, validated AuthenticatorResponse before proceeding is an application (Relying Party) policy decision and is out of scope for this transport; messages that do not depend on fresh attestation MAY proceed in parallel with an in-progress exchange.

DTLS 1.3 Considerations When this protocol is used in Shim Mode over DTLS 1.3 , 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 . 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 . 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.

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. 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 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 0xE5A7A19C. If the first 4 bytes of a message in Shim Mode do not match 0xE5A7A19C, the receiver MUST terminate the connection immediately. The leading byte of the magic (0xE5) is deliberately outside the ASCII range, so it cannot be mistaken for the first byte of an ASCII application-protocol token (e.g., an HTTP method). As per 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. ; } AuthFrame; ]]> Note: The magic value 0xE5A7A19C is an opaque 32-bit constant chosen so that its leading byte lies outside the ASCII range. It serves solely as a framing guard against misinterpretation of application-layer data. This follows the approach used by the STUN magic cookie , which distinguishes STUN from other protocols multiplexed on the same transport. 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.

ALPN Considerations An application protocol running over Shim Mode MAY register a dedicated ALPN identifier for that specific binding (e.g., "coap-altea" for CoAP over Shim Mode). The application protocol specification is responsible for determining whether explicit ALPN signaling is needed and for defining the corresponding registration.

Security Considerations

Transport Security Although 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 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 .

Capability Mismatch Capability mismatch at session setup is treated as a fatal error. This prevents silent downgrade to unauthenticated operation.

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.

IANA Considerations

HTTP Upgrade Token Registration IANA is requested to register the following entry in the "HTTP Upgrade Token Registry" defined in Section 16.7 of :

Value:

exported-authenticator

Description:

Exported Authenticator Transport

Expected Version Tokens:

None

Reference:

This document

HTTP Capsule Types IANA is requested to register the following entries in the "HTTP Capsule Types" registry defined in Section 5.4 of . 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

Well-Known URI Registration IANA is requested to register the following Well-Known URI in the "Well-Known URIs" registry defined in :

URI Suffix:

expat

Change Controller:

IETF

Specification Document:

This document

Related Information:

For use with the "exported-authenticator" HTTP upgrade token.

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 () and DTLS binding (). In the HTTP binding, message type discrimination is performed by the Capsule Type field; see . Registration policy: Specification Required for values 5-254.

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

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.

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

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.

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

Acknowledgements Thanks to Ionut Mihalcea, Markus Rudy and Thomas Fossati for the comments.

References Normative References This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. 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. 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. The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. 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. 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 Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. Google LLC n.d. Apple Akamai This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators.

Design Rationale defines a mechanism for HTTP/2 and HTTP/3 servers to present additional certificate-based credentials after TLS connection establishment using TLS Exported Authenticators . 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 .

Motivating Example: STET The Split-Trust Encryption Tool (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.

Document History

draft-reddy-seat-expat-transport-00 Initial version.