[OAUTH-WG] Re: Deferred Key Binding / TMB

Watson Ladd <watsonbladd@gmail.com> Thu, 05 June 2025 21:18 UTC

MIME-Version: 1.0
References: <E40270D7-F032-49B1-9B10-87167331EA3C@mit.edu> <CACsn0cmbadUJTR7pi36ZwOQFAxvTNraYof30bPcv60qGSRNzdA@mail.gmail.com> <LV8PR01MB8677FB35032113000029E2A1BD6FA@LV8PR01MB8677.prod.exchangelabs.com>
In-Reply-To: <LV8PR01MB8677FB35032113000029E2A1BD6FA@LV8PR01MB8677.prod.exchangelabs.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 05 Jun 2025 14:17:59 -0700
Message-ID: <CACsn0ck4A5ysL=-Z4Mo9sNZc6f6S9dnNrRi0986bMdG=mr4=rA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="0000000000008ca2bb0636d9a68f"
Message-ID-Hash: PI2BLK4NOM2TCMQRYRXF3QVNOTNHWFWZ
CC: oauth <oauth@ietf.org>
Precedence: list
Subject: [OAUTH-WG] Re: Deferred Key Binding / TMB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ER_RwUAu6vE1u0SKO91e09GTXNo>

On Thu, Jun 5, 2025, 2:06 PM Justin Richer <jricher@mit.edu> wrote:

>
> Yes, this completely upends the security assumptions of PoP as we know it.
> That's exactly why we should discuss this as a distinct pattern, because
> people are doing this in the wild and it needs to be handled differently.
>

I myself couldn't tell you what the resulting semantics are. Can we just
tell them to stop until they can explain why what they want is secure?

------------------------------
> *From:* Watson Ladd <watsonbladd@gmail.com>
> *Sent:* Thursday, June 5, 2025 1:15 PM
> *To:* Justin Richer <jricher@mit.edu>
> *Cc:* oauth <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] Deferred Key Binding / TMB
>
> On Thu, Jun 5, 2025 at 9:45 AM Justin Richer <jricher@mit.edu> wrote:
> >
> > Hi Chairs and WG,
> >
> > Back in Bangkok, we presented the draft
> https://datatracker.ietf.org/doc/draft-richer-oauth-tmb-claim/ that
> introduces, in a concrete way, the notion of getting a token bound to a key
> that you don’t possess. As we discussed, this is a topic that keeps coming
> up in the OAuth space and is usually dutifully pushed aside for the sake of
> simplicity (and some would argue sanity).
> >
> > The chairs mentioned pulling together an interim meeting for the OAuth
> WG for us to discuss this topic ahead of Madrid, to see if there was
> anything more we as a community want to do with it. As we’re now more than
> halfway between the meetings, we wanted to bring that up again and see if
> that interim can get scheduled soon. I’d also like to encourage people to
> read through the draft and open the discussion here on the list more.
>
> This draft, plus the properties of many existing signature schemes
> like RSA and ECDSA, creates the possibility of an attacker getting a
> credential issued that will work with an already existing PoP exchange
> without actually having possession of the key. (They register the
> credential after seeing the PoP exchange, but before finishing). This
> is a very subtle change in the semantics that likely invalidates a lot
> of security assumptions.
>
> Why do we need to do this?
>
> >
> >  — Justin
> > _______________________________________________
> > OAuth mailing list -- oauth@ietf.org
> > To unsubscribe send an email to oauth-leave@ietf.org
>
>
>
> --
> Astra mortemque praestare gradatim
>

[OAUTH-WG] Deferred Key Binding / TMB Justin Richer
[OAUTH-WG] Re: Deferred Key Binding / TMB Watson Ladd
[OAUTH-WG] Re: Deferred Key Binding / TMB Ethan Heilman
[OAUTH-WG] Re: Deferred Key Binding / TMB Justin Richer
[OAUTH-WG] Re: Deferred Key Binding / TMB Watson Ladd
[OAUTH-WG] Re: Deferred Key Binding / TMB John Kemp
[OAUTH-WG] Re: Deferred Key Binding / TMB Justin Richer
[OAUTH-WG] Re: Deferred Key Binding / TMB Filip Skokan
[OAUTH-WG] Re: Deferred Key Binding / TMB Justin Richer
[OAUTH-WG] Re: Deferred Key Binding / TMB Pieter Kasselman
[OAUTH-WG] Re: Deferred Key Binding / TMB John Kemp