Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

Daniel Fett <fett@danielfett.de> Mon, 12 April 2021 12:36 UTC

Return-Path: <fett@danielfett.de>
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 63F7C3A1BFE for <oauth@ietfa.amsl.com>; Mon, 12 Apr 2021 05:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
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 W4LBbqZWbnVZ for <oauth@ietfa.amsl.com>; Mon, 12 Apr 2021 05:36:18 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B583A1C04 for <oauth@ietf.org>; Mon, 12 Apr 2021 05:36:18 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 1EEBC2465B for <oauth@ietf.org>; Mon, 12 Apr 2021 12:36:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618230975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wrR6XICKPuOFk/u6+QfGFIJ9xP2WcupWCaNqcsh1FJI=; b=A95IZMu8B5oIlBbsNlh9RowscRyXosymjkzUyLs9L6Y5BktZLO3qVk8nQkQISF28tDYD2G DLlCteitnXyZgloFS9knKoLfG09gLosMoBCtLXfWonxJvbSzK4/xs667qnOsCvz9BbCdYd 03ebFutXQx0z65zmvMsbGWGsNGM4XQM=
To: oauth@ietf.org
References: <CADNypP80KicBYDjOHkZQMrowM1WgrtpCr1Ywt88RrTRbZ_Ctrw@mail.gmail.com> <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de>
Date: Mon, 12 Apr 2021 14:36:14 +0200
MIME-Version: 1.0
In-Reply-To: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr>
Content-Type: multipart/alternative; boundary="------------1F800BD78CD29C1F6E7EC52D"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1618230975; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wrR6XICKPuOFk/u6+QfGFIJ9xP2WcupWCaNqcsh1FJI=; b=axBICptaGq9VMpIr2z/Ftz0jEOnCWyj31niFkY0Syh9jOBii/CshPcylTiSjMLpWHXXlyH dkCrKoxQZlbzZdjf09ilTBHkVJo1VnXLilQqkX9xmNgbpfCxNm0yJ54O7Kp81MKkMGHek6 v+4rMJY9igCbbImOqIPCwr9ygaA8bJQ=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1618230975; a=rsa-sha256; cv=none; b=ZREf5+sd9ixSDMNJgPqxKFltLd4cYXkkKM/G09Cf3vQZCLw6/NzHALe/A9As2QvfyzV4BT k1HF+k31QMy9x/TTLRdZyknQUKZL5vyzyB2VWcdajnW25UfGNG/068wperkKJWLUPPkE3p b68NtpVqVyGzggdkCe75fEMV6/bEPzU=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: --
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9mQxmfMz-kolz0tTYcMr8df4kTY>
Subject: Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP
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: Mon, 12 Apr 2021 12:36:23 -0000

Denis,

I was awaiting your mail and I admire your perseverence with bringing
this topic to our attention.

To your points:

Am 12.04.21 um 13:36 schrieb Denis:
> The case where two clients collude to mount an attack against a RS is
> not addressed. It now needs to be addressed.
>
>
> This should be added in section 1 ( Introduction)
>
No.


> The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model)
> clearly states:
>
>     " In the following, this attacker model is updated (...) to
> include new types of attackers and to define the attacker model more
> clearly".
>
> Section 3 should include the case of a collusion or a collaboration
> attack between clients against a RS, where one of them is a legitimate
> client
> voluntarily "helping" another client to use or to request access
> tokens that would normally "belong" to the legitimate client.
>

As I'm sure you have noticed, we have updated Section 3 following your
last input. It now explicitly says:

    Attackers can collaborate to reach a common goal.

It also says

   Note that in this attacker model, an attacker (see A1) can be a RO or
   act as one.  For example, an attacker can use his own browser to
   replay tokens or authorization codes obtained by any of the attacks
   described above at the client or RS.

Your scenario is therefore covered. It was already before, but that was
obviously too implicit, so we made it more clear with the recent update.

>
> Finally, section 4 (Attacks and Mitigations) should include an
> additional subsection, e.g. section 4.16, addressing the case of a
> collaboration attack
> between clients against a RS.
>
If I remember correctly, you first presented this attack at the OAuth
Security Workshop in 2017. Since then, it has been brought up countless
times on this mailing list, both with regards to the Security BCP as
well as for the JWT Token draft.

There has been practically no positive resonance at the meeting 2017 or
here on the mailing list as to including this in either of the drafts.

A number of reasons come to mind, but first and foremost, I think that
what you describe is not perceived as an attack, or, worded differently,
it is obvious that what you describe in the "attack" is possible. There
is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in
password-based authentication. Even though the Security BCP attacker
model includes the general setting required for the attack, the attack
does not violate an expected security property.

I therefore propose to proceed with the Security BCP without including
this attack.

-Daniel


-- 
https://danielfett.de