Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd: Allow SYSTEM_SECRET key rotation #73

Closed
aeneasr opened this issue May 18, 2016 · 4 comments
Closed

cmd: Allow SYSTEM_SECRET key rotation #73

aeneasr opened this issue May 18, 2016 · 4 comments
Assignees
Milestone

Comments

@aeneasr
Copy link
Member

@aeneasr aeneasr commented May 18, 2016

Key rotation is tricky because we either need a table lock for JWK or an overlord. Having an overlord who is attached to rethinkdb might be the smartest thing to do. There should never be more than one overlord running (how to ensure this? table row? ttl?).

The system secret key rotation definitely needs an overlord. Key exchange could done through HTTP:

  • Poll last key creation and check TTL
  • Generate new secret
  • Gather a list of all running instances
  • Authorize via access token
  • Provide old secret
  • Provide new secret

Alternatively the new secret could be encrypted with the old key and stored in the database. Everyone who has the old key, can read the new one as well. This would save the trouble of instance discovery as all instances are connected to rethinkdb anyways.

Using policies and IP ranges, access to the endpoint could be allowed to trusted addresses only.

On system key rotation, all JWKs must be re-encrypted using the new key. All tokens become invalid when the key changes which is why sysem key ttl must be larger than token ttl. This way we can be sure that all instances can validate tokens using either the old or the new key

@aeneasr aeneasr changed the title the global key should rotate. JWK sets should have a rotate flag system secret and jwk rotation May 30, 2016
@aeneasr aeneasr self-assigned this May 30, 2016
@aeneasr

This comment has been minimized.

Copy link
Member Author

@aeneasr aeneasr commented May 30, 2016

Let me know if you have any ideas how to improve this. Best practices, specs and ideas alike :)

@aeneasr

This comment has been minimized.

Copy link
Member Author

@aeneasr aeneasr commented May 30, 2016

Instead of a flag, JWKs should have an exp claim.

@waynerobinson

This comment has been minimized.

Copy link

@waynerobinson waynerobinson commented Sep 12, 2016

For standard, regular key rotation that are meant to prevent key abuse, I would recommend a period of time where the old and new keys could be used. Basically the maximum expiry period for anything that would've been encrypted or signed with the old key.

If an existing key has been compromised, it should be replaced instantly and anything encrypted with the old key should be considered unsafe anyway and discarded. Locking during the replacement process would be nice, but ultimately there is going to be failing messages at some point if you're not respecting the previous keys anyway.

@aeneasr aeneasr added the other label Jun 5, 2017
@aeneasr

This comment has been minimized.

Copy link
Member Author

@aeneasr aeneasr commented Jul 16, 2018

JWK Rotation is now implemented by adding another key (pair) to the existing set.

@aeneasr aeneasr changed the title system secret and jwk rotation cmd: Allow SYSTEM_SECRET key rotation Aug 10, 2018
@aeneasr aeneasr modified the milestones: unplanned, v1.0.0-rc.1 Aug 10, 2018
aeneasr added a commit that referenced this issue Aug 27, 2018
Closes #73

Signed-off-by: arekkas <aeneas@ory.am>
aeneasr added a commit that referenced this issue Aug 27, 2018
Closes #73

Signed-off-by: arekkas <aeneas@ory.am>
@aeneasr aeneasr closed this in 929cbe5 Aug 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.