Re: draft-kwatsen-reverse-ssh submission for review

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



> 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.  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.



> > 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>


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.


Thanks,
Kent