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 <watsonbl...@gmail.com> wrote: > 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
