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

[Richard Barnes <[e-mail]>]

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 <[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.
>
>
>
>                                                                 Thank you,
>
>                                                                 -- Mike
>
>
>
> *From:* Richard Barnes <[e-mail]>
> *Sent:* Tuesday, June 25, 2024 1:56 PM
> *To:* Rifaat Shekh-Yusef <[e-mail]>
> *Cc:* oauth <[e-mail]>
> *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 <
> [e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>