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

[Karsten Meyer zu Selhausen <[e-mail]>]

Hi Warren,

I think there is some misunderstanding on how mix-up attacks work. I 
will try to clear things up.

Have a look at the following mix-up attack example (slide 4 
<https://datatracker.ietf.org/meeting/interim-2020-oauth-17/materials/slides-interim-2020-oauth-17-sessa-as-issuer-identifier-in-authorization-response-00#page=4> 
from the interim meeting):

I marked the important parts:

  * In step 1 the client stores the attacker's AS (A-AS) as the selected
    AS.
  * Step 5: The authorization response is issued by the honest *(= not
    compromised)* AS, not by the attacker's AS. The H-AS will use its
    own correct issuer identifier as the value for the AS parameter.
      o In a mix-up attack the attacker cannot directly influence the
        value of the iss parameter in the authorization response as it
        is issued by the H-AS.
  * Step 6: The client sends the token request to the token endpoint of
    the A-AS, because it stored the A-AS as the selected AS in step 1.
    This leaks the authorization code to the attacker who can use it in
    a code injection attack, for example.

With an iss parameter present in step 5 the client would be able to 
recognize that the code was issued by the H-AS, not by the A-AS. The 
client would be able to abort the authorization grant instead of leaking 
the code to the A-AS.

I hope this addresses your concerns.

Best regards,
Karsten

On 08.12.2020 20:15, Warren Parad wrote:
> 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)
>  2. 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. 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.
>
> 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?
>
> 	
>
> 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/
>         <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
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
-- 
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training

Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:
https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz