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

[Warren Parad <[e-mail]>]

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