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 proof and the token are credentials, by definition. Subject identifiers within the token do not prevent this kind of collusion, as has been previously discussed at length. Nothing stops Alice from giving her token that says “This is Alice” to Bob and having Bob use it. The RS will know it’s Alice’s token, but it’s still valid and Bob can act as Alice. 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. — Justin > On Mar 29, 2022, at 11:39 AM, Denis <denis.i...@free.fr> 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 <denis.i...@free.fr >>> <mailto:denis.i...@free.fr>> 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 <stei...@udelt.no >>>>>> <mailto: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 >>>>>> <mailto: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 that the 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 that the 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/ >>>>>>> <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 <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 <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> >>>> -- >>>> 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> >> > > _______________________________________________ > 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
