Small modification to allow application proxies

[Dan Shearer <dan%tellurian.com.au@localhost>]

This proposes a modification to
http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-09.txt

The change affects the definition of the header exchange, and I have not
found a record of it being previously discussed. My apologies if it has
been. I am not a security protocols expert (far from it) just a user
hacking together a solution.

Section 3.2 "Protocol Version Exchange" says:

  When the connection has been established, both sides MUST send an
  identification string of the form "SSH-protoversion-softwareversion
  comments"...
     :
  The server MAY send other lines of data before sending the version
  string.  Each line SHOULD be terminated by a carriage return and
  newline.  Such lines MUST NOT begin with "SSH-", and SHOULD be encoded
  in ISO-10646 UTF-8 [RFC-2279] (language is not specified).  Clients MUST
  be able to process such lines; they MAY be silently ignored, or MAY be
  displayed to the client user; if they are displayed, control character
  filtering discussed in [SSH-ARCH] SHOULD be used.  The primary use of
  this feature is to allow TCP-wrappers to display an error message before
  disconnecting.

I would like to suggest that the client be allowed to optionally send
other lines of data in the same way the servers can, ie a paragraph like
so:

  The client MAY send other lines of data before sending the version
  string.  Each line SHOULD be terminated by a carriage return and
  newline.  Such lines MUST NOT begin with "SSH-", and SHOULD be encoded
  in ISO-10646 UTF-8 [RFC-2279] (language is not specified).  Servers MUST
  be able to process such lines up to a limit of 4096 8-bit characters 
  after the newline; they MAY be silently ignored, or MAY be used to 
  perform some pre-processing of the connection attempt. If they are
  if they are displayed or logged, control character filtering discussed in 
  [SSH-ARCH] SHOULD be used.  The primary use of this feature is to allow 
  application-level proxies for ssh, whereby multiple, different servers
  can be accessed via a single IP address by specifying an appropriate
  payload such as a hostname or other mapping supported by the proxy. The
  syntax of any payload is not specified.

I have invented an arbitary 4096 character limit for safety, although I
don't really know what it should be. I observe that there is no such limit
in the original which says "Clients MUST be able to process such lines". I
suspect this allows the possibility of a malicious server or packet
insertion attack tying up an unsuspecting client, or otherwise confusing
it. I have not checked to see if this issue has been discussed before on
the secsh list; it probably has been, since it is rather obvious!

When I first started playing with openssh I fiddled with letting the
client specify version information such as a DNS name, however this isn't
a good solution for many reasons. UTF-8 DNS names would break the length
limit for a start. I don't see that this proposal weakens the protocol,
because the sensible way to implement an application proxy is just to send
on all information including the extended version string to the host the
other side of the proxy as specified by the payload.

Examples
--------

The following examples assume a network like this:


   Internet        ssh application proxy        Internal .test network

                     ip address 1.2.3.4         girafe (10.0.0.1)
                     DNS A bouchon.test        
                     CNAME girafe.test         

They also assume a -z parameter to the ssh client which puts everything
that follows -z in the extended version string. Sessions are initiated
from random hosts on the Internet.

   ssh -z girafe.test

would make a connection on port 22 to 1.2.3.4, and the proxy server would
see there was a payload. Since "girafe.test" resolves on the internal
network's DNS, the connection attempt is forwarded to 10.0.0.1 (if policy
allows.)

  ssh -z bouchon.test

would connect to port 22 on 1.2.3.4, and the proxy server would see that
the name in the payload is its own name, and (if policy allows) this is
forwarded on to the local machine just like any other connection. Either
there is an ssh daemon running on a port other than 22, or the proxy
server is also an ssh daemon (possibly inadvisable, depends) or the ssh
daemon is running on port 22 bound to another interface on the same
machine as 1.2.3.4.

  ssh -z zero.example

would initiate a connection to the machine zero.example, which is not
running an ssh proxy and would completely ignore the payload, proceeding
with an ordinary connection attempt. Apart from the transmited version
payload, everything in this example would proceed as if the command 
ssh zero.example had been used instead.
 
Benefits
--------

I see the benefits of this addition to be mainly:

  1. Networks behind NAT firewalls will be able to expose internal
     ssh services without exposing any more IP addresses. This increases
     convenience for such sites, not security

  2. An application proxy for ssh will become practical. This could
     increase security (even for sites which are not behind
     NAT firewalls) and it certainly allows some forms of logging
     and control to be centralised that would otherwise be distributed at 
     the ssh connection endpoints inside a network

  3. Potential to consolidate services, for similar reasons that 
     web hosters like to run many virtual servers from one IP address

The proxy could choose to perform transformations on the ssh stream rather
than just passing it on.

--
Dan Shearer
Open Source Manager
Mob: +61 411 49 1800
Tel: +61 8 8130 3104
dan%tellurian.com.au@localhost