On Tue, 2009-06-16 at 07:56 -0400, Ken Raeburn wrote: > (two KDCs could try incrementing the failed- > attempt counter simultaneously by both reading the old value at the > same time, and then both writing the incremented value, causing one > increment to be lost).
This could be detected and fixed easily, all you'd have to do is combine a delete and add operation in a single modify where the exact value retrieved is deleted and the incremented value added. If a race condition occur, one of the KDCs would see the operation fail as it would try to delete with a wrong value. The operation could then be repeated, for a max of 3-5 times or so, and only then the KDC would give up, maybe logging the issue in the log file. In a multi-master case, this technique wouldn't work as both changes against 2 masters would succeed, so in that case an increment would be lost when later the replication conflict resolution will discard one of the 2 changes (in theory special code in the replication code could be written with understanding of how this specific attribute operate and increments could be summed up, but it would probably be a lot of spcial code for not much gain). This seem an issue only wrt failure counts, however if they are low enough, this shouldn't be a big concern. It seem very unlikely that under normal circumstances 2 KDCs will get a preauth request for the same principal. Someone could time them appropriately to multiply the number of chances to guess a password by the number of KDCs, but the timing would be pretty hard to achieve I guess, and not much would be gained. Simo. -- Simo Sorce * Red Hat, Inc * New York ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
