Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP
Denis <denis.ietf@free.fr> Mon, 12 April 2021 11:36 UTC
Return-Path: <denis.ietf@free.fr>
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 315D73A19CA for <oauth@ietfa.amsl.com>; Mon, 12 Apr 2021 04:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 lJkqn6Ldi5uU for <oauth@ietfa.amsl.com>; Mon, 12 Apr 2021 04:36:27 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428AE3A19C9 for <oauth@ietf.org>; Mon, 12 Apr 2021 04:36:27 -0700 (PDT)
Received: from [192.168.1.11] ([90.26.9.133]) by mwinf5d88 with ME id rncN2400C2sDAeJ03ncN8f; Mon, 12 Apr 2021 13:36:25 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 12 Apr 2021 13:36:25 +0200
X-ME-IP: 90.26.9.133
To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>, oauth <oauth@ietf.org>
References: <CADNypP80KicBYDjOHkZQMrowM1WgrtpCr1Ywt88RrTRbZ_Ctrw@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr>
Date: Mon, 12 Apr 2021 13:36:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CADNypP80KicBYDjOHkZQMrowM1WgrtpCr1Ywt88RrTRbZ_Ctrw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------8610C36021BC948FD582E887"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QbDGvPCQzhQsdLDIKJ789Grrh0E>
Subject: Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP
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, 12 Apr 2021 11:36:33 -0000
To all, In RFC 6819 OAuth 2.0 Security), it is assumed in section 2.2 (Attack Assumptions)that : * two of the three parties involved in the OAuth protocol may collude to mount an attack against the 3rd party. For example, the client and authorization server may be under control of an attacker and collude to trick a user to gain access to resources. These three parties are the client, the AS and the RS. The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed. This should be added in section 1 ( Introduction) The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states: " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly". Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client. Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack between clients against a RS. This sub-section would need to include to other sub-sections: 4.16.1Attack Description 4.16.2Countermeasures The following text is a skeleton proposed for these subsections: *4.16****Collaboration attack between clients against a RS* The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server. *4.16.1****Attack Description* The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS. This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client. It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys. *4.16.2****Countermeasures* This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens. Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states: Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. This statement is correct but insufficient, since it does not say how resources servers cannot get confused. Section 6(Privacy Considerations) states: This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match, the access token shall be discarded. In this way, the access token will be linked to the user account of the legitimate client and the illegitimate client cannot take advantage of the claims contained into the access token. Denis > All, > > The coming OAuth WG Interim meeting is this coming* Monday, April > 12th, at 12:00 pm EDT.* > The meeting will be focused on the *Security BCP *document: > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > <https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/> > > The following link has links to the slide and draft and will be used > to capture the notes and attendees: > https://codimd.ietf.org/notes-ietf-interim-2021-oauth-05-oauth?both > <https://codimd.ietf.org/notes-ietf-interim-2021-oauth-05-oauth?both> > > *Webex Meeting Link:* > https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b > <https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b> > > Regards, > Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] OAuth Interim Meeting - April 12 - Sec… Rifaat Shekh-Yusef
- Re: [OAUTH-WG] OAuth Interim Meeting - April 12 -… Denis
- Re: [OAUTH-WG] OAuth Interim Meeting - April 12 -… Daniel Fett
- Re: [OAUTH-WG] OAuth Interim Meeting - April 12 -… Denis
- Re: [OAUTH-WG] OAuth Interim Meeting - April 12 -… Steinar Noem
- Re: [OAUTH-WG] OAuth Interim Meeting - April 12 -… Daniel Fett
- Re: [OAUTH-WG] OAuth Interim Meeting - April 12 -… Denis
- Re: [OAUTH-WG] OAuth Interim Meeting - April 12 -… Denis
- Re: [OAUTH-WG] OAuth Interim Meeting - April 12 -… Daniel Fett