Is a replay attack possible when using SSH2(or other protected service) as the kerberized service?

[Greg Hudson]

On Fri, 2011-07-22 at 11:55 -0400, Henning Horst wrote:
> [H1] Just to make sure - as long as the authenticator and the service
> ticket are only transferred via SSH both cannot be stolen. How would
> "using the host service with another protocol" look like? Could you be
> so kind and outline a short example on how this would work?

I authenticate to a service using Kerberized rlogin or telnet.  You
observe the exchange and pull out the authenticator and service ticket.
You then use those to attempt to authenticate to sshd.

> [H1] In this case they don't have to steal anything but can just do what
> they want and authenticate on behalf of the client, couldn't they? Or
> would Kerberos prevent successful user authentication even if the SSH
> channel was captured?

An attacker who subverts the ssh DH channel would be unable to
authenticate because the client's MIC would be over a different session
ID than the one seen by the server.  But the attacker would be able to
grab an authenticator and service ticket in the process of failing.

> But in any case from what you say - the need to generate a MIC prevents
> the attacker from a successful replay attack. So assuming the attacker
> captured the authenticator because it was used with some other protocol
> using that host service as you indicated above, the attacker would still
> not be able to authenticate successfully due to the inability to
> generate the MIC.

Correct.

> [H1:] Btw: The origin of this question is [...]

I believe you should be able to safely disable the replay cache for
sshd.  The caveat would be if your sshd is old enough to still support
the insecure "gssapi" userauth mechanism, then the replay cache affords
some level of protection against the weaknesses of that mechanism.