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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 10 Apr 2021 13:00:12 -0400

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/

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

*Webex Meeting Link:*
https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b

Regards,
 Rifaat & Hannes

---

From: Denis <[email-masked]>
Date: Mon, 12 Apr 2021 13:36:22 +0200

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.*
> <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>
>
> *Webex Meeting Link:*
> <https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b>
>
> Regards,
>  Rifaat & Hannes
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Daniel Fett <[email-masked]>
Date: Mon, 12 Apr 2021 14:36:14 +0200

Denis,

I was awaiting your mail and I admire your perseverence with bringing
this topic to our attention.

To your points:

> This should be added in section 1 ( Introduction)
No.

>     " In the following, this attacker model is updated (...) to
> include new types of attackers and to define the attacker model more
> clearly".
>
> 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.

> 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. There
is no expectation that OAuth would defend against this kind of thing,
just as there is no mitigation against password sharing in
password-based authentication. 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

-- 
https://danielfett.de

---

From: Denis <[email-masked]>
Date: Mon, 12 Apr 2021 14:57:49 +0200

Hi Daniel,

> this topic to our attention.

[Denis] I admire your perseverence with constantly refusing to include 
this attack. :-)
>> The first sentence of section 3 (The Updated OAuth 2.0 Attacker 
>> Model) clearly states:
>>
>> attack between clients against a RS, where one of them is a 
>> legitimate client
> 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.

