OpenID Discovery already allows this attack. Its security relies on HTTPS, which only authenticates the domain name. So the owner of a domain can present a valid discovery document with arbitrary information in it for any issuer path on the domain.
Do you have the same concern with that mechanism? On Tue, Jun 25, 2024 at 5:53 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. > > > > Thank you, > > -- Mike > > > > *From:* Richard Barnes <r...@ipv.sx> > *Sent:* Tuesday, June 25, 2024 1:56 PM > *To:* Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> > *Cc:* oauth <oauth@ietf.org> > *Subject:* [OAUTH-WG] Re: Call for adoption - PIKA > > > > Hi all, > > > > Replying to the top of the thread again to recap the arguments so far. > (Hoping the chairs will give us a moment more to discuss before calling > cloture.) > > > > It seems like Sharon, Rohan, Watson, and I are all on the same page w.r.t. > the X.509-based mechanisms in the current draft. In particular, we're all > developers of relying party software, and it seems like we're all OK with > doing X.509 (contra Mike's point about application-level X.509). > > > > If I understand Mike and Giuseppe correctly, they want to be less > prescriptive about how the PIKA signer establishes their authority for an > "iss" value, so that an OP could use some other mechanism (e.g., OpenID > Federation). It sounds like Mike at least is OK with the draft aside from > this point. > > > > I would be open to adding some optionality in the authority mechanism > here, but I'm wary of losing the concrete interop that we get with the > draft as it is. So we would need at least a strong recommendation for > X.509, even if something else can be used if the parties agree to it. I > would be more comfortable doing something along the lines of what Rohan > suggests, namely defining a concrete, X.509-based thing here, and extending > it to support other mechanisms via follow-on specs as needed. If there > were a single additional mechanism that people wanted, as opposed to a > generic "[insert authority mechanism here]", that would also be more > palatable to me. > > > > Additional feedback would be useful on a couple of points: > > > > 1. From RPs: Is the X.509 requirement onerous to you? Or is there enough > library support out there that it's not a big deal? > > 2. From OPs: Is signing using a key bound to an X.509 certificate workable > for you? Or do you need some other authority framework? > > 3. From everyone: Is the general mechanism here useful, assuming we can > align on some set of authority frameworks? > > > > Thanks, > > --Richard > > > > > > On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > > All, > > This is an official call for adoption for the *Proof of Issuer Key > Authority (PIKA)* draft: > > https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/ > > > Please, reply *on the mailing list* and let us know if you are in favor > or against adopting this draft as WG document, by *June 24th*. > > Regards, > Rifaat & Hannes > > > > _______________________________________________ > 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
