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

[Joseph Salowey <[e-mail]>]

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]
>