Hi Warren, Am 08.12.20 um 20:15 schrieb Warren Parad: > As an implementer on both sides of the issue I'm struggling to > understand how this problem would occur. I'm finding issues with the > proposed problems: > > 1. Honest AS is compromised, assuming this does happen details on why > adding iss to the AS response would prevent attacks is necessary > for me. In other words, how would an AS be compromised in a way > that would be identifiable through the issuer value? (my ignorant > assumption is that a compromised AS is compromised enough that an > attacker would be able to send the correct ISS) > If an AS is compromised, we can't do much for it anyway. We must assume that all credentials from this AS can be stolen or forged and that resource servers relying on this AS have a big problem, too. The Mix-Up Attack is about attacking *other* (uncompromised) AS using the client's trust in the compromised AS.
For clarification, in our slides we refer to - an uncompromised AS as H-AS (honest AS) - this is the AS which issues the credentials the attacker wants to read, and - a compromised AS as A-AS - this may have been uncompromised previously or may have been introduced into the ecosystem for the sole purpose of running the mix-up attack. In the mix-up attack, the client assumes that it is talking to A-AS but actually received the authorization response from H-AS. This is why the iss parameter helps: It always comes from H-AS (together with the authorization code) and therefore cannot be modified by the attacker. (If the attacker would be able to intercept/tamper with this communiction, there would be no need to run a mix-up attack in the first place.) > 1. Attacker AS is registered. I fully support the idea that this can > and will happen, however from attempting to test-implement this > proposal, I can't see how the authorization would be sent to the > wrong token endpoint. Since there is no information in the AS auth > code response, the client must already have the knowledge of where > they are going to send the token, no mix-up can be executed. > The assumption in the mix-up attack is that the client stores where to send the authorization code, for example in a session bound to the resource owner's browser. This would always be the token endpoint of the attacker (A-AS) in the mix-up attack, either because the user selected A-AS as the AS or because the attacker had an opportunity to modify the user's choice. > > 1. I would argue, if anything, adding the ISS parameter would open a > new attack surface by providing clients an opportunity to > blatantly trust the ISS parameter as the honest AS and thus > actually sending the code there instead of sending it to one > specified in the metadata document. > As far as I can see, the potential attacks from such a bug on the client's side would not be worse than mix-up, at least. It would undermine session integrity probably, in that an attacker-AS would be able to steer the client to send the code to H-AS. I'll take a closer look at this. > My confusion is the following: > > * Are multi AS services utilizing authorization codes in a way where > there could be a mix up attack for #2. > * Is there a #3 that I'm missing which even in light of #1 & #2 I > brought up that would still make this change valuable? > I'm not sure if I could help to clear up the confusion a bit. I'd recommend that you take a look at Section 3.3.2. of this document [1] which provides a more detailed description of the mix-up attack and why the defense mechanism works. -Daniel [1] https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf > > > Warren Parad > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress <https://bit.ly/37SSO1p>. > > > On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt <dick.ha...@gmail.com > <mailto:dick.ha...@gmail.com>> wrote: > > +1 > ᐧ > > On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef > <rifaat.s.i...@gmail.com <mailto:rifaat.s.i...@gmail.com>> wrote: > > All, > > This is a call for adoption for the following AS Issuer > Identifier in Authorization Response as a WG document: > > https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ > > Please, provide your feedback on the mailing list by Dec 22nd. > > Regards, > Rifaat & Hannes > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
