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

Denis <denis.ietf@free.fr> Fri, 08 November 2019 13:13 UTC

Return-Path: <denis.ietf@free.fr>
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 5FD7A120133 for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 05:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 L7xyr0ZI3nxr for <oauth@ietfa.amsl.com>; Fri, 8 Nov 2019 05:13:48 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28B0120125 for <oauth@ietf.org>; Fri, 8 Nov 2019 05:13:47 -0800 (PST)
Received: from [192.168.1.11] ([90.79.49.31]) by mwinf5d07 with ME id PRDk210030gNo7u03RDks5; Fri, 08 Nov 2019 14:13:45 +0100
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 08 Nov 2019 14:13:45 +0100
X-ME-IP: 90.79.49.31
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Cc: "oauth@ietf.org" <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>
From: Denis <denis.ietf@free.fr>
Message-ID: <ff668a74-52f9-3ac9-acf0-ad3e27e98ea9@free.fr>
Date: Fri, 8 Nov 2019 14:13:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CA+iA6uhqVf9B2VxzS7cFx_ATSymB9gsAk0ebpjdv99ymW6RjXA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------C07DB0AA502FF4F249FE20DD"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/s8FuRLQgy0S7FNQAIBIXJUdF6mY>
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 13:13:50 -0000

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>