Re: [saag] draft-kwatsen-reverse-ssh-01 submission for review

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Wed, 2011-06-08 at 16:43 -0700, Kent Watsen wrote:
> I've updated the Reverse SSH draft per suggestions:
> 
>     - now uses IANA-assigned SSH port 22
>     - now defines proper client and server roles (Reverse SSH client, Reverse SSH server)

So, let's make sure I have this right.  A device "calling home" is going
to connect to some server on port 22, and expect the server to
immediately pick up the role of being an SSH client?

How is the server to distinguish between such a device and a normal ssh
client being used by an admin who wants to log in to the server?  Or by
some other protocol that runs over ssh?

I'm pretty sure I recall the discussion on this point involving some
sort of negotiation, rather than a requirement that both sides know a
priori which protocol variant they're going to speak.  In fact, I seem
to recall der Mouse suggesting use of a pre-kex extension packet to
indicate this.


>     - definition of a new family of public host key algorithms (hmac-*)

This is not the way to achieve what you're trying to do.  Nor is
specifying use of only particular host key algorithms, which rather
badly breaks modularity.  Further, what you've done doesn't actually buy
anything.  If the HMAC is precomputed before the device that will act as
SSH server is deployed, then there is no operational advantage over
X.509 certificates.  On the other hand, if the HMAC is computed at the
time of the connection, then both the client and server must know the
key _and_ there must be a different key for each client/server pair (so
one device cannot impersonate another).  In which case, you may as well
preshare per-device RSA keys instead of per-device HMAC keys.

Except in cases like X.509 (where a host key is associated with a
long-term signature by some trusted third party), SSH proves server
identity and authenticates host keys as part of key exchange.  If none
of the already-defined KEX methods are suitable for your needs, then it
might be possible to define a new one along the lines of what you've
described.  However, I seriously doubt its utility, for the reasons
described above.


It sounds to me like you really _don't_ want the device to be the SSH
server at all; you only think you do.  I suspect you really want the
device to be the SSH _client_, except that once the connection is up,
you want the server to open some sort of session to the client to
execute commands, transfer files, run netconf or SNMP, or whatever.

Interestingly, this role reversal -- allowing the SSH server to open
sessions and run commands on the SSH client, requires no change to the
SSH protocol at all.  It simply requires that the client sit around
waiting for a channel-open request from the server and accept it when it
comes around.  This is exactly the sort of situation in which it is
appropriate to behave contrary to the SHOULD in RFC4254 section 6.1.



FWIW, I'm fairly concerned about the hmac-* algorithms described in this
document, which don't seem to provide any guarantee of freshness.

I'm concerned that there is no description in this document as to how
the SSH client is expected to authenticate itself to the device.  This
is fairly important, particularly since in the described deployment
scenario, the device is likely about to give nearly unlimited power to
the SSH client.

Finally, I'm very concerned about the statements in the first paragraph
of section 7, which assert that the proposed role reversal does not
introduce any new security concerns.  On the contrary, the proposed
protocol is very nearly akin to calling someone up and saying "Give me
your password", later followed by "by the way, I might be your bank".

We've discussed "reverse SSH" ideas before*, and they haven't gained any
traction.  Part of the problem is that server and client authentication
is not symmetric in the SSH protocol, and there is a basic assumption
that a client knows a priori what server it intends to talk to, while
the server does not know what client will be talking to it.  Attempting
to falsify this assumption and still have things work typically results
in warping the protocol rather badly.

I'm not saying a reverse SSH is not possible, and with a few more
iterations this document might well become one.  However, as mentioned
above, I think it's probably not the right approach to solving the
stated problem.

-- Jeff