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

Denis <denis.ietf@free.fr> Fri, 01 May 2020 08:47 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 840193A0C86 for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 01:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZvWuzsJhLbfz for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 01:47:31 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5AA3A0C7C for <oauth@ietf.org>; Fri, 1 May 2020 01:47:25 -0700 (PDT)
Received: from [] ([]) by mwinf5d05 with ME id ZLnJ2200Q4FMSmm03LnMWt; Fri, 01 May 2020 10:47:23 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 01 May 2020 10:47:23 +0200
To: oauth@ietf.org
References: <CALAqi_-9+JYBMSSBnX9PUZkvrPrGTtS8wrJduoPCxMs9+FguPQ@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <27491ba3-857d-8ab9-fbe3-f3cf37d0078b@free.fr>
Date: Fri, 1 May 2020 10:47:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CALAqi_-9+JYBMSSBnX9PUZkvrPrGTtS8wrJduoPCxMs9+FguPQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------28178BA488F52192CAFE41F4"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/6EkTw_9SrfBWQujpM2_TVTS3KlQ>
Subject: [OAUTH-WG] DPoP draft-ietf-oauth-dpop-0 Client collaborative attacks
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2020 08:47:34 -0000

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

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

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.