Ticket 5338: Race conditions in key rotation

[Jeffrey Altman]

Ticket 5338 describes a race condition that occurs whenever a TGS key
is rotated.  In a multi-KDC environment, when a TGS key is updated
there is going to be a period of time during which only the Master KDC
is going to have a copy of the key.  The slaves will not obtain a copy
of the key until the Master has finished propagating its database.
Depending upon the size of the database and the frequency of propagations
(even assuming there is incremental propagation) there is only going to
be some window during which a client could obtain a TGT from the Master
and then try to present it to a slave and end up receiving a failure.

In the current implementation the sendto_kdc() function will return
a value indicating whether or not the master kdc was contacted.  However,
only the krb5_get_init_creds_password and krb5_get_init_creds_keytab
functions will actually perform a retry against the KDC on failure.

In order to address this race condition I propose that krb5_send_tgs()
be modified to retry against the master KDC whenever there is an
error and the error is not one of KRB5_KDC_UNREACH or 
KRB5_REALM_CANT_RESOLVE.

If such as patch was written, would the Consortium accept it?

Thanks

Jeffrey Altman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080618/bdf73068/attachment.bin