Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP

Steinar Noem <steinar@udelt.no> Mon, 12 April 2021 13:14 UTC

Return-Path: <steinar@udelt.no>
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 AB4BE3A1D72 for <oauth@ietfa.amsl.com>; Mon, 12 Apr 2021 06:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=udelt-no.20150623.gappssmtp.com
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 TJ2TNnQKjiMH for <oauth@ietfa.amsl.com>; Mon, 12 Apr 2021 06:14:02 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523503A1D6F for <oauth@ietf.org>; Mon, 12 Apr 2021 06:14:02 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id n138so21359274lfa.3 for <oauth@ietf.org>; Mon, 12 Apr 2021 06:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mFGp0uvILPCzOtz41BHv7TBs5ibj3CtxutiilZc4bQo=; b=xq0sqXbXVmzoDfioUtJMyBfhgsXk4kH0sGn0su1zk71tn6H/IOmnvhIBb2qVo01LND kGqzhCPUW6IyYZrfZ++FyUUMfFjXWB6jVx2WR1jJhU060sYvTztEGRFKNQOuXuhpyDNH 856WROlHOzdJeIj5L7cgnM9qyy7FHckxaOQZg8qED+HT0wzV0L760RPLCjYnn8aLa3kO jD+ZXoXcO9A7Zm6pvs6LDg4+TLjpsKXQl9WbNiyOeMhr8Z5iOidkULpNI9EVYp7Mw572 /aBfeQXkF355R426Fv7qzIur+K2z+yI8wFGNKAqa1m/oIQysT6RU4JJnofQNaYrvN13S 2V9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mFGp0uvILPCzOtz41BHv7TBs5ibj3CtxutiilZc4bQo=; b=d/n3uxykVeIboMm+xW2cBJVvLu6oPdgNjNv7nl2wzG8UFyqnHDNQ7DS8eZP56clVPV 0klbdAHiQGOwF262sl3lWeQP6AVr4mLRKKvQVinJ1c/fVhGQ19Af7X/Ortg03oi/cgGi fuMqaBaWRmVc9rY7P6WyLbbXPE7fQ1aW0VaE/MCY0c6ULNhbpahqoNoxWxNl4/IqZcR5 EixDziTk9A1NDukfO5aIO8jzqW1/+L16OyQSTNU7l+2aPcJu9/dXD+w1kxBgqf4NptvM 9FadVWUgiZTtXStBXPGoWGbmV8ej9x7qjOc/dkJ4q951nqpEZy+l7EF3MR5X6DbrPlWs wORA==
X-Gm-Message-State: AOAM533oVqkiiKqjIgXzDXy681Na2wslgHwv7EIRFiz0d662IazcqSbe Yskog2zmFjRYt7qzJaVCXkhZ1LxAkkK3ZaXUUfnYZQ==
X-Google-Smtp-Source: ABdhPJyVL+i9q7NucoeIhZ8TKgZ01U0KMeNM7CV9rlXGG1KpRppsrl10pSxKU93mIa2E0Vcn9im59mrlYMKE69VqoQQ=
X-Received: by 2002:a05:6512:922:: with SMTP id f2mr7607977lft.171.1618233234652; Mon, 12 Apr 2021 06:13:54 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP80KicBYDjOHkZQMrowM1WgrtpCr1Ywt88RrTRbZ_Ctrw@mail.gmail.com> <1990805d-e9c5-969a-9c62-a3ddd21e2180@free.fr> <2e1af244-91cd-1d08-8bf6-97cc82e3f862@danielfett.de> <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr>
In-Reply-To: <065f2559-d14b-5ddc-ba33-8ce14fa2d622@free.fr>
From: Steinar Noem <steinar@udelt.no>
Date: Mon, 12 Apr 2021 15:13:43 +0200
Message-ID: <CAHsNOKdW9U+-7tGTtcx5PZW+769tcw7z3qMc3f1uBSWJNn5OOw@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Daniel Fett <fett@danielfett.de>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001d92da05bfc649fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/UTGuCmnsR6aSLDgi84iVyrpkhcU>
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 13:14:08 -0000

Hi Denis, I don't understand the attack or the countermeasures you are
describing completely - but that doesn't really matter.

As far as I know OAuth doesn't require a specific token format, so the
countermeasure you describe is based on an assumption that the AT is a JWT.
If that's the case, isn't what you are describing as a countermeasure
related and already covered by the work being done in the JWT spec for
Access Tokens?

https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12#page-5

S

man. 12. apr. 2021 kl. 14:58 skrev Denis <denis.ietf@free.fr>fr>:

> Hi Daniel,
>
> Denis,
>
> I was awaiting your mail and I admire your perseverence with bringing this
> topic to our attention.
>
>
> [Denis] I admire your perseverence with constantly refusing to include
> this attack. :-)
>
>
> To your points:
>
> Am 12.04.21 um 13:36 schrieb Denis:
>
> 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)
>
> No.
>
>
> 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.
>
>
> As I'm sure you have noticed, we have updated Section 3 following your
> last input. It now explicitly says:
>
>     Attackers can collaborate to reach a common goal.
>
> It also says
>
>    Note that in this attacker model, an attacker (see A1) can be a RO or
>    act as one.  For example, an attacker can use his own browser to
>    replay tokens or authorization codes obtained by any of the attacks
>    described above at the client or RS.
>
> Your scenario is therefore covered. It was already before, but that was
> obviously too implicit, so we made it more clear with the recent update.
>
> [Denis] I don't believe that the scenario is covered with the above
> sentences.
>
> 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.
>
> If I remember correctly, you first presented this attack at the OAuth
> Security Workshop in 2017.
> Since then, it has been brought up countless times on this mailing list,
> both with regards to the Security BCP as well as for the JWT Token draft.
>
> There has been practically no positive resonance at the meeting 2017 or
> here on the mailing list as to including this in either of the drafts.
>
> A number of reasons come to mind, but first and foremost, I think that
> what you describe is not perceived as an attack, or, worded differently,
> it is obvious that what you describe in the "attack" is possible.
>
> [Denis] Here after comes the important sentence which is wrong:
>
> *There is no expectation that OAuth would defend against this kind of thin*
> *g*,
> just as there is no mitigation against password sharing in password-based
> authentication.
>
> [Denis] In the section 4.16.2 there is a clear proposal that explains how *
> "OAuth can successfully defend against this kind of thin**g"*. *So* *there
> **IS **a solution*.
>
> Currently, when reading the text, an implementer might consider to deliver
> an access token that contains a claim such as "older the 18" without any
> "sub" or equivalent claim.
> Such an access token would be transferable to anyone and the RS would not
> be able to identify the attack.
>
> I therefore propose to proceed with the Security BCP *with the inclusion
> of this attack*.
>
> Even though the Security BCP attacker model includes the general setting
> required for the attack, the attack does not violate an expected security
> property.
>
> I therefore propose to proceed with the Security BCP without including
> this attack.
>
> -Daniel
>
> [Denis] Since you have deleted the remaining of my email, I copy it again.
> If you respond to this email, please DO NOT delete it.
>
> 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.1  Attack Description
> 4.16.2  Countermeasures
>
> 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
>
>
> -- https://danielfett.de
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no |