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

[Giuseppe De Marco <[e-mail]>]

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 <[e-mail]>
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
> <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> wrote:
> >>>
> >>> On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
> >>> <[e-mail]> 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 -- [e-mail]
> >>> To unsubscribe send an email to [e-mail]
> >>
> >> _______________________________________________
> >> OAuth mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >
> > _______________________________________________
> > OAuth mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>