yahoo-eng-team team mailing list archive

[Dolph Mathews <1428708@xxxxxxxxxxxxxxxxxx>]

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