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

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

Return-Path: <watsonbladd@gmail.com>
X-Original-To: oauth@mail2.ietf.org
Delivered-To: oauth@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B1CF03161A1D for <oauth@mail2.ietf.org>; Thu, 5 Jun 2025 10:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_IYsKGFQ2Zi for <oauth@mail2.ietf.org>; Thu, 5 Jun 2025 10:15:50 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3BE343161A18 for <oauth@ietf.org>; Thu, 5 Jun 2025 10:15:50 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3a361b8a664so1074499f8f.3 for <oauth@ietf.org>; Thu, 05 Jun 2025 10:15:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749143749; x=1749748549; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KZGfNe+5NALLUR1WdNKE8UQ+/9vr43U+RX14TxYMEcw=; b=EzBtBYYl3cavJeg9KZu/RpnRZ5F+y+/vIsiKPSoeJ67zqtWeWQV/yDCVqelpVyWrvf DYoSUsKylBP593O3PuMl55CwYbO1HRZ6G2fiWwBorUMivEQ0YKGaO7C5oCpDaE9MU4uO s9/MPltDjx2baFcriALXL2b5ZWtTPugTD+ZJ2OzyxpEfV6enKVK2W9NJYeAt+N3Ju7XE 73qwBJBR5ZM50bBCUh2VOBX8Z1hsZxVb+KP7i2P02dv8o1yeAkFnMR7tNDQaOmXNH+5E CzjC1hoXUxeuf+xuuewhDAjF/v6q94Mm0uA3uIHPxAYXgee7wyuzkJe7U6aXNhF+FaR2 RlzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749143749; x=1749748549; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KZGfNe+5NALLUR1WdNKE8UQ+/9vr43U+RX14TxYMEcw=; b=p+cADg8cBSohTccbgNWnMkVbeJQCWa+q4atwtjm61EZF7+DZGxyMfBIiXda7rDzxlP 3FoMDeEA6tpaxkohsMEJ2pw1484p9rteAULocjhFg07VpZ3GiDzZ2sdhkmlsRGK0I9d9 fd/cKHOa/RLprClafiy9eSjZ8/1cbMDpFlIuGvnWdZS3V0uKovU7f5VQNBl8l0YKycL+ Y6Iaf/koE/Uv9OJtrVWDOcEaz2kSi4GZ8Dm9GR+vc22EJv+v9wgPqdmEYq77jqIZ2MLD ysA7JK/05mPzmCNptH83fwTC3foqdwK95htDA9IbeZITDwLoUITPH8DyVxfPuPZNxn9I VAaw==
X-Gm-Message-State: AOJu0YzYwebG3UVlNZDO628+u6jt64u3xtzuoT/eMoKinDVGuIEqas4m 7sww/DEWwcy73n226l07ZZTqPxO2FG/FElhUlMqrI/AGDKhfItb2/LTlWm8s5L1e8rmmYSEjBXJ WTfZQ1jQfQhccRKtUgnPo2Ay79s1K2ECceQ==
X-Gm-Gg: ASbGncvQaEVLGxoRao4tPPD+V68MoAJ9KcGcTQN14gNFyFre/LHN6aswmXgA71ipApX 8clIC3a9uS5puLtT5vGkCPfLUVzU0O5Qzyq3kCIOst1DDbvHYlwazn6ugcjhlSypKg+iSRUEe91 FkMX29XD4YePfQjGrgG7Yc/CH+oiMmzQuzfN4GuW8Vjdup20XAZkeDL2PvYObhFV8vZQ==
X-Google-Smtp-Source: AGHT+IH7Qnbyd0ShqNxjIQnz4ospov/Hny5xpHF85Cv9ZYooFadFZgaQ0I5nnaKVPUqZHS9aNPtdM99KdZ0JIrRPvfg=
X-Received: by 2002:a05:6000:2901:b0:3a4:d53d:be23 with SMTP id ffacd0b85a97d-3a51d969a22mr6793605f8f.30.1749143749058; Thu, 05 Jun 2025 10:15:49 -0700 (PDT)
MIME-Version: 1.0
References: <E40270D7-F032-49B1-9B10-87167331EA3C@mit.edu>
In-Reply-To: <E40270D7-F032-49B1-9B10-87167331EA3C@mit.edu>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 05 Jun 2025 10:15:37 -0700
X-Gm-Features: AX0GCFseKwHA58wYKrW2uCwUJ-mBwGylQCRZAUXIzjdozwEkRYM_8YqZjvaLRRg
Message-ID: <CACsn0cmbadUJTR7pi36ZwOQFAxvTNraYof30bPcv60qGSRNzdA@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: CTWRYGLBY3XUBOEYP6UFXBXCWT6DOEDE
X-Message-ID-Hash: CTWRYGLBY3XUBOEYP6UFXBXCWT6DOEDE
X-MailFrom: watsonbladd@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: Deferred Key Binding / TMB
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_qThqEIPeoB6zOSdTem4FNSULv8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

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