Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt

Daniel Fett <fett@danielfett.de> Thu, 07 May 2020 16:23 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 08A173A0AA0 for <oauth@ietfa.amsl.com>; Thu, 7 May 2020 09:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, 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 kElB56-gpK6K for <oauth@ietfa.amsl.com>; Thu, 7 May 2020 09:22:57 -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 3A6563A0A93 for <oauth@ietf.org>; Thu, 7 May 2020 09:22:57 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 28C8F26C2 for <oauth@ietf.org>; Thu, 7 May 2020 16:22:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588868573; 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=4yMML/IdeuOfLPPCF+pILDyi+6lL6YNFzMN7bE3tzOo=; b=diHekUAGIjeCFNgCyaMgwyXFJ5Esoy9K8aEY9sEnIayKIIPskn4QOKDpo4UbIYdF4CLvIn x6eXeNDNXVVvH8BnswUBy1WwP6meej4FW56+kGf4HwoRR5gDQlqYjYyF98MnfhRrOdnFPJ 5w7qylRbt7bsG04HYZvr08FgHa+axm8=
To: oauth@ietf.org
References: <158608868945.18323.557347538112056951@ietfa.amsl.com> <51f42eb9-9f6a-6fb1-e01e-2bba7688bcb9@free.fr> <a36b5a22-533a-6320-055b-d3f5af8f79cb@danielfett.de> <cb1a1af0-947d-3d6f-a280-c7579ad2494a@free.fr>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <18e38735-ae9f-c41b-0cda-b2818a1038dc@danielfett.de>
Date: Thu, 7 May 2020 18:22:52 +0200
MIME-Version: 1.0
In-Reply-To: <cb1a1af0-947d-3d6f-a280-c7579ad2494a@free.fr>
Content-Type: multipart/alternative; boundary="------------E3AF5DC2981EC9C2E7E838F1"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1588868573; 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=4yMML/IdeuOfLPPCF+pILDyi+6lL6YNFzMN7bE3tzOo=; b=Yir8l6y2HF0pWCVB9894u2ce7ULAcgY20cG1n3eVwLXHN55X0aOndZM/hgmjK0N6EuN9wq eChoge6yLIFeIayx1tiB90ahfTky4FV7T2zeHOB9h7g11YxfZfkow6saSKliEbAPnIfHg4 TWsjlWyWMpSnao9OVRlGQ9XVKRhW/lk=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1588868573; a=rsa-sha256; cv=none; b=MFTsseV0UDMos7uRurCIWzrHEK8iHDi/vBo8FDFm0o6/0zWn/4BOUXRjsCLKp/wEc1k5D9 DT9QtvLy4lX0LfsJf4PzT6k3RIqPLhO/eq/WMrD/d9KTgUwySa2pG4XUHML3/wsmsmxPiJ 03emVJRqeZlznRRuMSxAfyoM92f4rVk=
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/mPLXA_ZShQHXJLXnjbJMZKWL_LU>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-15.txt
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: Thu, 07 May 2020 16:23:00 -0000

Hi Denis,

Am 07.05.20 um 14:46 schrieb Denis:
> (...)
>
> A new definition for the term client should be adopted for this
> document.  However, you are right, the two wordings shall remain.
>
I cannot follow any of this, sorry.

>>>
>>> 3) The "_Updated _OAuth 2.0 Attacker Model" is supposed to have been
>>> "updated to account for the potentially _dynamic relationships
>>> involving multiple parties_".
>>> However, it still misses to address the case of _dynamic
>>> relationships between clients_, which include scenarios of
>>> _collaborative clients_.
>>>
>> That is not correct. Web attackers (A1) can participate in the
>> protocol as one or more users (resource owners) or clients. Of
>> course, these can collaborate between each other.
>>
> Section 3 states:
>
>    *OAuth MUST ensure that* the authorization of the resource owner
> (RO)  (with a user agent) at the authorization server (AS) and
>    the subsequent usage of the access token at the resource server
> (RS) *is protected _at least_ against the following attackers*:
>
>   *  (A1) *Web Attackers *(...)
>
> If a collaboration / collusion between clients were covered under this
> case, then it would mean that *OAUTH MUST provide a protection for it*,
> whereas this is technically impossible.
>
You are confusing the attacker model with the security goals (aka
security properties).

