Re: [OAUTH-WG] WGLC for DPoP Document

[Denis <[e-mail]>]

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 <[e-mail]> 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 <[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
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>