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

[Paul Hoffman <paul.hoffman%vpnc.org@localhost>]

On May 23, 2011, at 10:56 AM, Kent Watsen wrote:

>> I think both mailing lists should remain on the mail. The issues 
>> relate to both.
> 
> OK, we'll keep both on, just as the Security ADs originally suggested.
> 
> 
> 
>>> Yes. And will the need for a reverse port create a similar need for 
>>> every such  current SSH-based port assignment to have a corresponding 
>>> reverse-channel port assignment? That would be undesirable...
>> 
>> +1. A single reverse-port protocol that has a way to say "and I'm going 
>> to be doing X protocol" would be a much better design.
> 
> Sounds a little bit like the tcpmux protocol.  Do you think how SSH opens
> channels/subsystems is not good enough?   A proliferation of ports doesn't
> sound good, but others expressed a need for ports to support port-based
> firewall filters.  

Firewalls should adapt to good protocol design; protocol design should not be weakened to work with firewalls. (And I say this as someone who likes firewalls.)

> How many ssh-based protocols are there currently?  I 
> only know of two (SSH/SCP/SFTP:22 and NETCONF:830) - are there any others?  

You say that as if we never expect to have any more, which seems like poor planning. For example, many people run VNC and other such protocols on other ports. The "ssh -L 15901:localhost:5901 example.com" usage is quite common. Making it harder for protocols other than NETCONF to use SSH doesn't seem like a good plan at this point.

>> The design of this draft sounds like it can be summarized as "an entity
>> that is normally a client becomes a server for a short period while it
>> gets information from the entity that is normally a server". At the 
>> point that the was-a-client becomes a short-term server, why not make
>> it a real SSH server?
> 
> What does this means at a protocol level?  Does the application present a
> SSH host-key during DH key exchange and the device logs into the application
> via userauth?  - if so, then please realize that this is exactly what we're
> trying to prevent.  

I do realize that; I am proposing that what you are trying to prevent is in fact fine, and a lot more rational than a "I'm a kind-of-server for just a moment" design.

> We want the device to always be the peer that presents
> its SSH host key, whether due to the application connecting to its port 22
> or because the device connected to the app's Reverse SSH port.   Likewise,
> we always want the app to be the peer that userauth's to the device, 
> regardless how the transport was setup.

Understood. The draft does a reasonable job of matching that design.

>>> The particular roles of who checks what certificate should be negotiated
>>> in-band, IMO.
>> 
>> That sounds right to me.
> 
> This would only be necessary if there are no new port assignments as, 
> otherwise, each peer *knows* which role to assume.  For instance, each
> peer knows its role if started like this:
> 
>  app:     ssh --listen <rssh-port> --handler /usr/local/bin/myapp
>  device:  sshd --connect <app>:<rssh-port> --id 234230 --hmackey secret
> 
> 
> Otherwise, if there are no new port assignments (i.e. <rssh-port>==22),
> then we'd have to have in-band negotiation, perhaps by the device 
> sending a special identification string (RFC 4253, section 4.2) like
> this?
> 
>  SSH-2.0-OpenSSH_5.6 <SP> Reverse SSH <CR> <LF>

This assumes that all SSH use is only on the currently-assigned ports. That ignores the "-L" use case I gave above, as well as future protocols that want to run over SSH.

> If having in-band negotiation, then we should also extend the SSH 
> Protocol to support device identification and automatic authentication
> of host keys other than PGP and x.509 certificates, this is the 
> essence of the REVERSE-SSH-CONN-INFO message in the draft.


That is one design; another is "when I am acting like a server, I am actually a server". That seems a lot cleaner.

--Paul Hoffman