Subject: Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure

From: Christian Mainka <[email-masked]>
Date: Mon, 2 Dec 2019 10:05:08 +0100

Hi Daniel,

I think this problem is not only restricted to the redirect_uri.
Regarding countermeasure (1), also the A-AS can return the same
client_id as the client uses on the H-AS.

TL;DR: In countermeasure (1), only the issuer prevents MixUp, the
client_id parameter can be faked as well during the registration of the
client (especially if Dynamic Client Registration is used).

Regards
Christian

On 26.11.19 15:20, Daniel Fett wrote:
> Hi Karsten,
>
> Very interesting observation!
>
> My gut feeling is that this is the real problem here:
>
> Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen:
>> Depending on its implementation the client might simply extract all data
>> contained in the Client Information Response and use it for
>> authorizations with the specific AS.
>> We were able to confirm that one popular open-source library behaves in
>> this exact way. It stores the redirect URI contained in the Client
>> Information Response and uses it for Authorization Requests with the
>> A-AS although it differs from the redirect URI in the Client
>> Registration Request.
> The client uses untrusted, unverified data to make its decision on what
> redirect URI to use.
>
> Nonetheless, we should definitely mention this in the BCP!
>
>> In our opinion this makes the countermeasure "AS-specific redirect URIs"
>> obsolete and we believe the other countermeasure described in the BCP
>> (adding an AS identifier and the client_id of the intended recipient to
>> AS's responses) should be used to prevent Mix-Up attacks. If the
>> involved entities use the OIDC hybrid flow this countermeasure is
>> automatically applied.
> These are more intrusive changes than the per-AS redirect URI and may
> require new parameters.
>
> Daniel
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security 
Chair for Network and Data Security 
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX

---

From: Daniel Fett <[email-masked]>
Date: Mon, 2 Dec 2019 11:26:19 +0100

> client (especially if Dynamic Client Registration is used).

What would be the issuer identifiers of A-AS and H-AS in this case be,
as seen by the client?

-Daniel

---

From: Christian Mainka <[email-masked]>
Date: Tue, 3 Dec 2019 10:21:56 +0100

Hi,

according to [1], countermeasure (1) describes to

> configure [the] authorization servers to return an AS identitifier
("iss") and the "client_id" for which a code or token was issued in the
authorization response.

So if an MixUp attack is running, the victim contacts A-AS but is
redirected to to H-AS [2].
The AS adds - according to the countermeasure - two additional
parameters to the authorization response: client_id and issuer. Both
values are set by H-AS, so it returns H-issuer and H-client_id.

But: during the registration of the client on A-AS (rfc7591), it can return:

HTTP/1.1 201 Created

     {
      "client_id": "H-client_id",
      "redirect_uris": [
        "https://client.example.org/honest-callback",
     }

So if the client receives the client_id in the authorization response,
it is unable to distinguish to which AS the client_id belongs to - they
have the same values.

This does not hold for the issuer parameter in the authorization
response, because it is set by H-AS and independent of and not set
during the Dynamic Client Registration Protocol.

So basically, it is the same problem as with the redirect_uri.

Regards
Christian

[1]:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.4.2
[2]: Step 4 in
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.4.1

---

From: Daniel Fett <[email-masked]>
Date: Tue, 3 Dec 2019 10:49:54 +0100

> values are set by H-AS, so it returns H-issuer and H-client_id.

I asked for clarification because I would assume that the mix-up attack
is twharted at this point. The client would see H-issuer instead of
A-issuer, to which it sent the user.

I agree that the client_id is not of much value here.

-Daniel

---

From: Brian Campbell <[email-masked]>
Date: Tue, 3 Dec 2019 11:46:41 -0700

> Nonetheless, we should definitely mention this in the BCP!

RFC 7591 basically says that the AS can replace/substitute/augment any of
the client registration info and leaves it up to the client as to how to
handle differences from what was requested. There are quite a few things
that just wouldn't make sense for the AS to change and some like redirect
URI that could potentially be dangerous.  Perhaps the BCP should mention
the situation and recommend that a client not proceed if the redirect URIs
(and others?) don't align with what was requested.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Daniel Fett <[email-masked]>
Date: Wed, 4 Dec 2019 16:19:04 +0100

Am 03.12.19 um 10:49 schrieb Daniel Fett:
> I asked for clarification because I would assume that the mix-up
> attack is twharted at this point. The client would see H-issuer
> instead of A-issuer, to which it sent the user.
>
Looking back at our analysis of OIDC [1], we actually included the
option that attacker choses the client_id, even for the honest AS. This
is a safe overapproximation, of course. Obviously an attacker-controlled
AS can also issue arbitrary client_ids. So I suspect that there is no
further attack hidden here.

[1] https://arxiv.org/pdf/1704.08539

-Daniel