Justin,
Denis,
This is why the use of “iat” and “nonce” are recommended, to prevent
this kind of replay, and these are already discussed in the draft.
Having a highly targeted request with narrow presentation window is
desirable in most cases, but some applications of DPoP do want to have
a pre-generated proof that can be re-used on multiple requests. In
this case, it becomes kind of bearer token in its own right, since
it’s not strictly tied to a single HTTP request. This isn’t an attack,
it’s an artifact of DPoP’s limited attachment to the HTTP message. If
a client pre-generates a generic proof and gives it to another client,
then that’s exactly the same as the client handing over its access
token (which it would also need to do).
The topic I am discussing has nothing to do with replay. The legitimate
client gives away a token that it will never use.
The proof and the token are credentials, by definition.
Well, the term "credentials" is being used with many different semantics
in different documents. This is why I prefer not to use it.
Subject identifiers within the token do not prevent this kind of
collusion, as has been previously discussed at length.
As it has been presented several times, this other technique provides a
solution (only) in the context of long term user accounts,
but this is very common case.
Nothing stops Alice from giving her token that says “This is Alice” to
Bob and having Bob use it.
Such scenario does not exist in the context of long term user accounts.
However, it is important first to understand the concept
of long term user accounts.
The RS will know it’s Alice’s token, but it’s still valid and Bob can
act as Alice.
When the AS delivers the access token, it includes into that access
token an identifier that the client cannot choose which is
representative of either Bob or Alice.
Alice cannot act on a long term user account that has been previously
successfully opened by Bob, because she will get an identifier specific
to herself.
On the contrary, when using DPoP, the sentence "/*not identified, not
catch*/" applies. Bob can sell such key bound tokens to an unlimited
number of users.
If Alice is over 18 then Bob will get access to the things that Alice
can get because she’s over 18.
The call still works.
Please stop pretending that adding a user identifier to the token
solves the problem you are describing, it simply does not.
I would agree that the scenario of mixing user identifiers to the token
and giving away access tokens between collaborative clients
has not yet been fully explored. If you are willing to discuss long term
user accounts in such a context, please open a different thread.
However, we should not mix topics since *this current thread is about
DPoP*.
The key point is not the existence of an alternative technique at the
moment, but the fact that DPoP is currently giving *a false sense of
security*.
Currently DPoP allows clients to monetize the selling of "key bound
access tokens" to other end-users, and this should be advertised
in the Security Considerations section.
The next question is the following: being informed of that threat, will
the community really use DPoP ? I let you answer that question.
However, if the community is not informed, it is more likely that it
will use it. Ignoring the danger will not stop the threat.
Denis
— Justin
On Mar 29, 2022, at 11:39 AM, Denis <[email protected]> wrote:
Hi Justin,
In this scenario, the “legitimate” client _never_ gives away its
secrets (if it is using a secure platform, it can't). It never give
away its credentials either.
When using key bound access tokens, a RS can't know whether the
access token is presented by the “legitimate” client or by
an“illegitimate” client.
One of the goals is also to prevent a client to monetize the selling
of "key bound access tokens" to other end-users.
As I have already indicated, there exists a solution able to prevent
such scenario in some specific cases (i.e. in the case of RS
long-term user accounts).
Denis
If the “legitimate” client willingly gives away its secrets and
tokens to the “illegitimate” client, then the latter isn’t actually
“illegitimate” anymore.
What I was saying is that the “attack" is not even necessary if the
clients are in fact working together.
If the “legitimate” client knowing gives away its credentials, it is
accepting that the receiver of those credentials can do anything it
wants with those credentials. That’s why they are credentials.
— Justin
PS: I did not “break” the thread, I replied to a message in the
thread. That’s how email lists work.
On Mar 29, 2022, at 9:19 AM, Denis <[email protected]> wrote:
Hi Justin,
You broke the thread since you have not re-used the last message
which was:
Steinar,
As you have guessed, no data (except the token and some crypto
checksums) is passing through the clients.
Once the legitimate client has allowed the illegitimate client
to use the token, the illegitimate client can do anything it
wants with it.
The legitimate client can be kept fully ignorant of what
illegitimate client is doing.
The data flow is minimum: if the token allows to view a 4 Gb
movie, that data flow does not flow between the clients.
Furthermore, the content of the token may allow the
illegitimate client to use it during days or months.
Suppose that the token indicates "over 18". If the user is over
18 now, he will certainly be "over 18" the next days, months or
years.
There is no need to refresh the token as it would be the case
if the token included a home address.
This message explains why this collaborative attack is very
different from simply forwarding messages between clients.
The illegitimate client can do anything it wants without disclosing
what it is doing to the legitimate client.
The traffic between the clients is kept to the very minimum.
Denis
+1
Am 29.03.22 um 15:10 schrieb Justin Richer:
And this is exactly the problem with the “collaborating clients”
attack, as has been pointed out any number of times it’s been
brought up before. If two clients are willingly collaborating in
this way, they do not need to share any cryptographic material
and impersonate each other.
You don’t need to steal my license if I’m willing to just go buy
you beer.
The DPoP draft does address signed request re-use, which some see
as a feature to be carefully applied.
— Justin
On Mar 28, 2022, at 1:04 PM, Steinar Noem <[email protected]> wrote:
Interesting, but won't two collaborating clients just pass any
data they want to each other? Why would these collaborating
clients go through the trouble of exchanging private keys, dpop
proofs or tokens? Could you elaborate some more on the scenario?
S
man. 28. mar. 2022 kl. 16:29 skrev Denis <[email protected]>:
Rifaat & Hannes,
Hereafter are my comments:
The introduction states :
Recipients of such tokens are then able to verify the
binding of the token to the key pair thatthe client has
demonstrated
that it holds via the DPoP header, thereby providing
some assurance that the client presenting the token also
possesses the private key.
In other words, the legitimate presenter of the token
is constrained to be the sender that holds and can prove
possession of the private part of the key pair.
The client presenting the token *does not necessarily
possess the private key*. The client presenting the token
has been able to use
the results of some cryptographic functions using the
private part of the key pair.
These results may be communicated by one client to another
client, if the two clients agree to collaborate. This
statement will be added later on.
Proposed rewording:
Recipients of such tokens are then able to verify the
binding of the token to the key pair thatthe client has
demonstrated
that it holds via the DPoP header, thereby providing
some assurance that the client presenting the token *either
*also possesses
the private key *or* has been able to use the result
of cryptographic computations from another client that
possesses the private key.
In other words, the presenter of the token can prove
that it has been able to use the results of cryptographic
computations performed
by using the private part of the key pair.
The objectives states
The primary aim of DPoP is to prevent unauthorized or
illegitimate parties from using leaked or stolen access tokens,
by binding a token to a public key upon issuance and
requiring that the client proves possession of the
corresponding
private key when using the token.
DPoP does not prevent unauthorized or illegitimate parties
from using access tokens, as soon as two clients agree to
collaborate.
Proposed rewording:
The primary aim of DPoP is to bind a token to a
public key upon issuance and requiring that the client
proves possession
of the corresponding private key when using the
token.This does not demonstrate that the client presenting
the token is
necessarily the legitimate client. In the case of
non-collaborating clients, DPoP prevents unauthorized or
illegitimate parties
from using leaked or stolen access tokens. In the
case of collaborating clients, the security of DPoP is
ineffective
(see section 11.X).
Section 11 is about "Security Considerations" and addresses
the following topics:
11.1.DPoP Proof Replay
11.2.DPoP Proof Pre-Generation
11.3.DPoP Nonce Downgrade
11.4.Untrusted Code in the Client Context
11.5.Signed JWT Swapping
11.6.Signature Algorithms
11.7.Message Integrity
11.8.Access Token and Public Key Binding
11.9.Authorization Code and Public Key Binding
The case of collaborative clients should be addressed within
section 11.
Text proposal.
11.X. Collaborative clients
DPoP demonstrates that the client presenting the
token has been able to use the results of some cryptographic
functions
using the private part of the key pair.
If a client agrees to collaborate with another client, the
security of DPoP is no longer effective.When two clients
agree to collaborate,
these results of the cryptographic computations performed by
one client may be communicated to another client.
Even if the private key used for DPoP is stored in such a
way that it cannot be exported, e.g., in a hardware or
software security module,
the client can perform all the cryptographic computations
needed by the other client to create DPoP proofs.
The client can easily create new DPoP proofs as long as the
other client is online.
Note: There exist other techniques able to limit, in some
cases, the use of a token transmitted voluntarily by a
legitimate client
to an illegitimate client.
Denis
All,
As discussed during the IETF meeting in *Vienna* last week,
this is a *WG Last Call *for the *DPoP* document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Please, provide your feedback on the mailing list by April
11th.
Regards,
Rifaat & Hannes
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Vennlig hilsen
Steinar Noem
Partner Udelt AS
Systemutvikler
| [email protected] <mailto:[email protected]> | [email protected] |
+47 955 21 620 | www.udelt.no <http://www.udelt.no/> |
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
https://danielfett.de
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
