Public bug reported: Each Fernet token carries an expiration timestamp: the point in time at which an otherwise valid Fernet token is considered to be "expired." This design element is a holdover from previous token formats (especially UUID).
With key rotation, there's no reason for tokens to carry expiry timestamps. Instead, the deployer should tune their key rotation configuration to discard keys that are older than their desired *maximum* token lifespan. For example, if a deployer wishes to rotate encryption keys every hour (by calling keystone-manage fernet_rotate every hour via cron), and maintain a token lifespan of up to 24 hours, then they should configure keystone.conf as follows: [fernet_tokens] max_active_keys = 25 The effect is that 1 staged key, 1 primary key, and 23 secondary keys are held in the rotation (1 + 1 + 23 = 25). This means that tokens will "expire" somewhere between 23-24 hours (depending on how lucky you get with the timing of token creation and key rotation). A less aggressive security policy might be to rotate encryption keys with a daily cron job, and hold keys in the rotation for a week (max_active_keys = 15). Or to rotate encryption keys with a weekly cron job, and hold keys in the rotation for a year (max_active_keys = 53). Unlike with persistent tokens (UUID), deployers are not faced with the challenge of persisting a year's worth of tokens all at once, so the tradeoffs are primarily driven by security considerations, rather than the cost of performance. ** Affects: keystone Importance: Wishlist Assignee: Dolph Mathews (dolph) Status: New ** Tags: fernet -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1428708 Title: Fernet token expiration is redundant with key rotation Status in OpenStack Identity (Keystone): New Bug description: Each Fernet token carries an expiration timestamp: the point in time at which an otherwise valid Fernet token is considered to be "expired." This design element is a holdover from previous token formats (especially UUID). With key rotation, there's no reason for tokens to carry expiry timestamps. Instead, the deployer should tune their key rotation configuration to discard keys that are older than their desired *maximum* token lifespan. For example, if a deployer wishes to rotate encryption keys every hour (by calling keystone-manage fernet_rotate every hour via cron), and maintain a token lifespan of up to 24 hours, then they should configure keystone.conf as follows: [fernet_tokens] max_active_keys = 25 The effect is that 1 staged key, 1 primary key, and 23 secondary keys are held in the rotation (1 + 1 + 23 = 25). This means that tokens will "expire" somewhere between 23-24 hours (depending on how lucky you get with the timing of token creation and key rotation). A less aggressive security policy might be to rotate encryption keys with a daily cron job, and hold keys in the rotation for a week (max_active_keys = 15). Or to rotate encryption keys with a weekly cron job, and hold keys in the rotation for a year (max_active_keys = 53). Unlike with persistent tokens (UUID), deployers are not faced with the challenge of persisting a year's worth of tokens all at once, so the tradeoffs are primarily driven by security considerations, rather than the cost of performance. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428708/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp