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 <stei...@udelt.no> 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 <denis.i...@free.fr>:
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
OAuth@ietf.org
https://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
| stei...@udelt.no <mailto:stei...@udelt.no> | 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
https://danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
