Esto es detenido por los autenticadores. Cada vez que presente un ticket de Kerberos, debe ir acompañado de un autenticador, que se cifra mediante la clave de sesión y contiene (entre otra información) una marca de tiempo. El servidor comprueba que la marca de tiempo es reciente (en Kerberos 4, esto significa "dentro de 5 minutos", en 5, es configurable, pero 5 minutos es el valor predeterminado) y que nunca antes había visto ese autenticador. El autenticador solo se basa en la clave de sesión, por lo que puede ser generado por el cliente; se crea un nuevo autenticador cada vez que envías un ticket.
Para responder "qué pasa si están usando la misma sesión", el protocolo básico de Kerberos no lo maneja. Kerberos, en su núcleo, autentica al usuario abriendo una conexión; No tiene que hacer nada más. Los protocolos de aplicación son responsables de manejar la protección de más mensajes si eso es importante; Kerberos proporciona dos formas de hacerlo, o puede suministrar datos desde la autenticación a cualquier sistema que utilice el protocolo de la aplicación, pero un protocolo de aplicación no necesita utilizar Kerberos para la autenticación inicial. Todo después de eso depende del protocolo de aplicación.
Kerberos tiene dos opciones para la comunicación protegida con Kerberos más allá del mensaje inicial (una autentica, una encripta y autentica); un protocolo de aplicación puede usarlos para proteger la comunicación posterior, pero no tiene que hacerlo. Ambos utilizan una marca de tiempo y / o un número de secuencia para evitar repeticiones; el número de secuencia protege contra los mensajes caídos y la reordenación de mensajes, mientras que la marca de tiempo se perdona si eso no es un problema (pero evita que un atacante solo retrase un mensaje, ya que un mensaje retrasado será rechazado), pero ambos evitan repeticiones.
Si le preocupa que un usuario malintencionado manipule la transmisión de datos al servidor de impresión, puede definir el protocolo del servidor de impresión para utilizar KRB_SAFE o KRB_PRIV (respectivamente, "autenticar solo" o "cifrar y autenticar" ); Ambos protegen contra las repeticiones. O puede usar algún otro sistema que tome una clave de subsesión del autenticador como una clave precompartida y tiene protección de reproducción; un protocolo TLS-PSK con la clave de subsesión como PSK probablemente funcionaría (TLS protege contra ataques de repetición). El punto es que Kerberos no protege inherentemente contra ese tipo de repetición, porque no dice nada sobre cómo hacer el resto de la comunicación; Para protegerse contra los ataques en la comunicación posterior a la autenticación, debe usar KRB_SAFE o KRB_PRIV de Kerberos o usar otra cosa que proteja esa comunicación.