Hi Steinar,
Please read first the response just posted to Daniel.
Hi Denis, I don't understand the attack or the countermeasures you are
describing completely - but that doesn't really matter.
Since it does not matter, let us continue. :-)
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.
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.
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?
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
<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.i...@free.fr
<mailto:denis.i...@free.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.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
--
https://danielfett.de <https://danielfett.de>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
--
Vennlig hilsen
Steinar Noem
Partner Udelt AS
Systemutvikler
| stei...@udelt.no <mailto:stei...@udelt.no> | h...@udelt.no
<mailto:h...@udelt.no> | +47 955 21 620 | www.udelt.no
<http://www.udelt.no/> |
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
