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 <demarco...@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 <eth...@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 >> <yasudakrist...@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 <j...@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 <watsonbl...@gmail.com> >> wrote: >> >>> >> >>> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones >> >>> <michael_b_jo...@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-le...@ietf.org >> >> >> >> _______________________________________________ >> >> OAuth mailing list -- oauth@ietf.org >> >> To unsubscribe send an email to oauth-le...@ietf.org >> > >> > _______________________________________________ >> > OAuth mailing list -- oauth@ietf.org >> > To unsubscribe send an email to oauth-le...@ietf.org >> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