> 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.
>
> 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*,
> 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.
>
[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.

    4.16.1Attack Description
    4.16.2Countermeasures

    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.

    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.

    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.

          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

---

From: Steinar Noem <[email-masked]>
Date: Mon, 12 Apr 2021 15:13:43 +0200

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 <[email-masked]>:

> Hi Daniel,
>
> Denis,
>
> I was awaiting your mail and I admire your perseverence with bringing this
> topic to our attention.
>
>
> The case where two clients collude to mount an attack against a RS is not
> addressed. It now needs to be addressed.
>
>
> 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
> Finally, section 4 (Attacks and Mitigations) should include an additional
> subsection, e.g. section 4.16, addressing the case of a collaboration
> attack
> 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 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.
>
> Even though the Security BCP attacker model includes the general setting
> required for the attack, the attack does not violate an expected security
> property.
>
> [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.
>
> subsection, e.g. section 4.16, addressing the case of a collaboration
> attack
> 4.16.1  Attack Description
> 4.16.2  Countermeasures
>
> *4.16*  *Collaboration attack between clients against a RS*
>
> *4.16.1*  *Attack Description*
>
> 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.
>
> element is ineffective to counter this kind of attack, since the legitimate
> client can perform
> *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
> Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for
> OAuth 2.0 Access Tokens states:
>
> affect the value of the "sub" claim in ways that could confuse resource
> servers.
>
> Section 6  (Privacy Considerations) states:
>
> 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
> which shall be compared with the identifier of the user account. If there
> is no match,
> legitimate client and the illegitimate client cannot take advantage of the
> claims
> -- https://danielfett.de
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| [email-masked] | [email-masked]  | +47 955 21 620 | www.udelt.no |

---

From: Daniel Fett <[email-masked]>
Date: Mon, 12 Apr 2021 16:00:43 +0200

Hi Denis,

Am 12.04.21 um 14:57 schrieb Denis:
>> As I'm sure you have noticed, we have updated Section 3 following
>> your last input. It now explicitly says:
>>
I don't understand. This is not about believing, it is written very
clearly and conclusively in the text of the current draft.

We've had this discussion before, and, although irrelevant for the
meaning of the BCP itself, I would like to refer you again to the formal
model in our research paper, which the BCP attacker model is based on.
It has a *very* precise definition of the attacker model that does not
leave room for interpretation. The natural-language description in the
BCP, as usual, is more fuzzy than the formal definition, but both
attacker models include clients cooperating.

>> 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,
> how *"OAuth can successfully defend against this kind of thin**g"*.
> *So* *there **IS **a solution*.
>
I did not say that there is no solution.
> not be able to identify the attack.
Your proposed solution does not enable an RS to identify the attack
unless used together with some form of authentication way outside the
scope of OAuth.

Again, this also goes deeply into OIDC territory.

> I therefore propose to proceed with the Security BCP *with the
> inclusion of this attack*.
>
>> I therefore propose to proceed with the Security BCP without
>> including this attack.
>>
>> -Daniel
>>
I deleted the remainder of the mail as it was not relevant to my answer
(see RFC1855, Section 3.1.1). Everybody can access your original mail on
the mailing list.

-Daniel

-- 
https://danielfett.de

---

From: Denis <[email-masked]>
Date: Mon, 12 Apr 2021 16:56:23 +0200

Hi  Daniel,

> (...)
> meaning of the BCP itself, I would like to refer you again to the 
> formal model in our research paper, which the BCP attacker model is 
> based on. It has a *very* precise definition of the attacker model 
> that does not leave room for interpretation. The natural-language 
> description in the BCP, as usual, is more fuzzy than the formal 
> definition, but both attacker models include clients cooperating.
>
[Denis]. Your very last sentence is finally using two magic words that 
are not present anywhere in the BCP: "*clients cooperating*".
However, *clients collusion* or *clients collaboration* would be more 
accurate.

>>> If I remember correctly, you first presented this attack at the 
>>> OAuth Security Workshop in 2017.
>>> *There is no expectation that OAuth would defend against this kind 
>>> of thin**g*,

[Denis] Well, ... ask anybody else how he would interpret your statement.

> unless used together with some form of authentication way outside the 
[Denis] I never said that there is "some form of authentication". The 
word "authentication" is not present in my text proposal.

At the moment (/and this is a topic of its own that could be discussed 
later on/), a "sub" claim present in an access token is unrelated to any 
identifier
used during an authentication exchange between an end-user and a RS.

This means that your statement is incorrect.

*"OAuth can successfully defend against this kind of thin**g" and, since 
countermeasures exist, they should be described.
*

> I deleted the remainder of the mail as it was not relevant to my 
> answer (see RFC1855, Section 3.1.1). Everybody can access your 
> original mail on the mailing list.
>
> -Daniel
>
I re-established the remainder of the mail as it is relevant to *my 
*answer.

However, reading it again, the "Attack description" does not refer to a 
JWT access token whereas it is not the case for the two other sub-sections.
Nevertheless, these two sub-sections could be easily generalized to also 
address the case where JWT access tokens are not being used.

    4.16.1Attack Description
    4.16.2Countermeasures

Denis

PS. I re-read RFC1855, Section 3.1.1, but there is nothing in the 
Netiquette to delete or maintain some parts of a received message.

---

From: Denis <[email-masked]>
Date: Mon, 12 Apr 2021 17:08:56 +0200

Hi Steinar,

Please read first the response just posted to Daniel.

> describing completely - but that doesn't really matter.

Since it does not matter, let us continue. :-)

> countermeasure you describe is based on an assumption that the AT is a 

It is correct that the proposed text refers to countermeasures that are 
obtained using JWT access tokens.
However, the countermeasures that are explained can easily be 
generalized to any form of access token.

> related and already covered by the work being done in the JWT spec for 

I would like that, unfortunately this is not the case. I copied and 
pasted only the "good" sentences of the JWT spec for Access Token and 
purposely omitted
to copied and paste the sentences that do not allow to protect against 
this attack. In particular that one:

    (...) if a solution requires preventing a resource server from
    correlating the principal’s activity within the resource itself,
           the authorization server should assign different "sub" values
    for every JWT access token issued.

In such a case, it would be rather easy to transmit an access token 
including a claim saying that the subject is over 18 without the RS 
being able to notice
that the access token which is being presented is the result of a client 
collaboration attack.

Denis

> <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12#page-5>
>
> S
>
> man. 12. apr. 2021 kl. 14:58 skrev Denis <[email-masked] 
> <mailto:[email-masked]>>:
>
>     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:
>>
>>>     The case where two clients collude to mount an attack against a
>>>     RS is not addressed. It now needs to be addressed.
>>>
>>>
>>>     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
>>     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.
>
>
>>>     additional subsection, e.g. section 4.16, addressing the case of
>>>     a collaboration attack
>>     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.
>>
>>     *There is no expectation that OAuth would defend against this
>>     kind of thin**g*,
>     [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*.
>
>     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.
>
>     [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
>         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.
>
>         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
>         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.
>
>         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.
>
>         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.
>
>         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,
>         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
>>     https://danielfett.de  <https://danielfett.de>
>>
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/oauth  <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
> -- 
> Vennlig hilsen
>
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
> | [email-masked] <mailto:[email-masked]> | [email-masked] 
> <mailto:[email-masked]>  | +47 955 21 620 | www.udelt.no 
> <http://www.udelt.no/> |

---

From: Daniel Fett <[email-masked]>
Date: Mon, 12 Apr 2021 17:19:12 +0200

Am 12.04.21 um 16:56 schrieb Denis:
>>>> was obviously too implicit, so we made it more clear with the
>>>> recent update.
>>>>

   *  (A1) Web Attackers that can set up and operate an arbitrary number
      of network endpoints including browsers and servers (except for
      the concrete RO, AS, and RS).  Web attackers may set up web sites
      that are visited by the RO, operate their own user agents, and
      participate in the protocol.

      Web attackers may, in particular, operate OAuth clients that are
      registered at AS, and operate their own authorization and resource
      servers that can be used (in parallel) by the RO and other
      resource owners.

(...)

>>>> 2017 or here on the mailing list as to including this in either of
>>>> the drafts.
>>>>
Feel free.
> later on/), a "sub" claim present in an access token is unrelated to
> any identifier
It is very much possible that I did not understand your proposed
solution correctly. Part of the problem is that a concise and concret
attack description is missing (where end-user and clients are not
conflated). If you could provide such a description, in the style of the
mix-up attack description (i.e., using concrete protocol participants
and protocol messages), that would greatly benefit the discussion.

> Netiquette to delete or maintain some parts of a received message.
    - If you are sending a reply to a message or a posting be sure you
      summarize the original at the top of the message, or include just
      enough text of the original to give a context.  This will make
      sure readers understand when they start to read your response.

-- 
https://danielfett.de