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

[Denis <[e-mail]>]

Daniel,

> 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):

The first comment sent to the list was to ask whether the list of 
attacks was complete. IMO, the list should not be limited to the attacks 
that can be mitigated
using best current practices, but should include all /known /kinds of 
attacks.

At the moment a reader might get the impression that all /known /types 
of attacks have been analyzed and considered.

The document even refers to formal methods (which might impress some 
readers), but when looking at the perimeter of the model that has been 
used,
it is obvious that the ABC attack could not be discovered and thus 
considered.

> "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?

Please refer back to what I said, i.e."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"and you will get the response. Since OAuth 
is a software based solution,
it is unable to counter clients collusion attacks. Adding a secure 
element to only protect private/secret keys is ineffective to counter 
clients collusion attacks.

For potential implementers, it is important to know the limitations of a 
protocol before implementing it.

Denis

> -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 <[e-mail] 
>>> <mailto:[e-mail]>> 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
>>>>     [e-mail]  <mailto:[e-mail]>
>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> -- 
>>> [e-mail] <mailto:[e-mail]>
>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth