Application-Layer Transport for Exported Authenticators and Attestation
draft-reddy-seat-expat-transport-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Hannes Tschofenig | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reddy-seat-expat-transport-01
SEAT T. Reddy
Internet-Draft Nokia
Intended status: Standards Track H. Tschofenig
Expires: 7 January 2027 UniBw M.
6 July 2026
Application-Layer Transport for Exported Authenticators and Attestation
draft-reddy-seat-expat-transport-01
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 7 January 2027.
Reddy & Tschofenig Expires 7 January 2027 [Page 1]
Internet-Draft ALTEA July 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 . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 11
4.2. Connection Establishment . . . . . . . . . . . . . . . . 11
4.3. Capsule Framing . . . . . . . . . . . . . . . . . . . . . 12
4.4. Capsule Type to Message Mapping . . . . . . . . . . . . . 12
4.5. Bidirectionality . . . . . . . . . . . . . . . . . . . . 13
4.6. TLS Requirement . . . . . . . . . . . . . . . . . . . . . 13
4.7. Operation over HTTP/2 and HTTP/3 . . . . . . . . . . . . 13
4.8. Path Configuration . . . . . . . . . . . . . . . . . . . 13
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 7 January 2027 [Page 2]
Internet-Draft ALTEA July 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 7 January 2027 [Page 3]
Internet-Draft ALTEA July 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 7 January 2027 [Page 4]
Internet-Draft ALTEA July 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 7 January 2027 [Page 5]
Internet-Draft ALTEA July 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 7 January 2027 [Page 6]
Internet-Draft ALTEA July 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.
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.
Reddy & Tschofenig Expires 7 January 2027 [Page 7]
Internet-Draft ALTEA July 2026
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;
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.
Reddy & Tschofenig Expires 7 January 2027 [Page 8]
Internet-Draft ALTEA July 2026
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.
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.
Reddy & Tschofenig Expires 7 January 2027 [Page 9]
Internet-Draft ALTEA July 2026
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):
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.
Reddy & Tschofenig Expires 7 January 2027 [Page 10]
Internet-Draft ALTEA July 2026
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.
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:
Reddy & Tschofenig Expires 7 January 2027 [Page 11]
Internet-Draft ALTEA July 2026
:method = CONNECT
:protocol = exported-authenticator
:scheme = https
:path = <configured path, e.g. /.well-known/expat/>
:authority = <server 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.
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:
Reddy & Tschofenig Expires 7 January 2027 [Page 12]
Internet-Draft ALTEA July 2026
+=========================+=======================+
| 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.
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/.
Reddy & Tschofenig Expires 7 January 2027 [Page 13]
Internet-Draft ALTEA July 2026
5. Use with draft-fossati-seat-expat
When used with [I-D.fossati-seat-expat]:
* Whether attestation features are used on a given connection is
determined by whether the cmw_attestation extension was negotiated
per Section 3.1 of [I-D.fossati-seat-expat]. A server MUST NOT
send an auth_capabilities message on a connection where that
extension was not negotiated.
* 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.
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.
Reddy & Tschofenig Expires 7 January 2027 [Page 14]
Internet-Draft ALTEA July 2026
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.
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.
Reddy & Tschofenig Expires 7 January 2027 [Page 15]
Internet-Draft ALTEA July 2026
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 7 January 2027 [Page 16]
Internet-Draft ALTEA July 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 7 January 2027 [Page 17]
Internet-Draft ALTEA July 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 7 January 2027 [Page 18]
Internet-Draft ALTEA July 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 7 January 2027 [Page 19]
Internet-Draft ALTEA July 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 7 January 2027 [Page 20]
Internet-Draft ALTEA July 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-03, 4 July 2026,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
expat-03>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/rfc/rfc8441>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Reddy & Tschofenig Expires 7 January 2027 [Page 21]
Internet-Draft ALTEA July 2026
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.
[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,
<https://www.rfc-editor.org/rfc/rfc9147>.
[RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3",
RFC 9220, DOI 10.17487/RFC9220, June 2022,
<https://www.rfc-editor.org/rfc/rfc9220>.
[RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261,
DOI 10.17487/RFC9261, July 2022,
<https://www.rfc-editor.org/rfc/rfc9261>.
[RFC9297] Schinazi, D. and L. Pardue, "HTTP Datagrams and the
Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
2022, <https://www.rfc-editor.org/rfc/rfc9297>.
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, <https://datatracker.ietf.org/doc/html/
draft-ietf-httpbis-secondary-server-certs-02>.
[STET] Google LLC, "STET: Split-Trust Encryption Tool", n.d.,
<https://github.com/GoogleCloudPlatform/stet>.
Reddy & Tschofenig Expires 7 January 2027 [Page 22]
Internet-Draft ALTEA July 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 7 January 2027 [Page 23]