[OAUTH-WG] Re: Call for adoption - PIKA

Giuseppe De Marco <demarcog83@gmail.com> Tue, 25 June 2024 23:03 UTC

Return-Path: <demarcog83@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 1EA35C18DB9B for <oauth@ietfa.amsl.com>; Tue, 25 Jun 2024 16:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.857
X-Spam-Level:
X-Spam-Status: No, score=-6.857 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 QzKFCR3IkGCA for <oauth@ietfa.amsl.com>; Tue, 25 Jun 2024 16:03:56 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 9C60CC1840F4 for <oauth@ietf.org>; Tue, 25 Jun 2024 16:03:56 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-57d280e2d5dso6284721a12.1 for <oauth@ietf.org>; Tue, 25 Jun 2024 16:03:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719356634; x=1719961434; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YH1wItN7x8RFa7MM8I2jEboFw0OWUMD5INMlL7A6V54=; b=OEvEopilk8hVVMvoAgmx4yNTykQZXWKhcGa+7PgjCEtlat6rAKBARb1kXjGfuq2AEK JIA2dx0CTW1OSs8dUan0DLCjd3H5AF0bC9RkHRACz4+P5W3As+6A5RMSPsW+0MKnVITH qQyiNid20QRlpVHay7meJ4hcMGoEz9qUE5fEJcwu/2+bxc3Xz7be+ene02p9Qk8Q5iGx lgP6YhVIeTiChYlt/K4mQqigJs84nDVpO/NefI1jsOaMX+khaW6d3/FXC++KQoUo2FY7 E1AA1pTmWDmwSrnIcOyt+eHDR71nOVOSKzCMU20+rEISnTk8tl5Sxs1ZumvgSKEyUy+d VFSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719356634; x=1719961434; h=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=YH1wItN7x8RFa7MM8I2jEboFw0OWUMD5INMlL7A6V54=; b=kBvLq4qGX1R8kZyNM5RXOR7Byleq9DLUvK79rcznYYscZ8vWFFMB8l5Z4Qc0Gnhsdm ARmQb5oRCXK/D4/48mrFD819l+igg9FX10FUxhjs8NDTW8U4obvoWhIY6mhYD/YchVQt 7aYFcmdRzZfwwxeUJgtYqzgu3sgUETNp6k76U8G1K58PUlNXHNAz8YC2efkvk5gND1Xb 2y6Hj5pJZcM9BA1CDvSwbWemn1FzNcs3V2jJkUw0mBF3iv3wRY6r7vY8yAp+BvCPRa/f 6Q4CtD7UaT4Fvl3pV0znk0TsMMXGyHS3t0zprkxNW6g+mtrEwQywhmPuu8acwRFgsikr 8+vQ==
X-Forwarded-Encrypted: i=1; AJvYcCVjMLpFuR+uHuIwKwwQCyz8SF4kGmynxRm4WCK7gbxNy1Gcg7VSjfBZNTmKmj41zy7JT8sWP+kXBYZT2PhZZQ==
X-Gm-Message-State: AOJu0YzB+SMWA8WwJ4D+akmAUR4qML1QmYXE0LRYXV7TjIXvp1npSeno 3UPeXKFuYXl2RznEAIpowPV0bC5IHoB9ZGV6MnnNIaWmH08TM7A7vu/m5o4I3QE51RBbtevYNvI onEGMKZB3+0s9Jt9r/9JYpGPoyrgYXg==
X-Google-Smtp-Source: AGHT+IHUTaNB6jrBbkUKeRhaVS/lXXiGfERbFngvhxw0IBoc+5is5uJu4yoClGYdeP/cOURRLNO+0NfT253P0PqX6Hs=
X-Received: by 2002:a50:bac5:0:b0:57d:c8:d295 with SMTP id 4fb4d7f45d1cf-57d4bd566e6mr4596183a12.4.1719356634311; Tue, 25 Jun 2024 16:03:54 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP9GmF4vp1uzLXK0YYZAHUDjK7RHbhEb4MCXkB7N3Oq4+w@mail.gmail.com> <CAL02cgQYom9P+yGMODkHNE125mZnQxRdUTNQbP4ck4y48cgGTA@mail.gmail.com> <SJ0PR02MB7439E4391F43BC7D045859F2B7D52@SJ0PR02MB7439.namprd02.prod.outlook.com> <CACsn0cnW-N984ErjkLiqGx014GikupYWEJ-VPhOg7oD3Vaa=bQ@mail.gmail.com>
In-Reply-To: <CACsn0cnW-N984ErjkLiqGx014GikupYWEJ-VPhOg7oD3Vaa=bQ@mail.gmail.com>
From: Giuseppe De Marco <demarcog83@gmail.com>
Date: Wed, 26 Jun 2024 01:03:41 +0200
Message-ID: <CAP_qYyn8HYj8e+r-6NOptstk4gBCmbQN-wT7m7VE9tSpjiyaEg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000006e372a061bbee981"
Message-ID-Hash: CMWRI6OPL4GKBPM6VRPYFQ55HSMOMNKX
X-Message-ID-Hash: CMWRI6OPL4GKBPM6VRPYFQ55HSMOMNKX
X-MailFrom: demarcog83@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.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Fx6ppyNOsQQC3pSAdK5XR5qu2Cc>
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>

> If we have a tenant" distinguished by a path, there is already a security
issue with giving it the X509 certificate. It could then imitate any
other tenant
on that server already. That's why we use reverse proxies and put the
certificate only on the proxying machines.

In large deployments, like an entire national public service domain or
multinational organization, using the model you propose may represent a
security issue because, behind the proxy, the services/endpoint are
supposed to be not secured at the application level

Threats like rogue emploies or adversaries taking control of the proxy,
might take control of all the endpoints behaviour, while the additional
application security layer would keep this out of the control of who
controls the proxy

When we mention a trust that scales I also think about these distinct
layers enforcing the security of each single endpoint




Il mer 26 giu 2024, 00:12 Watson Ladd <watsonbladd@gmail.com> ha scritto:

> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
> <michael_b_jones@hotmail.com> wrote:
> >
> > The other critique I voiced of the approach is that the
> application-level X.509 certificate can be used to secure the HOST part of
> the issuer, but not the entire issuer, since in general, the issuer will
> contain a PATH.  Yes, the service hosting the issuers controls all the
> paths, as Richard replied earlier, but it’s not the service who is the
> attacker that this enables.  The attackers that not securing the PATH
> enables are the tenants themselves.
> >
> >
> >
> > An attacker could host a tenant at the service and get an X.509
> certificate securing the HOST part of its issuer.  However, because a
> legitimate tenant at another path shares the same HOST, the attacker can
> copy its X.509 certificate chain and utilize a substitution attack to make
> unauthorized statements about the victim tenant – statements that were not
> made by the hosting service.
> >
> >
> >
> > This attack was not addressed, and I believe is intrinsic to the
> decision not to protect the entire issuer value.
> >
> >
> >
> > I believe that adopting this draft would result in this attack occurring
> in practice.
>
> To be clear, drafts get modified by the WG after adoption so adoption
> is not the same thing as WGLC.
>
> However, I'm not sure I understand your attack scenario. If we have a
> "tenant" distinguished by a path, there is already a security issue
> with giving it the X509 certificate. It could then imitate any other
> tenant on that server already. That's why we use reverse proxies and
> put the certificate only on the proxying machines.
>
> Sincerely,
> Watson
>
>
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>