> 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.
In large deployments, like an entire national public service domain or multinational organization, using the model you propose may represent a security issue because, behind the proxy, the services/endpoint are supposed to be not secured at the application level Threats like rogue emploies or adversaries taking control of the proxy, might take control of all the endpoints behaviour, while the additional application security layer would keep this out of the control of who controls the proxy When we mention a trust that scales I also think about these distinct layers enforcing the security of each single endpoint Il mer 26 giu 2024, 00:12 Watson Ladd <watsonbl...@gmail.com> ha scritto: > 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
