On 22 Nov 2019, at 07:13, Dick Hardt <dick.ha...@gmail.com> wrote:
>
> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <neil.mad...@forgerock.com
> <mailto:neil.mad...@forgerock.com>> wrote:
> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <richa...@amazon.com
> <mailto:richa...@amazon.com>> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
