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

[Daniel Fett <[e-mail]>]

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 <[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