Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

[Neil Madden <[e-mail]>]

On 22 Nov 2019, at 07:13, Dick Hardt <[e-mail]> wrote:
> 
> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <[e-mail] <mailto:[e-mail]>> wrote:
> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <[e-mail] <mailto:[e-mail]>> wrote:
>> There are key distribution challenges with that if you are doing validation at the RS, but validation at the RS using either approach means you’ve lost protection against replay by the RS. This brings us back to a core question: what threats are in scope for DPoP, and in what contexts?
> 
> 
> Agreed, but validation at the RS is premature optimisation in many cases. And if you do need protection against that the client can even append a confirmation key as a caveat and retrospectively upgrade a bearer token to a pop token. They can even do transfer of ownership by creating copies of the original token bound to other certificates/public keys. 
> 
> While validation at the RS may be an optimization in many cases, it is still a requirement for deployments.

It's a pattern currently used in some deployments. But as Brian (I believe) mentioned at the last OSW in Trento, you often really want to setup a shared key between the AS and the RS and use authenticated encryption instead for performance and PII protection reasons. And if you do that then (a) replay by the RS is not possible because each RS has a different key and (b) you can use the shared key for macaroons too.

(This is why I proposed adding public key authenticated encryption to JOSE [1] after OSW, and why the initial version of the draft included a simple two-way handshake to derive a symmetric session key that could be used for subsequent messages. That handshake had perfect forward secrecy and key compromise impersonation protection as well, which is overkill for DPoP hence my later simplified challenge-response version).

> 
> I echo Annabelle's last question: what threats are in scope (and out of scope) for DPoP?

I agree this is the crucial question as per my original post a week ago asking what the intended threat model is [2].

[1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 <https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02> 
[2]: https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s <https://mailarchive.ietf.org/arch/msg/oauth/1Zltt75p5taPw0DRmhoKLbavu9s>

-- Neil