On Wed, May 20, 2026 at 12:44 AM Ramki Krishnan <[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]
> To unsubscribe send an email to [email protected]



-- 
Astra mortemque praestare gradatim

_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to