Subject: [OAUTH-WG] DPoP key rotation

From: Dmitry Telegin <[email-masked]>
Date: Tue, 8 Jun 2021 19:30:13 +0300

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 11 Jun 2021 14:20:19 -0600

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=
[email-masked]> wrote:

> 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?
>
> 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
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._

---

From: George Fletcher <[email-masked]>
Date: Mon, 14 Jun 2021 12:29:40 -0400

There has also been some limited discussion on whether it's useful for 
mobile applications to create a relationship between keys used for 
Dynamic Client Registration (DCR) and the associated keys for DPoP 
headers. DCR does have mechanisms for rotating client instance keys and 
hence if the keys for DPoP are the same then this might be a mechanisms 
to support rotation for mobile applications.

Note that while both Android and iOS have hardware support for keys... 
the keys themselves have limitations on how they can be used, so 
depending on your use case, the hardware backed keys may not suffice.

Thanks,
George

On 6/11/21 4:20 PM, Brian Campbell wrote:
> 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=[email-masked] 
> <mailto:[email-masked]>> 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
>     <https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess>
>     [email-masked] <mailto:[email-masked]>
>     <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./
>

---

From: "Nikos Fotiou" <[email-masked]>
Date: Mon, 14 Jun 2021 20:58:46 +0300

Hi,

For a research project we have implemented key rotation by leveraging “Token Introspection” (see section 6.2 here https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.2 ) Of course the drawback of this approach is that the authorization server must always know the current key of the client.

Best,

Nikos

From: OAuth <[email-masked]> On Behalf Of Dmitry Telegin
Sent: Tuesday, June 8, 2021 7:30 PM
To: [email-masked]
Subject: [OAUTH-WG] DPoP key rotation

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:

---

From: Neil Madden <[email-masked]>
Date: Tue, 15 Jun 2021 11:00:19 +0100

On 11 Jun 2021, at 21:20, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> 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.  
> 

I think this is probably true for most current signature schemes [*], but does this assumption hold for post-quantum signature algorithms? e.g., I think for some hash-based signature schemes like SPHINCS there is a trade-off between number of signatures and signature size - so a key that can never be rotated may have to have larger signatures to compensate to avoid exceeding usage limits. I don’t know enough about the state of the art of post-quantum signatures to say if this is a real issue or if those schemes would be appropriate for DPoP in the first place, but perhaps we should get an opinion from CFRG before baking in this assumption?

[*] There are things like repeating or biased nonces in ECDSA that can leak the private key without the storage being compromised, but I think such bugs would also require more than key rotation to recover from.

— Neil
-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>