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

Benjamin Kaduk <kaduk@mit.edu> Tue, 05 May 2020 23:00 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411233A0C1F for <oauth@ietfa.amsl.com>; Tue, 5 May 2020 16:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMQR0L7DfBKC for <oauth@ietfa.amsl.com>; Tue, 5 May 2020 16:00:36 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8013A0C0A for <oauth@ietf.org>; Tue, 5 May 2020 16:00:35 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 045N0Uex030078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 May 2020 19:00:32 -0400
Date: Tue, 05 May 2020 16:00:29 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis <denis.ietf@free.fr>
Cc: oauth@ietf.org
Message-ID: <20200505230029.GX27494@kduck.mit.edu>
References: <CALAqi_-9+JYBMSSBnX9PUZkvrPrGTtS8wrJduoPCxMs9+FguPQ@mail.gmail.com> <27491ba3-857d-8ab9-fbe3-f3cf37d0078b@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <27491ba3-857d-8ab9-fbe3-f3cf37d0078b@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4P7YHq8jYV5YaLRDfThBQ-Qdozk>
Subject: Re: [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: Tue, 05 May 2020 23:00:38 -0000

Hi Denis,

On Fri, May 01, 2020 at 10:47:18AM +0200, Denis wrote:
>    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.

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

>    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.

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.

>    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.

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

>    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 about collaborative clients should be added into the
>    security considerations section.
> 
>    Denis