Re: [OAUTH-WG] DPoP key rotation

[Brian Campbell <[e-mail]>]

Hi Dmitry,

This ML is indeed the appropriate place for this kind of thing. You raise a
legitimate question, however, the general rough consensus thinking has been
that allowing for DPoP key rotation for refresh tokens and public clients
(the only case where it's relevant) didn't add enough value to justify the
added complexity. It doesn't help with the threat model for in-browser
applications. And mobile applications have really good options for key
storage - to the point that the kind of event that might compromise a DPoP
key would involve a lot more than key rotation to cleanup from.



On Tue, Jun 8, 2021 at 10:31 AM Dmitry Telegin <dmitryt=
[e-mail]> wrote:

> Hi,
>
> I'm Dmitry Telegin, I'm currently working on DPoP implementation in
> Keycloak on behalf of my company, Backbase. Takashi Norimatsu of Hitachi
> supervises this process as the head of the Keycloak FAPI SIG.
>
> With the current DPoP design, once the keypair has been generated on the
> user agent and the initial token set has been obtained (using
> authorization_code grant), the whole chain of the subsequent access/refresh
> tokens will be bound to this particular keypair. That means, the keypair
> should be persisted on the user agent for the duration of the session.
>
> OTOH, sessions could be rather long-lived, especially if we take offline
> tokens [1] into account. In a nutshell, offline access provides a
> non-expiring refresh token. This could be highly relevant e.g. for mobile
> applications that would employ offline tokens to help users avoid logging
> in every time.
>
> The longer the session lasts, the higher the probability of key leakage
> is. Currently, the only way to switch to a new DPoP keypair is to start a
> new session (i.e. log in again). Do you think it might be worth
> incorporating some sort of key rotation concept into DPoP design?
>
> The most obvious way to perform key rotation is to do that during token
> refresh. For that, we could make the refresh_token grant honour the
> additional DPoP proof that would supersede the current one. From the
> technical PoV, it could be as easy as supplying two proofs within the DPoP
> header:
>
> DPoP: eyJ0eXAiO... eyJ0eXAiO...
>
> Or we can go with a single (old) DPoP proof, containing the new proof (to supersede the current one) as a claim (or vice versa).
>
> We'd appreciate any feedback from the WG. Also apologize if this ML is not the appropriate place to discuss issues like this.
>
> Regards,
>
> Dmitry Telegin
>
> Senior Backend Engineer, Backbase R&D B.V.
>
> [1] https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._