[krbdev.mit.edu #5338] race in TGS key rotation.

[Public Submitter via RT]

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.