You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kudu.apache.org by Dan Burkert <da...@cloudera.com> on 2017/02/24 03:30:06 UTC

Kerberos replay attack mitigation in Kudu

Hi all,

While testing the new Kudu security features, Todd found that the Kerberos
replay cache is causing excessively slow connection setup.  Apparently krb5
will fsync the replay cache file while holding a global lock during every
connection setup on the server.  Workarounds include configuring the replay
cache to be on tmpfs, or disabling it altogether.  Disabling the replay
cache leaves the server open to Kerberos replay attacks.

As an alternative to weakening the replay cache, we've been discussing
adding a server-generated nonce into our negotiation protocol.  The server
would send the nonce to the client, and the client would wrap it in SASL
integrity protection, and send it back to the server.  The server would
then validate that the unwrapped nonce sent by the client matches the
original nonce.  We believe this will protect Kudu against replay attacks
in an even more effective way than the replay cache, and will provide
better performance (our connection negotiation protocol is such that we can
add this with 0 additional round trips).

Are we right in thinking a server-generated nonce protects against this
attack, and will allow us to safely disable the Kerberos replay cache?

- Dan