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.i...@free.fr >> <mailto:denis.i...@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.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> >> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu> > > > > _______________________________________________ > 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
