[krbdev.mit.edu #7905] Password changes can result in replay error

[Greg Hudson via RT]

Password changes typically happen over UDP using a request-response 
protocol (RFC 3244 or its predecessor).  As with the regular Kerberos 
protocol, the client will retransmit the UDP request if it does not see 
a reply within a second or so.  If the first request made it to the 
server but the reply got lost, the second request will be rejected as a 
replay attack, and the client will report a failure, when in reality the 
password change succeeded or failed for some other reason.

Possible solutions and mitigations include:

* Disable the replay cache for password changes in kadmind.  This would 
have somewhat negative security implications; it would allow password 
change requests to be replayed within the window.  (That's already 
possible in a multi-master setup, of course.)

* The client could prefer TCP over UDP.  This would be easy to implement 
but might have unwanted side effects.

* If kadmind detects a replay, it could string-to-key the password and 
check it against the current key.  If it detects a match, it can report 
success; if not, it can vaguely report a failure (or it could retry the 
password change without actually writing to the KDB to try to get the 
correct error result).  This approach may have denial-of-service issues 
since string-to-key is slow.

* If the client gets a replay error from the server, it could try an AS 
request using the desired password.  If that works, the client reports 
success; if not, it tries the password change again to get the correct 
failure message.