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

Jim Willeke <jim@willeke.com> Wed, 09 December 2020 09:54 UTC

Return-Path: <jim@willeke.com>
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 B3D7F3A13BB for <oauth@ietfa.amsl.com>; Wed, 9 Dec 2020 01:54: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 (2048-bit key) header.d=willeke.com
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 S2HlOYeCkMlB for <oauth@ietfa.amsl.com>; Wed, 9 Dec 2020 01:54:54 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 897D13A13BE for <oauth@ietf.org>; Wed, 9 Dec 2020 01:54:53 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id r24so2243104lfm.8 for <oauth@ietf.org>; Wed, 09 Dec 2020 01:54:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vXm++qdEJ59uG79j9LyZwIZmsI6SRUAHbIQ57Mqzn04=; b=K8rh0fl7udyfDubjmfor6pMhBZOzUK7CjsWTr5LQwct0GFeMp4HOsHTVzW2nge5RM0 wMlmZRo0XItD6tLUHaBySuM4yFJ6iiRQ1w7Gb4HrMJqgSSGTG93WTuY7E36RhxXeo3lG E2I5QCwu/TGNkdxVb6exH4kPzQUzwRhIuCPXNLlbrNK6gLXiqA6ExBlW0+xE3idF46M2 fl35YFd8JZDg16TL8On38X9Ll1OdRROZOg/GsKnAIS1jP/Cn2h6R8dtmcuU46/JKomCV bYxx3SyRh1Iod5mtMOeSmUkLSjljYUzNLkEkQwkIrKc4N0U3u0jaHvjND7TmfA13wyM3 NmLg==
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; bh=vXm++qdEJ59uG79j9LyZwIZmsI6SRUAHbIQ57Mqzn04=; b=h3WRP1wBOWhhtaB0D1DieRX6BuqfT8etytF7217wPIGhCTFqEfvnWbOD3c4C9r0KB5 K/N6/BUIc8D1eo6sYthHDlaanyjf5qNX62CcBAr2DznzMnUnxPUhHBrqew736deNzAao NX+SCvDoWDpIUAcFQsGqW6avxty7L34rM6CX5dl4Y8l4g0ClmXd16hX4NLFYVeAFE8PZ ddFex93Ko/AzTQD2UYLRg42Slx+in1njHWbmz1RRtJ68adXLHSlMjoi0ZJMQEEsa5not 7+KkA4Gkb7dnMpEaYMtdM4yvULjGrgM8+MLIONSAhsOBmeRpdVAf23WAEY/JhogoXHhJ Dh7g==
X-Gm-Message-State: AOAM533qS+WmMd8ZAmn+bkIQzwFrA05YoWcNzrzgLkrVNXYyGPXo/NQM Bp6WEM5B+RSp6ssHx4Fb0zRc/4JH1cK/e99FvOE+BFXyZtbXvQ==
X-Google-Smtp-Source: ABdhPJzs4pd5RNFS+5wNwttD5YUH4BJN2MEnUXCxwK+LCTpv+Aykw0G835lk2ydEiXrwUsMnZXQRdFn7m9uKxm2x4HA=
X-Received: by 2002:a19:4ad8:: with SMTP id x207mr799650lfa.9.1607507690057; Wed, 09 Dec 2020 01:54:50 -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> <CAJot-L2FrMrxBGATVHd1DVwbqyMGoH7Dy1stP46vUVpEWrq21Q@mail.gmail.com>
In-Reply-To: <CAJot-L2FrMrxBGATVHd1DVwbqyMGoH7Dy1stP46vUVpEWrq21Q@mail.gmail.com>
From: Jim Willeke <jim@willeke.com>
Date: Wed, 9 Dec 2020 04:54:13 -0500
Message-ID: <CAB3ntOsWCyB9YY6WNh5nmyKcYz3Tgs=FSytbnuJmjfdXcQppqw@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/related; boundary="000000000000d7587e05b6050c86"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1nf1j48gmX7RMo1ZKUnXMGsEc-U>
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:54:58 -0000

I support the adoption of AS Issuer Identifier in Authorization Response.
--
-jim
Jim Willeke


On Wed, Dec 9, 2020 at 4:48 AM Warren Parad <wparad@rhosys.ch> 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 <
> 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
>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>