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<mailto: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<mailto:oauth@ietf.org>
To unsubscribe send an email to
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