A commonly accepted security property for OAuth would be:

"An attacker should not be able to obtain access to or use a protected
resource protected by an uncompromised AS if that resource is only used
by an honest user with an uncompromised client and user agent."

(roughly equivalent to the one in
https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf)

Being resistant to collusion attacks is not a commonly accepted/expected
security property.

So: Yes, attackers are free to collude, and that is part of the model.
No, that is not a problem, as they are not breaking anything anyone
would expect.

-Daniel


> Since AOuth is unable to protect against a collusion attack between
> clients, the collusion attack cannot belong to this section, in
> particular under (A1).
>
> Section 3 is confusing the threat model with the resistance of OAuth
> to these threats.
>
> At this time, an RFC reader may not catch the fact that a collusion
> attack between clients may ever exist and thus may not
> grasp the fact that this kind of attack cannot be countered by OAuth,
> even when following the Best Practices.
>
> The "Updated OAuth 2.0 Attacker Model" does not take into "account for
> the potentially _dynamic relationships involving multiple parties_".
> as it is advertised, in particular the case of _dynamic relationships
> between clients_ which include the case of _collaborative clients_.
>
> The text currently does not  incorporate words like "collusion",
> "colluding", whereas it should. The text should clearly indicate that
> a protection against a collusion between clients is currently not
> possible using OAuth.
>
>>> Such a collaboration between clients is possible and should be
>>> considered in the "updated model".
>>>
>> This is considered in the model.
>
> See my comments above. While promised by the text, the case of
> collaborative clients is not considered in the model.
>
>>> which are human beings, it cannot be assumed that all the human
>>> beings in the world will necessary be honest. Whether or not Auth
>>> 2.0 is able or not
>>> to counter such an attack is another issue.
>>>
>> This as well. 
>
> As said above, the model should only express the threats (or the
> possible attacks) and another section should indicate which threats
> cannot countered. 
>
>>> In another section, it should be mentioned that OAuth 2.0 is unable
>>> to counter such an attack.
>>>
>> The problem is not that this type of collusion attack is not possible
>> under the model. The problem is it is not commonly expected that
>> OAuth protects against this type of attack.
>>
> RFC readers who have not followed or participated to this thread will
> not necessarily know that OAuth does not protect against this type of
> attack.
>
> The purpose of this document is to inform the reader about _all_ known
> types of attacks, whether they can be defeated or not by OAuth 2.0.
>
> Denis
>
>> -Daniel
>>
>>> Stating that such an attack is "out of the scope" of OAuth 2.0 would
>>> not be an appropriate statement.
>>>
>>> It should not be forgotten, that the purpose of this document is to
>>> inform the reader about _all_ the relevant security issues.
>>>
>>> Denis
>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>>>
>>>>         Title           : OAuth 2.0 Security Best Current Practice
>>>>         Authors         : Torsten Lodderstedt
>>>>                           John Bradley
>>>>                           Andrey Labunets
>>>>                           Daniel Fett
>>>> 	Filename        : draft-ietf-oauth-security-topics-15.txt
>>>> 	Pages           : 46
>>>> 	Date            : 2020-04-05
>>>>
>>>> Abstract:
>>>>    This document describes best current security practice for OAuth 2.0.
>>>>    It updates and extends the OAuth 2.0 Security Threat Model to
>>>>    incorporate practical experiences gathered since OAuth 2.0 was
>>>>    published and covers new threats relevant due to the broader
>>>>    application of OAuth 2.0.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-15
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-15
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>> _______________________________________________
>> 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