Skip Menu |
 

Subject: race in TGS key rotation.
There's a race in key rotation that I noticed. I haven't tested it, but
it just occurred to me when thinking about the issue. It's pretty
obvious when you consider rotating the TGS key.

1. The master has the new TGS Key. Any TGTs vended by the
master will be encrypted with the new key,

2. If a client obtains a TGT from a KDC which has the new
key it will obviously get the new key,

3. If the client presents said key to another KDC then the
transaction will fail. The client will not retry,

4. If a client obtains a TGT with a recently changed password
or for any other reason switches KDCs between obtaining a
TGT and using it then we may have failures.

The solution is that all errors a client encounters against a slave
should be retried against the master which has a fresher copy of the
Kerberos database and hence is more likely to be up to date.
This race can be solved by modifying the client to always fail over to
the master_kdc on all failures.