Re: Ssh "security hole": proposed fix

Well, a while ago I suggested the following as simplified (and
therefore easier to find bugs in) ssh protocol:

> PREAMBLE:
> 
> (1)  A -> B: A
> (2)  B -> A: Cb, PKsb, PKb
> (3)  A -> B: {Kab}_PKsb, {A, B, Cb}_Kab
> (4)  B -> A: {{A, B, Cb, Kab, PKsb}_SKb}_Kab
> 
> SSH_AUTH_RHOSTS:
> 
> (5)  A -> B:  0
> 
> SSH_AUTH_RHOSTS_RSA:
> SSH_AUTH_RSA:
> 
> (5)  A -> B: {{A, B, Cb, Kab}_SKa, PKa}_Kab
> 
> SSH_AUTH_PASSWORD:
> 
> (5)  A -> B: {Ka}_Kab

I was assuming that you would basically have to tolerate
man-in-the-middle style attacks if A did not know PKb before the
exchange.  However, I have since realized that it is easy to have
one's public key in an NFS mounted home directory when talking to a
host one has never talked to before.  Thus, B can know PKa even if A
does not know PKb.  This is enough to prevent man in the middle
attacks if we modify the protocol slightly:

PREAMBLE:

(1)  A -> B: A
(2)  B -> A: Cb, PKsb, PKb
(3)  A -> B: {Kab}_PKsb, {A, B, Cb}_Kab
(4)  B -> A: {{A, B, Cb, Kab, PKsb}_SKb}_Kab

SSH_AUTH_RHOSTS:
SSH_AUTH_PASSWORD:

(5)  A -> B:  0

SSH_AUTH_RHOSTS_RSA:
SSH_AUTH_RSA:

(5)  A -> B: {{A, B, Cb, Kab, PKsb}_SKa, PKa}_Kab
                              ^^^^
IF AUTHENTICATION NOT SUFFICIENT:

(6)  B -> A: {"Passwd:"}_Kab
(7)  A -> B: {Ka}_Kab                           ; Ka is A's password

David

