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

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

The attacker being able to manipulate the first request is an additional 
precondition for the mix-up attack variant we used as an example. The 
precondition is based on the attacker A2 defined in section 3 
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-3> 
of the security BCP.

There are other mix-up variants which work without this precondition. 
One variant is described in the security BCP 
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.4.1>, 
for example:

> *Mix-Up Without Interception*: A variant of the above attack works
>        even if the first request/response pair cannot be intercepted, for
>        example, because TLS is used to protect these messages: Here, it
>        is assumed that the user wants to start the grant using A-AS (and
>        not H-AS, see Attacker A1).  After the client redirected the user
>        to the authorization endpoint at A-AS, the attacker immediately
>        redirects the user to H-AS (changing the client ID to "7ZGZldHQ").
>        Note that a vigilant user might at this point detect that she
>        intended to use A-AS instead of H-AS.


On 09.12.2020 10:47, Warren Parad wrote:
> Okay, it wasn't clear that the user agent was required to be 
> compromised for this to be a problem. Here's where it breaks down for 
> me, if the attacker can manipulate the first request, why would they 
> not be able to manipulate the AS where the Auth Response code is 
> sent?  Unless we can guarantee there is an attack surface that would 
> only affect the authorization request AS selection and not the auth 
> response, the solution the draft lacks purpose for me.
>
> 	
>
> Warren Parad
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture. 
> Implement Authress <https://bit.ly/37SSO1p>.
>
>
> On Wed, Dec 9, 2020 at 8:55 AM Karsten Meyer zu Selhausen 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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  <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  <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
>
-- 
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