Re: [OAUTH-WG] DPoP key rotation

[Nikos Fotiou]

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  On Behalf Of Dmitry Telegin
Sent: Tuesday, June 8, 2021 7:30 PM
To: oauth@ietf.org
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:

 

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 B.V.

[1] https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] DPoP key rotation

[George Fletcher]

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 
> 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 B.V. |

[1]
https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess

___
OAuth mailing list
OAuth@ietf.org 
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./


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth