[17056] in Kerberos_V5_Development
Is a replay attack possible when using SSH2(or other protected
daemon@ATHENA.MIT.EDU (Henning Horst)
Fri Jul 22 05:18:28 2011
Message-ID: <4E294050.7000700@derooter.org>
Date: Fri, 22 Jul 2011 11:18:08 +0200
From: Henning Horst <horst.h@derooter.org>
MIME-Version: 1.0
To: krbdev@mit.edu
Content-Type: multipart/mixed; boundary="===============0620804548=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0620804548==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig5D7AEDE9C572B431879034CC"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5D7AEDE9C572B431879034CC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Mailinglist,
I would like to ask the following:
Is a replay attack possible when using SSH2+method with gssapi-with-mic
as the kerberized service? Or to put it more general:
Is it possible to do a replay attack against the application server when
the connection between the client and the application server is secured
properly?
=46rom what I've read and learned from the Kerberos protocol - the answer=
is NO, but I would really appreciate confirmation or correction on that.
In RFC4120, section 3.2.2, , "Generation of a KRB_AP_REQ" it says:
" To use a ticket, the client constructs a new Authenticator from the
system
time and its name, and optionally from an application-specific
checksum, an initial sequence number to be used in KRB_SAFE or
KRB_PRIV messages, and/or a session subkey to be used in negotiations
for a session key unique to this particular session. Authenticators
MUST NOT be re-used and SHOULD be rejected if replayed to a server."
Thus:
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
=46rom 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!
Now regarding the secure connection:
In the concrete case from me it is an SSH2 connection (maybe there are
some ssh2 experts around here as well). The Kerberos exchange between
the client and the server is done via the method gssapi-with-mic (rfc
4462). Here it is relatively obvious that this connection is secure
since gssapi-with-mic takes place on SSH layer 2 - [SSH-AUTH]. If the
SSH2 connection state comes to this subprotocol the [SSH-TRANS]
sub-protocol has already established a secure transport connection, esp.
providing server authentication, encryption and integrity.
Thus - replay attack against the application server is not possible when
the client to server connection uses SSH2 with gssapi-with-mic. Please
confirm or correct!
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?
Thanks a lot in advance,
Henning
--------------enig5D7AEDE9C572B431879034CC
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/
iQIcBAEBAgAGBQJOKUBUAAoJEIie6vfnBxWxW7gP/ipQtYq6A3/ABgEyFImaVODR
+WXRBKw0eSBp2C2M6t/xVVeKfgPH0INug7u2yFY1gtDByd9GIDFL29LRfI9H+JbS
MQqTn8aTGR267UmbpphZZcMrC2Uy4voHn29KJWJzYo7wyoWDCYkKh54HQZ6UmCn0
Ii88CxiRSuoqIfW30Rw28w7y/Cc72bfwuINb50/5dt5Wm72G3bmnMjCVeqMYMIXn
UScM9mB1DaG5QNVvRNUaw/bt9pAb6mYzrfn01/BKzFcNPcILAEzWjB8x5WYQ+9y1
XHeMj5x+8rOuiS+H4n1aK+5ZdQH1S4/sSc276XoZNB1u1GuMLJ7B8VObOYtCzxUy
pLgySogdQCVHQ8EoQJROG/0l2CW/p2IP7HkorCzCl9Xe90DEYwPr7uB0JskIv1oM
Y0u7tZSHUZFCxUSM9Kzy8JoQPsBuFAUxkNR2O0mWCjg8Pf3GK3nmzOLIayI1FD1F
CSY9Z3vBOrd+yfSdE98pVvtzULhTSirX+SuAvWBTy/Nh85KAstqwuFsfDguCsfeb
1znvpl7q4Zxa4BljUTbcuWYUFiGabi71dNTWNIf2l94VuG1CrXgPYkoXqFUdLfGd
c/487wvpFXUSCvasjFUhMF2JLHln3ObbBk4ZsmdH7hTzQ+GU0g+cdte9rF7c07qz
hYzTfjnO7Yc2XJ1/hGKE
=zCop
-----END PGP SIGNATURE-----
--------------enig5D7AEDE9C572B431879034CC--
--===============0620804548==
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
--===============0620804548==--
