[17062] in Kerberos_V5_Development
Re: Is a replay attack possible when using SSH2(or other protected
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jul 22 14:09:08 2011
MIME-Version: 1.0
In-Reply-To: <4E294050.7000700@derooter.org>
Date: Fri, 22 Jul 2011 13:09:04 -0500
Message-ID: <CAK3OfOjusB=ZUJ2jAU3NV7OyZaA+himb8kpzmXJ=+qEVFoYEqQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Henning Horst <horst.h@derooter.org>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
No replay attack is possible against SSHv2 with gssapi-with-mic nor
gssapi-keyex, not in SSHv2 itself. This is true regardless of whether
the server uses a replay cache. The MIC token used serves to ensure
this since it authenticates a quantity that is not fully under control
of the client (nor the server), that being the SSHv2 session ID (which
is derived from the SSHv2 key exchange and key exchange messages).
However, if you do also use rsh or rlogin and don't require that the
session be protected, then it could be possible to replay a Kerberos
GSS excehange from SSHv2 in rsh/rlogin, but only if the attacker could
get their hands on those context tokens. The only attacker that could
do that is the client, and the client can always try a replay attack
anyways, which are to be defeated via replay caching on the
server-side.
If you had nothing but SSHv2 services using the "host" service then
you could technically forgo the replay cache altogether on the
server-side because the way SSHv2 uses GSS is impervious to replays.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
