Re: [OAUTH-WG] WGLC for DPoP Document

[Daniel Fett <[e-mail]>]

+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 <[e-mail]> 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 <[e-mail]>:
>>
>>     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
>>>     [e-mail]
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> -- 
>> Vennlig hilsen
>>
>> Steinar Noem
>> Partner Udelt AS
>> Systemutvikler
>> | [e-mail] <mailto:[e-mail]> | [e-mail]  | +47 
>> 955 21 620 | www.udelt.no <http://www.udelt.no/> |
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
https://danielfett.de