People have also suggested using the Photuris protocol that is part of
the IP Security work being done at IETF
(ftp://www.cnri.reston.va.us/internet-drafts/draft-ietf-ipsec-photuris-02.txt).

The basic idea behind the protocol goes roughly like this:
  1. Exchange session keys using Diffie-Hellman
  2. Each side sends a signature of the Diffie-Hellman exchange (the
     signature can be with any of a number of algorithms; RSA and
     Elliptic Curve systems have been defined).

If this were adapted to ssh, the protocol would look roughly like
this:
  1. Exchange session keys using Diffie-Hellman
  2. Each side sends a signature of the Diffie-Hellman exchange by its
     host key
  3. RSA and Rhosts authentication requests would include a signature
     by the requesting key.

This would get rid of the server key and the need to regenerate it,
because the diffie-hellman exchange already prevents decrypting old
conversations.  The challenge-dialogs could be avoided (unless they
are needed for performance reasons to avoid unnecessary signature
computations).

One could also eliminate RSA in future and start using some other
public key cryptosystem if desired.  The Diffie-Hellman patent and the
generic public key patent expire in 1997; the RSA-patent does not
expire until about year 2000.


Anyway, this would be a major change that probably cannot easily be
made compatibly.  Maybe an incompatible ssh-2.x?  Anyway, I don't want
to rush into making major changes in the protocol.

I would very much like to hear comments on this approach.

    Tatu

On Sunday 23 July 95, at 14 h 45, the keyboard of Tatu Ylonen <ylo@cs.hut.fi> wrote:

> People have also suggested using the Photuris protocol that is part of
> the IP Security work being done at IETF
> (ftp://www.cnri.reston.va.us/internet-drafts/draft-ietf-ipsec-photuris-02.txt
).
> 
> The basic idea behind the protocol goes roughly like this:
>   1. Exchange session keys using Diffie-Hellman
>   2. Each side sends a signature of the Diffie-Hellman exchange (the
>      signature can be with any of a number of algorithms; RSA and
>      Elliptic Curve systems have been defined).
> 
> If this were adapted to ssh, the protocol would look roughly like
> this:
>   1. Exchange session keys using Diffie-Hellman
>   2. Each side sends a signature of the Diffie-Hellman exchange by its
>      host key
>   3. RSA and Rhosts authentication requests would include a signature
>      by the requesting key.
> 
> This would get rid of the server key and the need to regenerate it,
> because the diffie-hellman exchange already prevents decrypting old
> conversations.  The challenge-dialogs could be avoided (unless they
> are needed for performance reasons to avoid unnecessary signature
> computations).
> 
> One could also eliminate RSA in future and start using some other
> public key cryptosystem if desired.  The Diffie-Hellman patent and the
> generic public key patent expire in 1997; the RSA-patent does not
> expire until about year 2000.
> 
> 
> Anyway, this would be a major change that probably cannot easily be
> made compatibly.  Maybe an incompatible ssh-2.x?  Anyway, I don't want
> to rush into making major changes in the protocol.
> 
> I would very much like to hear comments on this approach.
> 
>     Tatu

Stephane Bortzmeyer           Conservatoire National des Arts et Metiers
bortzmeyer@cnam.fr            Laboratoire d'Informatique
                              292, rue Saint-Martin			
tel: +33 (1) 40 27 27 31      75141 Paris Cedex 03
fax: +33 (1) 40 27 27 72      France	

"C'est la nuit qu'il est beau de croire a la lumiere." E. Rostand

Tatu Ylonen <ylo@cs.hut.fi> wrote:
> The basic idea behind the protocol goes roughly like this:
>   1. Exchange session keys using Diffie-Hellman
>   2. Each side sends a signature of the Diffie-Hellman exchange (the
>      signature can be with any of a number of algorithms; RSA and
>      Elliptic Curve systems have been defined).

I've been playing with the cryptotcp program available from utopia..  It
has some bugs but works pretty well, if you don't mind waiting 20-30
seconds at the beginning.  It does a Diffie-Hellman exchange and 3DES over
telnet.  How hard would it be to add some sort of authentication to this
program?

On Mon, 31 Jul 1995, Matthew Ghio wrote:

> Tatu Ylonen <ylo@cs.hut.fi> wrote:
> > The basic idea behind the protocol goes roughly like this:
> >   1. Exchange session keys using Diffie-Hellman
> >   2. Each side sends a signature of the Diffie-Hellman exchange (the
> >      signature can be with any of a number of algorithms; RSA and
> >      Elliptic Curve systems have been defined).
> 
> I've been playing with the cryptotcp program available from utopia..  It
> has some bugs but works pretty well, if you don't mind waiting 20-30
> seconds at the beginning.  It does a Diffie-Hellman exchange and 3DES over
> telnet.  How hard would it be to add some sort of authentication to this
> program?

Yes, I'm interested too, also because cryptotcp looks like a good
candidate as component of my "SafeSox" pet project, to make unmodified TCP
applications secure. Apparently, a sockd daemon could be easily modified
to open encrypted TCP connections to remote cryptod daemons, instead of
targeting remote servers directly. The next logical step would be a
Winsock (or Mac) version of that cryptified sockd, to be run on the same
PC where the applications live (not everybody has a UNIX box on the same
network). No modifications would be required in cryptod: 


Unmod. --- [socksifying DLL] === [crypto-sockd] ~~~~ [cryptod] +++ [server]
Winsock 
Client

--- = local API call
=== = local SOCKS connection (same network or same machine)
~~~ = cryptotcp connection across the Internet
+++ = cleartext TCP connection on the same network or same machine

Another area where I would appreciate analysis by someone more competent
than myself is cryptotcp's random key generator. Even though the
randomizer (in random.c) is called several times, stirring in the pool
also quantities of entropy depending on the time spent during the
establishment of the TCP connection, I doubt that the total resulting
entropy can be that high.  Perhaps, adding some purely local data a' la
randseed.bin (not available to an eavesdropper) would reduce the risk of
the scheme being brute-forced.