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

Warren Parad <wparad@rhosys.ch> Wed, 09 December 2020 09:47 UTC

Return-Path: <wparad@rhosys.ch>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446073A123F for <oauth@ietfa.amsl.com>; Wed, 9 Dec 2020 01:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJwL2XbIY3cI for <oauth@ietfa.amsl.com>; Wed, 9 Dec 2020 01:47:55 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12693A1236 for <oauth@ietf.org>; Wed, 9 Dec 2020 01:47:54 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id i9so1010670ioo.2 for <oauth@ietf.org>; Wed, 09 Dec 2020 01:47:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=npS/GM5biE3jBFdu8so+nPOX0XVNm0TjeFL2Ilc+j5g=; b=wWTDrcZHSA2khfzY+vj40dhOJi8lZdC9tkbkfPSCgY+/Fk86b5pjksSlDv6TDQvt6W /vohIYo+SaoFMGyTjBKibZZsWXKJwnIdOOqvp3lISzr/7IOzEsMKLnpoI/8t4zu3NPBF gn4rn3RuWVrWkQjkutjj8EhaK/z/xjjB6Z2/U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=npS/GM5biE3jBFdu8so+nPOX0XVNm0TjeFL2Ilc+j5g=; b=KUX9svtrSyIP8XxWYcwfIzMtskSvCjsTfSCr81itina3YMU5/mMrfKdO5DDZJ0ugUA 9I6z/WMSynt0yGFUpycIDb6lPWX7oV1poDIROL5Nyuw7DdQRRLjUToJ4XG2TYbWq/C7C mhhJNwAFoms5enHHuJKJ1IxiGCcPGJ5uVUlKlx9g+M82Vf6onAKxI5oOEbFlKXcrXKF3 /mOpxioA5XNE7B2GEgnWc/aftA+SrwcbbiMTUyTi6hB8XSPDUfpP2cHBLtJMo6tX3OmR 2giDGZ4M8eRqt0qNoPjI4qKClrj/LwYIkSMq7JNaTK8A2zaMnAAb8GJcCeOJcrTeu2oQ xw/Q==
X-Gm-Message-State: AOAM531JJBvxpZcmegR213cW9GKpiTgSxv8lrjj2nMhSr2v1ufXTmFin xCaS80zwO/hNzrmJzfonL5v8OgTvPgFoiTmqChc3
X-Google-Smtp-Source: ABdhPJxx7zOXBTQkPPNE3O+Jqr1otK3a2AJMlWV8rD1TmqNvR8EPwQidONnEUBmEjGgrPEIss3CYEEHwypakO3XEmfA=
X-Received: by 2002:a5e:c609:: with SMTP id f9mr1741567iok.41.1607507273382; Wed, 09 Dec 2020 01:47:53 -0800 (PST)
MIME-Version: 1.0
References: <CADNypP9D1G94LuPcgczSVYL+0KyMYoAK_s3H4JZK80Bj2mJKtA@mail.gmail.com> <CAD9ie-t7OroYwPrTQtwTS3Reem9bM5PHcVZ7D_N=jSmd6O7UGw@mail.gmail.com> <CAJot-L1-dYLy_m_WZv=bEC=r0zWSdKNXBMOV6b9SD8VR-dZvJg@mail.gmail.com> <09d3639d-7d7e-9582-d728-cc223d21bcb6@hackmanit.de>
In-Reply-To: <09d3639d-7d7e-9582-d728-cc223d21bcb6@hackmanit.de>
From: Warren Parad <wparad@rhosys.ch>
Date: Wed, 9 Dec 2020 10:47:35 +0100
Message-ID: <CAJot-L2FrMrxBGATVHd1DVwbqyMGoH7Dy1stP46vUVpEWrq21Q@mail.gmail.com>
To: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
Cc: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>, oauth <oauth@ietf.org>
Content-Type: multipart/related; boundary="00000000000003473905b604f47d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Pw0W90TMMhT6_9T2dvn8QQfiDwY>
Subject: Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 09:47:57 -0000

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 <
karsten.meyerzuselhausen@hackmanit.de> 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 <dick.hardt@gmail.com> wrote:
>
>> +1
>> ᐧ
>>
>> On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef <
>> rifaat.s.ietf@gmail.com> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> 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
>
>