Subject: [OAUTH-WG] DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks

From: Denis <[email-masked]>
Date: Fri, 1 May 2020 10:47:18 +0200

Comments on draft-ietf-oauth-dpop-00.

1) In section 9 (Security considerations), the text states:

DPoP does not, however, achieve the
same level of protection as TLS-based methods such as OAuth Mutual
TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding]
(see also Section 9.1 and Section 9.4).

draft-ietf-oauth-token-binding-08 [i.e. I-D.ietf-oauth-token-binding] 
expired on April 22, 2019,
thus it does not seem adequate to refer to it.

2)  The text states:

9.1.DPoP Proof Replay

If an adversary is able to get hold of a DPoP proof JWT, the
adversary could replay that token at the same endpoint (the HTTP
endpoint and method are enforced via the respective claims in the
JWTs).

This is true, but there is a worse case:  if a client legitimately 
obtains a DPoP proof JWT and collaborates
with another client, then it can provide it to that other client.

3)  The text states:

    9.4.Message Integrity

DPoP does not ensure the integrity of the payload or headers of
requests.The signature of DPoP proofs only contains the HTTP URI
and method, but not, for example, the message body or other request
headers.

This is an intentional design decision to keep DPoP simple to use,
but as described, makes DPoP potentially susceptible to replay
attacks where an attacker is able to modify message contents and
headers.In many setups, the message integrity and confidentiality
provided by TLS is sufficient to provide a good level of protection.

DPoP alone or DPoP used in conjunction with TLS does not provide any 
protection in case of collusion attacks
between collaborative clients.

Collaborative attacks between clients cannot be countered using 
software-only implementations.
It should also be noticed that the use of secure elements to only 
protect private keys is insufficient,
since a collaborative client can still perform all the cryptographic 
computations needed by the other client.

These considerations aboutcollaborative clients should be added into the 
security considerations section.

Denis

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 May 2020 16:00:29 -0700

Hi Denis,

>    thus it does not seem adequate to refer to it.

It can still be useful to refer to technology that ended up not getting
deployed, for comparison against the work in questionn.

>            9.1.  DPoP Proof Replay
>    This is true, but there is a worse case:  if a client legitimately obtains
>    a DPoP proof JWT and collaborates

Would we not consider one or both such clients to be "an adversary" in that
situation?  They are, after all, behaving contrary to the expected flow.

>       9.4.  Message Integrity
>       requests.  The signature of DPoP proofs only contains the HTTP URI
>       headers.  In many setups, the message integrity and confidentiality

Do you think that the reader would expect such protection in the absence of
text in the security considerations section?
My personal expectation is that the reader would not expect protection
against a client that colludes with some other (malicious) party, and that
such a client would itself be deemed malicious.

Thanks,

Ben

>    It should also be noticed that the use of secure elements to only protect
>    private keys is insufficient,
>    These considerations about collaborative clients should be added into the