on Fri, Aug 24, 2001 at 10:35:49AM +0100, Sean Neakums scribbled:

begin MJ Ray quotation:

...

802.11? Airsnort!

ssh, stunnel, ipsec...

ssh: mitm, key stroke analysis (which seems to have been "discovered" lately but i thought it was obvious to anyone sitting down with tcpdump and an ethernet with ssh...) stunnel: mitm, packet frequency stuff, depending on application.

ipsec: manual keying: spoofed packets and a dictionary/brute force attack, some cryptanalysis depending on known info and algos (replay?) preshared key: same as manual keying, just not so easy with existing sessions

certificates: harder, assuming it sticks strickly to certain certs for certain boxes. otherwise mitm. (mitm = man in the middle) http://lists.freeswan.org/pipermail/users/2001-June/000658.html

The problem with certificate based approaches is that in order to be relatively certain of the peers identity a second secure channel of communication is necessary to transmit the public certificates, otherwise, mitm is easy. And since you are trying to establish a secure channel, this makes it a chicken and egg problem.

on Fri, Aug 24, 2001 at 12:50:16PM +0100, Sean Neakums scribbled:

Man in the middle is a problem only if you do not have the host key fingerprints for the hosts you plan to use. As you note later on in your post, this is a chicken and egg problem common to systems of this nature, but not an flaw inherent in SSH.

True, but with ssh you are interacting with the user who is not always aware of what those "weird error messages" mean. Making it semantical (or whatever the word is :)

Sure. The only way to safely communcate host key fingerprints is either in person or via PGP-signed[0] mail where the keys' autheticity has been established to an acceptable (to the parties involved) degree through signatures on the PGP keys used.

Yep, I've yet to see this implemented in any ssh implementation? gpg/openssh integration would be nice. or just keys stored in openpgp format. gpg --recv-keys to obtain host keys would be interesting.

My main point, which I did not express explicitly, is that it is not the responsibility of the data link layer to make communications on that medium secure.

Yes. The transport or session layer is far more apt and more flexible.

on Fri, Aug 24, 2001 at 04:28:09PM +0100, Neill Newman scribbled:

xsprite@bigfoot.com wrote:

...

Yep, I've yet to see this implemented in any ssh implementation? gpg/openssh integration would be nice. or just keys stored in openpgp format. gpg --recv-keys to obtain host keys would be interesting.

this sounds like kerberos to me, but my knowledge is limited.. anybody care to correct me ??

Well, not really. Kerberos uses trusted third parties, namely the TGS similar to this, but there is no public key stuff, it's all one way hashes and symmetric ciphers. (TGS = ticket granting service. TGT = ticket granting ticket) Also the authentication is the other way around with host keys.

You are authenticating the host, before you give it your secret (in whatever way you decided.. a ticket from the Kerberos TGS, rsa key, password, etc) With Kerberos, I believe the TGS is assumed to be secure and honourable, and the algorithm itself authenticates the TGS to an extent, because it must know the hash of the users secret in order that the user be able to decrypt the TGT/session key properly. Hence no specific host to client authentication occurs.