#987 [RFE] Add automtic Kerberos key rotation for hosts and services
Opened 8 years ago by dpal. Modified 2 years ago

Certs can be rotated with certmonger using host keytab. But certs are not the only keys that need to be rotated and managed. We already have plans to manage SSH keys. So this ticket is about managing keytabs.
May be it should be done using certmonger. In this way the certmonger (or keymonger) can be pointer to the keytab (or potentially other symmetric key on the system managed by IPA) and told to renew it at some point in future. In this case it will use the certificate to authenticate to the IPA server to establish trusted connection and rotate the keytab.


A little bit about the reasons why this is needed.

Keytab is a long lived key. But even long lived keys need to be changed once in a while. There can be different reasons for changing them. One is just because every key from the cryptography point of view can be cracked. It is the question of the computation power and time. It is reasonable to assume that attacker can easily recruit and farm out the key cracking procedure to a thousand of hijacked machines. But cracking still would take some time. Long time in many cases. But anyways the life span of the keys in the keytab should always be less than the time it would take to crack the keys.

Another reason is that the key over times gets exposed more. More users get root access to the box.
This is why it is a good practice to actually change the long lived keys and this is why the certificates have expiration.

So providing a good way to rotate the key without disruption and manual intervention addressed potential security concerns, makes audits easier without adding addition manual procedures and thus IT costs.

Some notes:

  • two keys should be present in a keytab file - the newly acquired one and the original one. Others can be destroyed. The purpose of this is so clients connected to the machine by the old key don't get blocked by acquiring a new key. The old key can be destroyed after a period of time equal to what KDC allows as maximum ticket life.
  • acquiring a new key is similar to kpasswd operation, therefore no certificate is needed. How to do it is implementation detail.

Some notes (better formated):
- two keys should be present in a keytab file - the newly acquired one and the original one. Others can be destroyed. The purpose of this is so clients connected to the machine by the old key don't get blocked by acquiring a new key. The old key can be destroyed after a period of time equal to what KDC allows as maximum ticket life
- acquiring a new key is similar to kpasswd operation, therefore no certificate is needed. How to do it is implementation detail
- the key rotation should be handled by a standalone daemon which would cooperate with IPA or MIT Kerberos KDC. Other implementations don't need to be supported at the beginning and should be implemented at user request

Metadata Update from @dpal:
- Issue assigned to rcritten
- Issue set to the milestone: Tickets Deferred

2 years ago

Login to comment on this ticket.

Metadata