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

[Kristina Yasuda <[e-mail]>]

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