Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

Daniel Fett <fett@danielfett.de> Fri, 08 November 2019 14:30 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 44586120807 for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 06:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 E-x0XrusooKP for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 06:30:07 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC7012008C for <oauth@ietf.org>; Fri, 8 Nov 2019 06:30:06 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id AEEEB21600 for <oauth@ietf.org>; Fri, 8 Nov 2019 14:30:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1573223403; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zy1yDmbnsWcIswebQRR1ufVSiyVNUcN8R56zjVgAsDs=; b=MPH11ftLTWPOK17S4YIMXE43F1os9Hexlcoyx+ga371JVb4HjF0k/KY2xRk3VhQisk7uP/ 3Qo3nyAMPiVOPyGDvN3hu2HKKpAkEjGe4GlsRC6IH7XWm28ECxdUZ3jKa3imflY1bKhSsu NQ2sbdV0IhC02pS1e9O3B3WSV5snFvw=
To: oauth@ietf.org
References: <VI1PR08MB5360FBBAF0D3A38BDBED618BFA790@VI1PR08MB5360.eurprd08.prod.outlook.com> <CAMVRk++o2MdndK37FfADzEZJx988o=PvPWN_mhdgDK=OU1dtow@mail.gmail.com> <3ECDBBC5-F183-4227-857A-A95C53C74274@mit.edu> <d021c84a-36f3-f371-2903-2b6051ee654f@free.fr> <8324a1d3-2fe8-430c-facc-1f3c5d7db260@danielfett.de> <21a36a19-1f24-25d9-9478-1e282a1bea19@free.fr> <CA+iA6uhqVf9B2VxzS7cFx_ATSymB9gsAk0ebpjdv99ymW6RjXA@mail.gmail.com> <ff668a74-52f9-3ac9-acf0-ad3e27e98ea9@free.fr>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <9927a0d5-6202-3375-4ff3-2ee510beb814@danielfett.de>
Date: Fri, 8 Nov 2019 15:30:02 +0100
MIME-Version: 1.0
In-Reply-To: <ff668a74-52f9-3ac9-acf0-ad3e27e98ea9@free.fr>
Content-Type: multipart/alternative; boundary="------------F5A6A3B163F63804E825A631"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1573223404; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zy1yDmbnsWcIswebQRR1ufVSiyVNUcN8R56zjVgAsDs=; b=QCYumfmEr03mOm0VE+V7ekNktER4MMs665PBh4TeaonfM7fIq+1CnucEwU7Cu72raNOLni rkPXJRsXsRj68TphcOJDHUbD5E4jG807+DJW1akybTz61plAKFNWqd5AysPdjzKMQfAefk 6wYZmBYY/TfMaSRe4rx81dHZJDtDk/4=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1573223404; a=rsa-sha256; cv=none; b=VJupvm92kFgjx3UXXdIm8SL/VHEuMpJ2L5ovQnHFS5z1B7i7S2+KpAMvRlGvJJWjrH6WS+g1WjanVHGeOiEfU9l3qw6/rjr1d8BTvcgz0+td0Fib/Mqp9+cmyCGHVopfz4YrInp1wvFuHueFAlRR6+HNY8VlPLTvglrqj8/AjS8=
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/32rm5_94P6welBeG0IyHgxXJNLg>
Subject: Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
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: Fri, 08 Nov 2019 14:30:09 -0000

I have the feeling that this attack aims at breaking a security property
that OAuth does not claim to fulfill (and that nobody expects OAuth to
fulfill):

"Given two colluding clients A and B, where A has obtained an access
token T, B cannot use T to access protected resources."
(analogously for two users U_A and U_B of the clients, where the users
have some session with a backend client.)

And there are good reasons why this is not captured by the security
property (Hans' screenshot, for example).

As far as I know, this property is neither achieved by classical
first-party session-based authentication/authorization nor by any other
web-based mechanism, or is it?

-Daniel

Am 08.11.19 um 14:13 schrieb Denis:
> Hello Hans,
>
> You wrote:
>
>> one client can always share the protected data with another client
>> once retrieved, regardless of pop or secure elements
>
> No, there exist means that prevent a client to share the protected
> data with another client , simply because the client cannot access to it.
> The protected data is placed inside the secure element and thus a
> client has no way to extract it for the benefit of another client.
>
> The protected data is used by the secure element in such a way so that
> it cannot be used for the benefit of another user.
>
> But we are already in the field of the solutions and no more in the
> field of the requirements.
>
> Denis
>
>>
>> Hans.
>>
>> On Fri, Nov 8, 2019 at 8:38 AM Denis <denis.ietf@free.fr
>> <mailto:denis.ietf@free.fr>> wrote:
>>
>>     Daniel,
>>
>>     No. It is not a correct summary. One client can allow another
>>     client to get an access token that belongs to it.
>>     The key point is that a software only solution can't prevent this
>>     collaborative attack and since, at this time,
>>     the OAuth WG is not considering the use of secure elements, the
>>     attack cannot be countered.
>>
>>     Please have a look at:
>>     https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html
>>
>>     Denis
>>      
>>>     Hi Denis,
>>>
>>>     Am 07.11.19 um 09:16 schrieb Denis:
>>>>
>>>>            *Whatever kind of cryptographic is being used, when two
>>>>     users collaborate, a software-only solution will be unable to
>>>>     prevent the transmission *
>>>>     *       of an attribute of a user that possess it to another
>>>>     user that does not possess it. *
>>>>
>>>     To stay in OAuth lingo, what you are saying is: Two
>>>     collaborating clients can exchange their access tokens and use them.
>>>
>>>     Is that a correct summary of your attack?
>>>
>>>     -Daniel
>>>
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> -- 
>> hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth