changing password/keys but still being able to use the old ones

Sorin Manolache sorinm at gmail.com
Thu Dec 22 09:15:26 EST 2016


Hello,

I have the following use-case:

I have a service principal, HTTP/localhost, and its keys have kvno 1. I 
export the keys in a keytab file that I deploy on the http server.

At time moment t_0, I change the password of my service principal. They 
newly generated keys have kvno 2. I use -keepold in the cpw command, so 
I still have the old keys.

At time moment t_1, a user requests a ticket for the service. The ticket 
uses the new keys, i.e. those with kvno 2.

The new keys are not yet exported in the keytab and not deployed on the 
http server.

Therefore, at moment t_2, when the user makes a request to the http 
server, his ticket that uses the kvno 2 keys cannot be validated by the 
service that uses the keytab with the kvno 1 keys.

Once I export the new keys in a keytab and deploy them on the http 
server at moment t_3 everything is back to normal.

Just that between moments t_0 and t_3 users who fetched tickets after 
t_0 are not allowed to use the service.

What I would like to be able to do would be:

At t_0 I change the password but I instruct the KDC to use the old keys. 
(Either I would be able to tell the KDC which kvno to use or I would be 
able to specify the kvno of the new keys when generating them such that 
they have a kvno inferior to that of the old keys).

At t_3 I export all keys (both old and new) in a keytab that I deploy on 
the http server.

Between t_0 and t_3 users that fetch tickets after t_0 are still allowed 
to use the service because their tickets are encrypted with the old keys.

After t_3 users that fetch tickets after t_0 are still allowed to use 
the service because the old keys with which their tickets are encrypted 
are still present in the keytab deployed on the server.

At t_4, I tell the KDC to use the new keys to encrypt tickets. Either by 
directly specifying the kvno to use or by modifying the kvno of the keys 
generated at t_0. I may even purge the old keys. I think this can be 
done by the modprinc command.

Users fetching tickets after t_4 can use the http service because the 
new keys are now available in the keytab deployed on the service.

Is there a way to achieve that? Namely to specify the kvno when creating 
new keys or to tell the KDC which kvno to use when issuing tickets?

Thank in advance,
Sorin


More information about the Kerberos mailing list