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

[Greg Hudson]

On Fri, 2011-07-22 at 05:18 -0400, Henning Horst wrote:
> 1 - Authenticator is always generated on client and only send to
> application server.
> 
> 2 - If this connection is secured properly there should be no way of
> stealing the authenticator
> 
> 3 - If this connection is secured properly there should be no way of
> stealing the service ticket
> 
> 4 - The service ticket can also not be stolen from within the
> KRB_TGS_REP because that packet is encrypted with the client's key

An authenticator and service ticket could be stolen when it is used with
another protocol using the host service.

Also, people using gssapi-with-mic generally do not make strong
assumptions about the quality of the channel protection provided by SSH
host keys.  An attacker capable of mounting an MITM could in some cases
defeat the leap-of-faith protection used in most host key deployments
and observe the channel.

> From 1-4 and the assumption that the connection is secured properly,
> there should be no way of doing a replay attack against the application
> server. Please confirm or correct!

Confirmed, but for different reasons.  An attacker who replays an
authenticator can cause the krb5_rd_req() to succeed, but will not know
the session key and will therefore be unable to correctly generate a MIC
for the session identifier.

> Last but not least  - what about if using SSH2 authentication method
> gssapi-keyex (rfc 4462) ? In this method the Diffie-Hellman key exchange
> (SSH2 layer 1 [SSH-TRANS]) is done based on GSS, with security service
> Kerberos in this case. The actual user authentication (SSH2 layer 2
> [SSH-AUTH]) is then based on that key exchange. How about a replay
> attack in that scenario?

In this case, replays are believed to be impossible because an attacker
without knowledge of the session key will be unable to correctly
generate a MIC for the DH secret.

In both cases, it's important to note that the client cannot force the
reuse of a session identifier or DH secret.