[17058] 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 11:55:57 2011
Message-ID: <4E299D7E.3010006@derooter.org>
Date: Fri, 22 Jul 2011 17:55:42 +0200
From: Henning Horst <horst.h@derooter.org>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <1311345562.23877.181.camel@t410>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: multipart/mixed; boundary="===============0222421983=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0222421983==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig23BE14496382C3E8A91954A2"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig23BE14496382C3E8A91954A2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks a lot, Greg, for you swift response, my comments in your mail
(prefixed with [H1]) below:
On 07/22/2011 04:39 PM, Greg Hudson wrote:
> 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 wit=
h
> another protocol using the host service.
[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?
> 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.
>
[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?
>> From 1-4 and the assumption that the connection is secured properly,
>> there should be no way of doing a replay attack against the applicatio=
n
>> 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 MI=
C
> for the session identifier.
>
[H1] In which Kerberos packet can the authenticator and the service
ticket be stolen? - still assuming that the connection between client
and server are secured properly.
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.
>> Last but not least - what about if using SSH2 authentication method
>> gssapi-keyex (rfc 4462) ? In this method the Diffie-Hellman key exchan=
ge
>> (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.
>
>
[H1:] Btw: The origin of this question is that we use multiple gssapi
authentication processes (using the same server credentials) that are
called from multiple SSH server processes. The SSH server processes are
all listening to the same port (using round robin dispatching).
Communication between the gssapi authentication processes (actually
accessing the Kerberos libs via the gssapi bindings) and the SSH server
processes is done via IPC. The reason for using multiple processes is
for loadbalancing. However writing from multiple processes to one replay
cache seems to leads to concurrency issues (apparently no locking? or
was this implemented in the latest Kerberos versions? ) The KRB5CACHEDIR
helps out but then - the replay attack prevention is gone partially
(when replaying the service ticket and authenticator that was used with
one gssapi authentication process to a different one with the same
server credentials)
Comments highly appreciated.
Best Regards and thanks again,
Henning
--------------enig23BE14496382C3E8A91954A2
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/
iQIcBAEBAgAGBQJOKZ1+AAoJEIie6vfnBxWxj8MP/1s0m6bGIZQveFQqgXsgP4cN
4fpzEx7tY8jZ5t6F8F8mNG62PmwhYT0Gy/pWI4W4S6uFYcp7WwWzxLS8F4Ljaz1P
l1lpGOTp28y4le6NERtZrFd0ORYXiYgIiBrZXS1f0TiDZPxavBGw9SwZVK8QAfv9
+ekKp7BWjI8fw7ydI36ftoXkeznRaEzU7jbXOr8LjLAaU2XyDxtwbrevs5npMhHJ
DMUHct47QVX9D1Fq1C18l2Cbl+g/jCsBUA4t0bTxkUwMQtZZGIFCnLF2/UNIIQ3c
87He5F+yBslWibAIDXN0VfIyAdKfPPxcScqkhsRK8diZcgo4a2J0NXTNOwRcQqXY
FRt/s4oli6+N0wh0V5tSPWFZ4J+LSOIgaoIA9OyPcaOq2p1hWFpQx1P1ju7Ga/06
WTDRYEnM1Dc5qZM9QOaHp8+OX2c0U0Rcyk22gjPovIrd5cVpti/JyYuXWekHbX84
Tj3JfV43sjFNgRa0h33mJFjNAWwkLVebpxY5pHtXxIsdxXkyrwwhdPE5Zp5JaWfO
tJSudIgMipqld9DALTV5wDPzV8jiqYm2qucDsr9ZUAEFHmJSKsevLX+a0L6nqn0H
ozl0n+MTQoABPqT1DXn07tn+UcR2uByBkJJVY+bJsZmB06iG/vNK4iUTzHjVOZkw
5U86mKqpC8yVcfpnZ+aS
=IujQ
-----END PGP SIGNATURE-----
--------------enig23BE14496382C3E8A91954A2--
--===============0222421983==
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
--===============0222421983==--
