[17061] in Kerberos_V5_Development
Re: Is a replay attack possible when using SSH2(or other protected
daemon@ATHENA.MIT.EDU (Henning Horst)
Fri Jul 22 12:42:08 2011
Message-ID: <4E29A822.4070506@derooter.org>
Date: Fri, 22 Jul 2011 18:41:06 +0200
From: Henning Horst <horst.h@derooter.org>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <1311352322.23877.187.camel@t410>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: multipart/mixed; boundary="===============1366378234=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1366378234==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig103B3D4527E3FFBEF0EBEB50"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig103B3D4527E3FFBEF0EBEB50
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Greg,
Thanks a lot for your help and your quick responses. Thanks, too, for
developing such great stuff and providing it for the community!!
Best Regards and have a very nice weekend :)
Henning
On 07/22/2011 06:32 PM, Greg Hudson wrote:
> 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 wh=
at
>> 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 prevent=
s
>> the attacker from a successful replay attack. So assuming the attacker=
>> captured the authenticator because it was used with some other protoco=
l
>> using that host service as you indicated above, the attacker would sti=
ll
>> 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.
>
>
--------------enig103B3D4527E3FFBEF0EBEB50
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOKagiAAoJEIie6vfnBxWx+1oP/Aps15Fth8iWbVoFZavRCG9u
bK7BU2S1UZKpftHUlCgYOuwtxPyq/azVaD0PpTeYfMq2idJnlxaRMXRYbwKKcgKW
YwOuoBMYRx8Eb6L/qkRlj6U4FyEzw2j9S3RpSOBq188UkQlS50eEhcTiTkI+fFU7
OmreaUPfpPEHpgF1GZdmK2emdvhjgiBcry/1hGRZce7+roxWZx/TPS2SxnUXhp9G
W61+VVQS+GBKr4jDkJKd76oxkr8arzQrXiy+DT2jYFgKmg4fIhH5W6Ou3CGzt4/T
2FxmEizN8+jQUuBhiLTNXCIOhbQ+jmhexl4glpPPRy4oZV2/o09l/kIrZeLTD7OX
kfREHhJoLN+RMbS8Y2M35QSa5efsB5iUHDFHiORPRGx9EPWxFDXVgwnhQ7P9tvqf
1AqtxZlxrbgfHcExIMOROvGrAH+dqXciHs/QvjXyRbLoZsrWU6RhiBk8FbZNbiFu
Jy+vgVxRAEQ8iG4zUKQfpZBvDeP1AmNhJuNLMx8sYrvThYFQXkaSFOKLAPPp+00n
RPhoA+MdrOjhshzAIIUm5DZRQgkG+O10BwtKAzrdaN8h4CsGVYvbWeY0XfuzD7L0
xSji6HfDtSYA9TCmilIJw4sbSGk7k5bUFqopBM6uEsafvJUGTSmh87vfLIviubMV
DdpJdlzhQqKNAGCm5UbF
=H9gf
-----END PGP SIGNATURE-----
--------------enig103B3D4527E3FFBEF0EBEB50--
--===============1366378234==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============1366378234==--
