Re: [OAUTH-WG] Signed JWK Sets

Neil Madden <neil.e.madden@gmail.com> Fri, 12 April 2024 06:38 UTC

Return-Path: <neil.e.madden@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C370C14F5FA for <oauth@ietfa.amsl.com>; Thu, 11 Apr 2024 23:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lyScZZr7Y9HW for <oauth@ietfa.amsl.com>; Thu, 11 Apr 2024 23:37:59 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F89C14F5F7 for <oauth@ietf.org>; Thu, 11 Apr 2024 23:37:58 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-516e3103d92so227938e87.0 for <oauth@ietf.org>; Thu, 11 Apr 2024 23:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712903876; x=1713508676; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=Aavhh4llQ4+SFkvfm20IbVHpulgzo/gJpIc7S8jW9qo=; b=gqJEO7+b6KrQIhLTIhOcVSG4OMycjMUPJA11TSutosWUGZwVEQiB/5e14kni2JAjMK GFgCVDg+cixUT+cu6IqdUepefKPjMQscA2K+vdWMZzykICvrJZbTBOzBQxxGUTo+t0e2 Ktb1yBTQeNOyrrZYdSOLKtXdWmJawjTXJXXtFhN0mu9vjIyokfazqETvh24znFBpeltV i+hn3wrDF5t8vx/3Q2Y345UPmWTjociOl8LsqtLYkXzEWzUa5kSBXQQSgWUwxbRMvbuH gr5y9L+Bagsokzy6bilGwGgZ4lJjy8cXnHHFno3/Md4XZX+Gkt5cQX1/RCn4ee2ot7TP UqRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712903876; x=1713508676; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Aavhh4llQ4+SFkvfm20IbVHpulgzo/gJpIc7S8jW9qo=; b=k67MpJk1z4TEcGxcoP2n57XR+sFBNzMCIVHjII2LG+AfDAILS8ht7/dup5wxB/FkSv p7ZQU+WiNsR4CFBsoTwnQ/t2YgD9MooUAQ3+l+Qbnbh5sCo0REUOkXc6wASlI3bo2Zyn B/jBS0lhki+vGk0i3VBVAMXa9xOdmcYPfTtP8hjFeUJK7Bv9vAaqR6eiNXjoeKjwcqgP pMHBdLplplcPFesVXrljN+MkWVuHQqvOtyt/HzYk49XdLbsXOZ7LmZxQjprRGkEYG01N tqHpDMvpDmpnI//02xJDQ4eiDhAa1WlvUHpG+JMHkzhjxBV70a8jG15WZhC1c+XSr3s3 j/gA==
X-Gm-Message-State: AOJu0Yxj/g07N96/SexuAilQhSkyvpyjEXEHxOcyg3SCktemKPeZ7SPP mNb9Wu5ZFuQ6E668W8I/9VRwB6X050ByiwH4TlhrJNMyD8GgSziZ3gOG2SIK
X-Google-Smtp-Source: AGHT+IEc6da9RvzpsKzEYW1u+lGiav0yotvomNcIi1G4mLj5Pw1HWbZrWypKultB/Z+4uisHmfgIEA==
X-Received: by 2002:a2e:7a19:0:b0:2d8:1b2a:6526 with SMTP id v25-20020a2e7a19000000b002d81b2a6526mr880730ljc.4.1712903876314; Thu, 11 Apr 2024 23:37:56 -0700 (PDT)
Received: from smtpclient.apple (234.243.159.143.dyn.plus.net. [143.159.243.234]) by smtp.gmail.com with ESMTPSA id i7-20020a05600c354700b00416aca5ff66sm7791019wmq.19.2024.04.11.23.37.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Apr 2024 23:37:55 -0700 (PDT)
From: Neil Madden <neil.e.madden@gmail.com>
X-Google-Original-From: Neil Madden <Neil.E.Madden@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Fri, 12 Apr 2024 07:37:44 +0100
Message-Id: <1785DFCD-050E-4798-9438-332A3847014F@gmail.com>
References: <CAEM=y+VkFksRsH9WYBq2yZu7HR5GCFEgT98tLmrs_PgF_+tHow@mail.gmail.com>
Cc: OAuth WG <oauth@ietf.org>, Sharon Goldberg <goldbe@bastionzero.com>
In-Reply-To: <CAEM=y+VkFksRsH9WYBq2yZu7HR5GCFEgT98tLmrs_PgF_+tHow@mail.gmail.com>
To: Ethan Heilman <eth3rs@gmail.com>
X-Mailer: iPhone Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gY7GB_sflNqa_qEOJdLcpP6s5Rw>
Subject: Re: [OAUTH-WG] Signed JWK Sets
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2024 06:38:01 -0000


> On 12 Apr 2024, at 03:16, Ethan Heilman <eth3rs@gmail.com> wrote:
> 
> 
> Hi Neil,
> 
> I agree that PIKA would not protect against an attacker compromising a JWKS URI via a mis-issued TLS cert.
> 
> I was thinking of a simpler attack where the attacker compromises the server where a JWKS URI is hosted or the JWKS is stored. For instance consider an JWKS which is read from a database. An attacker could use a SQL injection to add their own key to the JWKS. Because such an attacker does not compromise any TLS certificates PIKA would defeat this attack (assuming the verifier required PIKA for that JWT issuer).

It depends how the PIKA is created. If you mean that the database stores the signed PIKA, then yes that would prevent the attack. But if the database just stores the keys and another process periodically extracts them and signs them to create the PIKA (which seems more likely to me), then the attack still succeeds. 

> 
> Today, write access to a JWKS is sufficient to comprise the signing authority of a JWT issuer. With PIKA write access to a JWKS may not be sufficient to compromise the signing authority of a JWT issuer.

I’m not sure this is true in many cases. Doesn’t PIKA essentially assume that the TLS cert signing key is accessible to whatever process creates the JWK Set? So if you have write access to the JWK Set, you often will also have access to that private key - either directly, or via some API/HSM call. Not always, but I think in many scenarios. 

— Neil