Making password driven SSH 'immune' to MTM attacks.

[Gregory Maxwell]

[I know this is the 'port' list, but I can't find a better place to post
this, and with the garbage going on @slashdot I figured I'd get this out. 
This belongs on sci.crypt or a general OpenSSH mailing list]

First, a quick rehash of stuff everyone here already knows,

OpenSSH can use two major forms of authentication:

1. Password
2. RSA keys

The RSA method is good because it doesn't rely on the (frequently
non)secrecy of passwords. It's primary disadvantage is that using it
correctly requires a PKI of some form (be it x.509 certs, GPG signed
copies, manual key population) to be secure. Considering the complexity,
cost, and lack of standardaztion, *most* orgs will are not and will not be
using RSA keys anytime in the forseable future.

Passwords are well understood, by both crypto/security heads and by the
common man. Often passwords are not a very good form of authentication,
because of their very nature. However, due to their simplicity many orgs
have developed sufficently secure methods of establishing and protecting 
passwords. Unfortuantly, when using passwords with SSH you are fairly
vulnarable to a Man-in-the-middle attack. SSH provides some basic
protection against this in the form of saved host keys. Unfortunatly, this
is insufficent as the network could be comprimised before inital
connection, and often users will just 'okay' the WARNING message anyways
because it is falsely triggered so easily.

I have a proposed solution that will make MTM virtually impossible in a
password authenticated SSH enviroment assuming the password is indeed a
shared secret and the server is not comprimised. MTM against stored keys
is not examined, presumibly the 'PKI' system is use provides sufficent
security against that.

For the rest of this message, we will assume a password is indeed a shared
secret. This makes sence because if it's not a secret, your security is
gone anyways. My scheme does not further reduce security in the situation
where the password is comprimised.

First go to http://srp.stanford.edu/srp/ and read up on SRP. SRP is a
password authentication system with the following properties:

* 'Shadowed' password data stored on server. It's computationally
inplusable that an attacker could derrive the password from the 'shadow'
(like MD5).
* The client sends NON plain-text equivlent data across the wire.
* It's infeasable for an MTM attack to occure unless the MTM knows either
the 'shadow' from the server, or the plain-text password (in which case
why would you bother with a MTM)

SRP is currently used as a 'replacement' for SSH in enviroments that can't
use encryption or are willing to use an enhanced telnet but not a whole
new client.

If we add SRP client code to the OpenSSH client (a small amount of code
that can be easily audited), and a small modification to the server it
will make it possible to use SRP to authenticate on hosts that using an
SRP password file. The most difficult aspect of the implimentation is that
the SRP negoiated secret should be xored into the key used for SSH channel
encryption (this would be rekeying because the ssh encrypted channel is
already established at authentication time).

This would make passworded SSH almost entirely immune to active MTM in the
common case, while not reducing security at all (with the excpetion of
potential implimentation bugs). This would also provide improved
compatibility for systems that are using both SSH and SRP (for other
services perhaps, or clients that can't use strong encryption).

This would probably require a minor change in the protocol that could
still operate in a backwards compatible fashion.

I think that this protection is important for the future of SSH, as
there appears to be no inexpensive, standard, simple, and understabable
PKI implimentation on the horizon. Because of this, people are going to
continue using passwords, at least with this reletivly minor enhancement,
their securiy is brought back to that of the password and not that of the
network during initial connect.

Any comments?

(is this a new idea?)