Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

[Daniel Fett <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     +1
>     ᐧ
>
>     On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef
>     <[e-mail] <mailto:[e-mail]>> 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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de