[OAUTH-WG] BCP: Client collaborative attacks

Denis <denis.ietf@free.fr> Mon, 26 October 2020 18:18 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 11A493A0B9F for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 11:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.777
X-Spam-Level: *
X-Spam-Status: No, score=1.777 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5Ijnm44EkpRC for <oauth@ietfa.amsl.com>; Mon, 26 Oct 2020 11:18:43 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.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 ED6333A0BA0 for <oauth@ietf.org>; Mon, 26 Oct 2020 11:18:42 -0700 (PDT)
Received: from [] ([]) by mwinf5d32 with ME id kiJf230175QJY7u03iJgqA; Mon, 26 Oct 2020 19:18:41 +0100
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 26 Oct 2020 19:18:41 +0100
To: Daniel Fett <fett@danielfett.de>
Cc: oauth <oauth@ietf.org>
From: Denis <denis.ietf@free.fr>
Message-ID: <8244f38a-710b-e95c-c61a-1b8df541c73e@free.fr>
Date: Mon, 26 Oct 2020 19:18:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------84F1E793F01603826EBCD021"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iYWp0eRpaxYtgBmOaYkODETmWbk>
Subject: [OAUTH-WG] BCP: 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: Mon, 26 Oct 2020 18:18:45 -0000

Hi Daniel,

Following the conversation we had today, hereafter is a proposal for 
addressing client collaborative attacks.
I propose to add a new section 4.16.

4.16 Client collaborative attacks

Two clients may agree to collaborate. In such a situation, one client 
transmits to another client an access token
that it legitimately got and also accepts to perform all the 
cryptographic computations that the other client needs
to use the access token, including when the access token is 
cryptographically bound to a key.

Since OAuth 2.0 does not mandate the use of cryptographic devices, this 
kind of attack cannot be countered in the general case.

However, if the access token contains claims that allow the RS to 
uniquely identify the legitimate holder of the access token
and if the RS only accepts access tokens that are able to uniquely 
identify the legitimate holder of the access token, then
this attack can be mitigated since the client collaborative attack 
becomes an impersonation attack.

For mitigating the collaborative attack, either a "sub" claim must be 
present or any combination of other claims allowing for the RS
to uniquely identify the holder of the access token must be present 
inside an access token, for example OpenID claims like: name,
family_name, given_name, middle_name, nickname, preferred_username, 
gender, birthdate, email, email_verified, phone_number,
phone_number_verified or address.

On the contrary, for example, an access token that would only contain a 
claim stating that the holder of the access token is over 21
or a birthdate without any claim allowing the RS to uniquely identify 
the legitimate holder of the access token, should not be accepted by the RS.

Under these conditions, it should be observed that the first user might 
be unlikely to be willing to collaborate since the other user would be able
to perform actions on behalf of the first user and the first user would 
be held responsible of the actions of the second user.

*Comment on section 4: "Validating JWT Access Tokens"
The JWT profile for OAuth 2.0 access tokens 
[draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim 
into an access token.
However, this section does not mandate the RS to verify that claims 
allowing for the RS to uniquely identify the holder of the access token
are indeed be present inside an access token.

It might be useful to add it, so that the above text can refer to it.