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
