[OAUTH-WG] Re: Call for adoption - PIKA
Richard Barnes <rlb@ipv.sx> Thu, 27 June 2024 15:07 UTC
Return-Path: <rlb@ipv.sx>
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 E6B87C151086 for <oauth@ietfa.amsl.com>; Thu, 27 Jun 2024 08:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=ipv-sx.20230601.gappssmtp.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 EDOq13gAjTYR for <oauth@ietfa.amsl.com>; Thu, 27 Jun 2024 08:07:05 -0700 (PDT)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 05785C151069 for <oauth@ietf.org>; Thu, 27 Jun 2024 08:07:04 -0700 (PDT)
Received: by mail-il1-x135.google.com with SMTP id e9e14a558f8ab-375e0e258b7so34376895ab.1 for <oauth@ietf.org>; Thu, 27 Jun 2024 08:07:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1719500824; x=1720105624; 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=JKzSBYZGzUBTq591DXGNxDTK1UdRlHqflRPaFKkMDoU=; b=BthppWVBkRddqbJqqn0FyLRncfypnkvXlw+AQDf/472JW/ifZhu63y4PcNcvKaorIX VL1wib/dom03B5xmkXdcO0nKAKuoik/sFpujwQ22nXRpUMxcUmd+H6kRDgDkKiO9jmIn dyrxhHOtUXmTRIx4OG/Xisu0+Cwui5V6Fdkw+r8OIHEiJiwRXSaq8mDAQ+yzK+i2X9bs D6DvfPTQbwLrksz0JT3erPQvU86RNCapVgBJoeLex7MgpmuPzX76RogR/dZhQiBmqvV5 45EtnzjIa9cSobDD5HugsKH5YLFXg4XfpGe3yaHRLf+HZCd6VN4ldyILUcH/J8FW7ABD husg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719500824; x=1720105624; 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=JKzSBYZGzUBTq591DXGNxDTK1UdRlHqflRPaFKkMDoU=; b=byZbLhyoXrUT0igiHBnec12rCore+fW1aUw9c7JjaJ2m5etCGn8puM3UYB0kXEyVh+ ArrFXgLjBZDlsAFDhI7tg77XwOEMULFPMPtpTUtClUvD7VuEeAtTOL96Y548vhRk6q3v uAAvY49pxuZkIDMwV/Jgkg3Iod4rmKSLY+Qr1vUdFqqoQSZ10UbN+GScBRw0Uirx6C/5 Jou4e3nhR+zGKyCHow+B6sTrMfEwhsPOdJH6kRJGIZON6I5OX79+pGIw8zbs7J+T+zJ2 FiHpC0TRoI7FIC/r/kAVbZuU9KLOG4nY8twiKJSyg+KQJZ6XqDes13/bnItN5g842XrU frfg==
X-Forwarded-Encrypted: i=1; AJvYcCUpBdpcGLvb9Z1uRjLJIiUUHDTSog1s+QMK5oKmwWntQYDypHfhpb0119jdfV25jDbqnXtmmirJr1cdXhGI0w==
X-Gm-Message-State: AOJu0Ywvtj3QnYGhS/ulDtXhKfaZp42gCiJL4tpcmOtw0J5KN8Mx/Afg dWNBl6BVPqZJgwOommxhM4XcxA7E+exUVjKrFhTJoPywZ6UnVqMpPSMMJQtC58gh2rCJiiWzuQR edj1TZ4C8MF+ckjMn+8bJChJUqOdQKxMvEIF0MCo8AKa2k7Qe7jc=
X-Google-Smtp-Source: AGHT+IGQsGB+1xab8glmAIBuwMMjni+nA8XCaxpMJuQuG1DQPIVFg2NrH87MaxWZhAT2IAlnttsCWU0hdWI5+PFcbWo=
X-Received: by 2002:a05:6e02:1a44:b0:375:b381:9ad1 with SMTP id e9e14a558f8ab-3763f5aa404mr181289035ab.6.1719500823855; Thu, 27 Jun 2024 08:07:03 -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> <CAOgPGoCZ95hhj5KNQVpAB8d4nfOEXY=ozwNmj690k9iepXjcfA@mail.gmail.com> <CAFje9PhELRPFQux6ffaOtyXDw0xnqF=ijZo74UwTXTZ3E8ECOw@mail.gmail.com> <CAEM=y+VuRjXY0xt3R3HsmZJamg=r=+qhyoO2vqRog=ta_8u+ow@mail.gmail.com> <CAP_qYy=WiSfZ8Bh=eUU_8FR816+SY2ziA9zEdaocZp0qhAyhcg@mail.gmail.com>
In-Reply-To: <CAP_qYy=WiSfZ8Bh=eUU_8FR816+SY2ziA9zEdaocZp0qhAyhcg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 27 Jun 2024 11:06:52 -0400
Message-ID: <CAL02cgSx062MXEZG1a8kfpnur2K4eWAV_jH-7mgkYnhMhLqqiw@mail.gmail.com>
To: Giuseppe De Marco <demarcog83@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000cc21c7061be07bc4"
Message-ID-Hash: 7N7GDCLMPJBOD56WJM44QKQIYRRRSBWY
X-Message-ID-Hash: 7N7GDCLMPJBOD56WJM44QKQIYRRRSBWY
X-MailFrom: rlb@ipv.sx
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/Xjizx-cRooo5AwHBhXNfK84BQKg>
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>
Hi Giuseppe, Asking whether a technology addresses real-world challenges is a fair question. The point of the current draft is that we have empirical evidence that X.509-based authentication works well for many cases, given the very wide usage of things like OpenID Connect Discovery. PIKA seeks to address some operational deficiencies in those models, without changing the trust model. --Richard On Wed, Jun 26, 2024 at 8:21 PM Giuseppe De Marco <demarcog83@gmail.com> wrote: > Hi Ethan, > > I have experience implementing LDAP clients with SASL and SSL, SAML2 SP, > IDP, MDQ, as well as OpenID Connect RP, OP, and RS. It's clear that X.509 > is foundational to our digital infrastructure, making implementation > straightforward due to the widespread availability of supporting libraries. > > However, X.509 has not addressed all issues; it would be unwise to ignore > its limitations and pretend it fits all needs perfectly. > > I can be an advocate for PIKA and am eager to delve deeper into the > technical trust requirements envisioned by the PIKA working group > participants. A new specification should aim to tackle the unresolved > issues. > > Consider this real-world example to illustrate a point: Space Attack > Spoofing eIDs [1]. The article highlights a vulnerability due to the lack > of mechanisms for validating endpoints, which opens the door to > Man-in-the-Middle (MITM) attacks through spoofing. > > From my perspective, part of the solution lies in the trust framework > employed. Even with a vulnerability at one point, having trusted endpoints > could prevent the attack's success. If endpoints were cryptographically > attested through verifiable metadata certified by a trusted third party, or > through a trusted distribution method or trusted policy processing, the > attack would likely fail. The attacker would not be able to redirect data > to fraudulent endpoints. > > Regardless of the technology, data format, or other elements used, these > may not align with our personal preferences or comfort levels, I am > interested in discussing the level of technical trust evaluation we aim to > incorporate into PIKA. Specifically, which problems are we aiming to solve, > and which are we deliberately excluding from the scope of this new > specification. > > When selecting a technology for implementation, it is essential to assess > whether it addresses real-world challenges effectively. I am here to > investigate if PIKA meets these criteria currently or in the foreseeable > future, and to understand the roadmap for its development, if available. > This evaluation is vital for trusting a specification. > > I was too verbose, I am sorry. > Giuseppe > > [1] > https://ctrlalt.medium.com/space-attack-spoofing-eids-password-authenticated-connection-establishment-11561e5657b1 > > Il giorno mer 26 giu 2024 alle ore 19:08 Ethan Heilman <eth3rs@gmail.com> > ha scritto: > >> I strongly support this draft and would have immediate uses for PIKA >> if standardized. >> >> As someone who builds OIDC relying party software I am not worried >> about the X.509 certificate requirement, nor do I consider dependence >> on X.509s or the Web PKI to be an onerous requirement. I already have >> to deal with parsing and creating X.509 certificates in my relying >> party software. >> >> Given that JWK Set URI's use the Web PKI to authenticate the JWKs they >> serve via HTTPS, it only seems natural we would use that very same >> system, the Web PKI, to authenticate JWKs directly. >> >> Thanks, >> Ethan >> >> >> On Tue, Jun 25, 2024 at 8:46 PM Kristina Yasuda >> <yasudakristina@gmail.com> wrote: >> > >> > Sorry to chime in late as well… >> > I support adoption of this draft. I have read the thread and to me it >> seems like there is a mechanism being proposed that solved a concrete >> problem in a simple manner. Some of the discussion can happen after the >> draft is adopted. >> > Best, >> > Kristina >> > >> > >> > On Wed, Jun 26, 2024 at 7:49 AM Joseph Salowey <joe@salowey.net> wrote: >> >> >> >> Sorry to chime in late here. I'm in favor of adopting this draft. >> While I realize that X.509 isn't for everyone, there is an established >> community of users out there that overlaps with OAUTH users. I think there >> are needs to both separate the distribution of the keys from the >> establishment of trust in those keys and in the auditability of the process >> of distribution. I think this draft establishes a deployable mechanism >> based on existing technology. X.509 is a good starting point and >> additional mechanisms can be added as needed. >> >> >> >> Cheers, >> >> >> >> Joe >> >> >> >> On Tue, Jun 25, 2024 at 3:12 PM Watson Ladd <watsonbladd@gmail.com> >> wrote: >> >>> >> >>> 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 >> >> >> >> _______________________________________________ >> >> OAuth mailing list -- oauth@ietf.org >> >> To unsubscribe send an email to oauth-leave@ietf.org >> > >> > _______________________________________________ >> > OAuth mailing list -- oauth@ietf.org >> > To unsubscribe send an email to oauth-leave@ietf.org >> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-leave@ietf.org >> > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org >
- [OAUTH-WG] Call for adoption - PIKA Rifaat Shekh-Yusef
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Rohan Mahy
- [OAUTH-WG] Re: Call for adoption - PIKA Rohan Mahy
- [OAUTH-WG] Re: Call for adoption - PIKA Rohan Mahy
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Watson Ladd
- [OAUTH-WG] Re: Call for adoption - PIKA Kristina Yasuda
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Rohan Mahy
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Michael Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Watson Ladd
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Rohan Mahy
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Rohan Mahy
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Watson Ladd
- [OAUTH-WG] Re: Call for adoption - PIKA Richard Barnes
- [OAUTH-WG] Re: Call for adoption - PIKA Joseph Salowey
- [OAUTH-WG] Re: Call for adoption - PIKA Ethan Heilman
- [OAUTH-WG] Re: Call for adoption - PIKA Giuseppe De Marco
- [OAUTH-WG] Re: Call for adoption - PIKA Pieter Kasselman
- [OAUTH-WG] Re: Call for adoption - PIKA James Carnegie
- [OAUTH-WG] Re: Call for adoption - PIKA Tom Jones
- [OAUTH-WG] Re: Call for adoption - PIKA John Bradley