Hi Daniel,
Rather than answering between the lines, I place a global answer in
front of your message.
Depending upon the content of the JWT, two different collaborative
attacks need to be considered,
one of them being an impersonation attack which can indeed be performed
using Teamviewer.
The other one, i.e. when the JWT does not contain a set of attributes
that is sufficient to identify an individual,
is not and cannot be performed using Teamviewer because it does not deal
with impersonation.
Let us consider a scenario to illustrate this second case.
Alice is Client A while Bob is Client B.
Alice and Bob have both opened an account on a web server allowing to
make reservations on tennis courts managed by the town of Utopia.
Bob is a resident from Utopia, but Alice is not. Residents from Utopia
are allowed to perform tennis courts reservations two weeks in advance
while other people can only perform them 48 hours in advance.
An Attribute Server (AS) managed by the town of Utopia is able to
provide a JWT stating that the holder is indeed a resident of Utopia
(there are about 50.000 residents). The holder can use such a JWT for
different web sites: library, swimming pool, tennis, ... The web servers
trusting the AS from the town of Utopia ask to present such a JWT once a
year which may allow to get some advantages during one year.
Bob has already presented such a JWT at the beginning of the year, thus
he can enjoy making tennis courts reservations two weeks in advance.
Alice is annoyed since most of the time 48 hours ahead, most tennis
courts are already reserved. So she asks Bob whether he would accept
to request a new JWT token stating that the holder is indeed a resident
of Utopia. Let us assume that Bob accepts.
When Alice connects to the server, she also ask Bob to connect to the AS
and to provide her with the JWT and to stay online to perform
all the cryptographic computations she will need to present this JWT to
the tennis courts web server. For doing this, they both use
a specific piece of software developed for this purpose.
When this is done, during one year, Alice will enjoy to make tennis
reservations two weeks in advance. At this end of these 12 months,
she will ask Bob to collaborate again.
In this scenario, unless the AS and the RS collaborate, nobody will know
that Alice and Bob collaborated.
You wrote:
We discussed these kinds of collusion attacks at great length previously
on this list. My views on them have not changed.
You are not saying in this email what your views are. However, I browsed
through the last exchanged emails.
On November 8, 2019, under the thread "WGLC for "OAuth 2.0 Security Best
Current Practice", you wrote:
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):
(...)
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?
I responded to this email:
*
Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
*Denis <denis.i...@free.fr> Tue, 12 November 2019 09:19 UTC
https://mailarchive.ietf.org/arch/msg/oauth/Gc8T8mRkF5vJT7fV3uSc66B_9Fs/
However, you never responded to it. Up to now, I don't know what "Hans'
screenshot" was and I don't know the "good reasons
why this is not captured by the security property".
On November 13, I sent an email to the list and to Brian:
*
Re: [OAUTH-WG] Fwd: New Version Notification for
draft-fett-oauth-dpop-03.txt
*Denis <denis.i...@free.fr> Wed, 13 November 2019 09:17 UTC
https://mailarchive.ietf.org/arch/msg/oauth/WC8jCC-U3bAhlBHEVRLAdSOuY98/
At the end, I wrote:
DPoP is not able to counter collusion attacks between clients and
this should be clearly advertised in the abstract, in the main
objectives (section 2)
and in the security considerations (section 9).
You have not participated to this thread. However, DPoP is still silent
about this kind of attack.
RFC 3552 (Security Considerations Guidelines) states in its Introduction :
"All RFCs are required by RFC 2223 to contain a Security
Considerations section.The purpose of this is both
to encourage document authors to consider security in their
designs and to _inform the reader of relevant security issues_".
draft-fett-oauth-dpop does not comply with RFC 3552 but it should.
Denis
P.S. It is possible to counter the Alice and Bob collusion attack (ABC
attack) when specific secure elements are being used.
Hi Denis,
We discussed these kinds of collusion attacks at great length
previously on this list. My views on them have not changed.
Am 04.05.20 um 20:06 schrieb Denis:
As soon as a software solution would be available to perform this
collaborative attack, everybody would be able to use it.
Teamviewer is sufficient and widely available.
-Daniel
Denis
Hi all,
as mentioned in the WG interim meeting, there are several ideas
floating around of what DPoP actually does.
In an attempt to clarify this, if have unfolded the use cases that I
see and written them down in the form of attacks that DPoP defends
against:
https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html
Can you come up with other attacks? Are the attacks shown relevant?
Cheers,
Daniel
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
