Hi,
+1 to Watson points.
As the main driver is Agentic AI Amplifi[cation] we need to encompass that in
the architecture of A2A/MCP/and other flavors. In practice: you cannot assume
the TLS session stays the same across tool calls
* For remote MCP over HTTPS, each tool call may or may not reuse the same
TCP/TLS connection. It depends on:
* Connection pooling in the HTTP client library
* Keep-alive timeouts
* Load balancer behavior (L4 vs L7)
* Serverless/lambda backends that terminate connections aggressively
* For MCP over SSE transport: long-lived connection for server→client
events, but client→server requests may use separate connections
* For A2A
* Agents may be behind API gateways, service meshes (Envoy, Istio), or
serverless infrastructure
* Each of these can terminate and re-establish TLS independently:
* Even long-running agent tasks (hours) will almost certainly see
connection drops and reconnects
Therefore, if connections are short-lived or unpredictable in agentic
deployments, the client will need to re-prove constantly. In the worst case
(serverless, aggressive connection cycling), it will degrade to O(n) like DPoP,
but without DPoP's per-request integrity properties (htm, htu).
Let’s add to the threat model: where is the key stored? The usage or non usage
of TPM/HSM will also present the same threat modelling as for RFC 8705.
Jeff
Jean-François “Jeff” Lombardo | Amazon Web Services
Architecte Principal de Solutions, Stratégie de Sécurité
Principal Solution Architect, Security Strategy
Montréal, Canada
Commentaires à propos de notre échange? Exprimez-vous
ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
Thoughts on our interaction? Provide feedback
here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
From: Ramki Krishnan <[email protected]>
Sent: May 20, 2026 3:27 PM
To: Watson Ladd <[email protected]>
Cc: [email protected]; A. Prasad <[email protected]>; diego lopez
<[email protected]>; Diego Lopez <[email protected]>; srini
addepalli <[email protected]>
Subject: [EXT] [OAUTH-WG] Re: New Work: TLS Session-Bound Access Tokens
(draft-mw-oauth-tls-session-bound-tokens)
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne
cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas
confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le
contenu ne présente aucun risque.
Thanks Watson.
In practical deployments, TLS is never end-to-end - it is between
intermediaries e.g. microservice to microservice, microservice to api gateway
BTW, how this idea can easily integrate with service mesh sidecars is described
in Appendix B.
Thanks,
Ramki
On Wed, May 20, 2026 at 8:13 AM Watson Ladd
<[email protected]<mailto:[email protected]>> wrote:
On Wed, May 20, 2026 at 12:44 AM Ramki Krishnan
<[email protected]<mailto:[email protected]>> wrote:
>
> Hi all,
>
>
> We'd like to bring draft-mw-oauth-tls-session-bound-tokens to the WG's
> attention and gauge interest in adoption.
>
> Problem
>
> - Bearer token replay remains a live threat, particularly as autonomous AI
> agents and service mesh architectures chain API calls across multiple hops.
> In these environments, a stolen token can be replayed on a different TLS
> connection. RFC 8705 (cert-bound tokens) binds tokens to the client
> certificate but not the specific session; RFC 9449 (DPoP) provides
> per-request binding but requires a signature on every request, creating
> overhead that is prohibitive at scale and difficult in sidecar deployments
> where the signing key is isolated from the application process.
>
>
> What the draft does
>
> - We define a mechanism that binds OAuth 2.0 access tokens to a specific TLS
> session using the TLS Exporter/EKM value (RFC 5705 / RFC 8446 §7.5). A signed
> proof JWT — carrying the access token hash (ath) and the EKM value (ekm) — is
> constructed once per (token, connection) pair and reused across all requests
> on that connection. This amortizes the cryptographic cost while preventing
> cross-session replay.
>
> - The mechanism fits naturally alongside RFC 8705 and RFC 9449 and helps
> satisfy the sender-constraining recommendations in RFC 9700.
Back when I was in grad school, people proposed using TLS Exporter
bound WebAuthn tokens. Early in my career though certificate client
auth could be fixed in HTTP/2 via signing exporter values. Later on I
think we had another bright idea to tie things to exporters. All of
this foundered on a basic architectural issue: TLS and HTTP don't line
up. HTTP requests end up using different sessions all the time, and
intermediary software that terminates TLS on each side often can't be
modified to pass on the exporter information that's required. As
people build things like service meshes and the like, this becomes a
bigger problem.
IMHO we should be able to solve this "once and for all" by defining a
notion of initial TLS termination point that sends back an exporter
value sufficient for derivation of all exporters other things down the
chain can use, but that's a lot of work.
Sincerely,
Watson
>
>
> Links
>
> Draft:
> https://datatracker.ietf.org/doc/draft-mw-oauth-tls-session-bound-tokens/
> Authors: Ramki Krishnan, A Prasad, Diego Lopez, Srinivasa Addepalli
>
>
> We welcome feedback on the approach.
>
>
> Thanks,
> Ramki (on behalf of the co-authors)
>
>
> _______________________________________________
> OAuth mailing list -- [email protected]<mailto:[email protected]>
> To unsubscribe send an email to
> [email protected]<mailto:[email protected]>
--
Astra mortemque praestare gradatim
--
Thanks,
Ramki
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
