Re: [Wimse] Binding tokens to TLS sessions

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sun, 21 January 2024 17:00 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: wimse@ietfa.amsl.com
Delivered-To: wimse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BDDC14F618 for <wimse@ietfa.amsl.com>; Sun, 21 Jan 2024 09:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEGIvkGY-KNE for <wimse@ietfa.amsl.com>; Sun, 21 Jan 2024 09:00:35 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F981C14F616 for <wimse@ietf.org>; Sun, 21 Jan 2024 09:00:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1705856430; x=1706461230; i=hannes.tschofenig@gmx.net; bh=evWGMbsda+wev2C5KGNIClYA510pSY7BUrXe6pEL1dU=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=cpE+Wng7Y8ETNptfTyaZjU51b0VSPG3XuibnugoUjIAhaSbAHFNK0Bb10JwOdDDY LO+c3qioQ9ttx1hrwf52q0y+vImoLGdJwXP0U66DKR2yIZc8DeYUyI+JWMXhg7Z/o 8JlWTQ62l+FcQhvcj5yRFEN8JG9sOVrZq2XCfKYqi02opr9aUCCSbKMm6/KV2FYXu PSkOWmZrlm/HLo/YWyofezkYQeInv9Z7glyawj46Wrm0YATiDo1b8nOEL69+JoT+j KY97EIuz2wZB8hUyJ5gcPL+rFDH5t85z9L2z5rGDHCgsItaNcIBB9FG/G2nIPOHCC iV0MX3R86O71Yh+BUQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [172.16.254.186] ([185.176.157.173]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N0XD2-1rDNgf3mk8-00wXR6; Sun, 21 Jan 2024 18:00:29 +0100
Message-ID: <bbc32472-0b4b-47bd-9523-9a0f68ef2aa3@gmx.net>
Date: Sun, 21 Jan 2024 18:00:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Watson Ladd <watsonbladd@gmail.com>, Justin Richer <jricher@mit.edu>
Cc: Orie Steele <orie@transmute.industries>, Evan Gilman <evan@spirl.com>, "wimse@ietf.org" <wimse@ietf.org>
References: <CAOB-mKkA55gUhxAfzZyU8u2A1pQ4gtcrpEo0n3o_mxAvRXj1kg@mail.gmail.com> <CACsn0ckjz_1shovt2KCHfnbWO-y_kbd98gV+CBHA4Lmd3nVj8w@mail.gmail.com> <CAOB-mKmbK=L8dW9y36U3ctr7npqcEsTA=4LAz2tz9xuDAiq4-g@mail.gmail.com> <CACsn0cnc1r0LprNMk0nu744UoctosuX1Mw_OaBAJqiC9iJq14w@mail.gmail.com> <CAN8C-_LBsYBnRAj+Q8H_UvEaPPLk3fcY9C6rmjLdMX9QsyBY5Q@mail.gmail.com> <LV8PR01MB867712F37E84D9A77A8BAC55BD772@LV8PR01MB8677.prod.exchangelabs.com> <CACsn0cm7HQtKW=sszrAQz8-Y7Cz8Sp+fDnuZo2xuxkc-_W-Hbg@mail.gmail.com> <85E44A80-36B9-4027-895D-49A0CE311B09@corp.intuit.net>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <85E44A80-36B9-4027-895D-49A0CE311B09@corp.intuit.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:BCsxxM5BaN4TsiWgnRNqGs9j7ADtYU7aDoAe7TIyzbDe7lVMGiB Wpi85/CdxEbcJyMwZ5xUv8M2HO/IIkoBYnD5ATa4fMJOEzkSi6Wjp5r9QOtEhGmMwD4JAcR 2EePR9hkg84ZMC2pjz31JVGcN+VCWhCfQoTYcaBf2ARFO3713BguI72caqQNzYQXn2TjLM0 cDhbZX5nVbxTTXJYEIxVw==
UI-OutboundReport: notjunk:1;M01:P0:t7APQSKas0c=;jLmJxgbS6tTEvoK9s6bt27rT8Cw 8rq9y8zvXLLRIhjHcdt+kgzez/jywRkb4VCYbp/fI1YqMmdC0Ui7WffGUjXedXphXtA+zz4Km fZXZEQCbXEeLCpZrvjno9obtlj7r/pa5r/od7fIPA4IuGX2yVdDjSGxV0g6A+LHo2qbZsKlZr WxY+zmvfeR0xk5Uuyk+kIpHfXzJv8TtPdOModsPP1ME+U3+9p99Y5LRUTAu2yYO5NpWh2mcr2 OecSjrY10Ob8RHA/sMMMosMofzLVw0sXqrOjPJ29xdtvpU5HQVKGPrXwzxDK6nn2kpi5Rh7D0 sOSkWLZhq/tIAfViBf//kIHO9pH6iSuhx7XOmp/TET7uzM0I9UXqHdwYocKGXuw6nLULK+Zh8 eppbaFlRtGrdz94jExMhUB6EZ90knSlVC6xDeQSnUihdekhbLIaMiX925gK59Gg6KWB13I57h Z3/Y+Jdt841Tl7yl5WO4HD+S8ccHCy65GTD13cZdCYxeEwdXL1YtHUbGoiXWLUSzVTdyOJ+Rx hyCjIkYUVpMNnz7xfqMcVXuC3QPk0zHQaGtrPRuxWnKFpMGPcggi3blJp5+7AbTkn/ekQ+yzG +5erdX+gjwMQgOoJDJr+wjRkkO5s8k0iBGlwExTSCQBXhQPUB8vF8IU6jA8LeVGrBqLoROMmq svKraFygour+St7zKdW3gw5LsunkR9YDes2BXZtm5aFxdQgCirJgDU+fvgaMSEmy/jc5yDzdt wErTXmQpTqnUHYOtjT8ocZAyUuZU0LyLpqJwGap3JA0CYT0vJGX8WUHGHH+D8MAWSnegLHxbL PYghhRZTJS8L5g0nPH0XfJC1DtsxAENZg5BDSxBJdCm+9XKu67u65Ds/uEBPGrEen01TQ1psT z8lJVs/rypSEZ58+/SF00+52P7xmOfEdMVqVZzkdA3U9cJcOkhamWrMjhK3PWWtvF96w+nG03 c22BJF4iJV6Of+0vZMr05FI7cv0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/wimse/QoUDhGdbOh11Z7H6oQTuG-vE6DU>
Subject: Re: [Wimse] Binding tokens to TLS sessions
X-BeenThere: wimse@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: WIMSE Workload Identity in Multi-Service Environment <wimse.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wimse>, <mailto:wimse-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wimse/>
List-Post: <mailto:wimse@ietf.org>
List-Help: <mailto:wimse-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wimse>, <mailto:wimse-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2024 17:00:41 -0000

FWIW you could still do a binding to TLS but this usage of TLS would be
at the application layer.


See, for example, Application-Layer TLS
(https://datatracker.ietf.org/doc/draft-friel-tls-atls/) for how you can
use TLS across middleboxes.


Ciao

Hannes


Am 21.01.2024 um 17:57 schrieb Yaron Sheffer:
> Even though Joe and I wrote the new text together, on second thought I think this particular sentence is a mistake.
>
> Yes we need to bind tokens to the caller's cryptographic identity (public key), to prevent token stealing. But this is application-level binding.
>
> TLS-level binding is impractical because we're assuming TLS middleboxes in an enterprise environment, and middleboxes would break TLS channel binding.
>
> So I would suggest to change:
>
> 	This deliverable includes both a token format and usage, including binding to the TLS layer.
>
> To:
>
> 	This deliverable includes both a token format and usage, including binding to caller's identity.
>
> We might still end up with *optional* TLS binding for cases where it works, but I don't think it needs to be in the charter.
>
> Thanks,
> 	Yaron
>
>