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 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/ > > Please, provide your feedback on the mailing list by April 11th. > > Regards, > Rifaat & Hannes > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://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 | h...@udelt.no | +47 955 21 620 | www.udelt.no |
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
