| Subject: | Password changes can result in replay error |
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.
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.