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

Steinar Noem <> Mon, 12 April 2021 13:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB4BE3A1D72 for <>; Mon, 12 Apr 2021 06:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TJ2TNnQKjiMH for <>; Mon, 12 Apr 2021 06:14:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 523503A1D6F for <>; Mon, 12 Apr 2021 06:14:02 -0700 (PDT)
Received: by with SMTP id n138so21359274lfa.3 for <>; Mon, 12 Apr 2021 06:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <>
In-Reply-To: <>
From: Steinar Noem <>
Date: Mon, 12 Apr 2021 15:13:43 +0200
Message-ID: <>
To: Denis <>
Cc: Daniel Fett <>, IETF oauth WG <>
Content-Type: multipart/alternative; boundary="0000000000001d92da05bfc649fc"
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?


man. 12. apr. 2021 kl. 14:58 skrev Denis <>:

> 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
> --
> _______________________________________________
> OAuth mailing listOAuth@ietf.org
> _______________________________________________
> OAuth mailing list

Vennlig hilsen

Steinar Noem
Partner Udelt AS

| |  | +47 955 21 620 | |