Re: [OAUTH-WG] DPoP: Threat Model

[Denis <[e-mail]>]

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