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 <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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
