Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-01.txt

----- Original Message -----
From: "Niels Möller" <[email protected]>
To: "Mouse" <[email protected]>
Cc: "Kent Watsen" <[email protected]>; <[email protected]>
Sent: Wednesday, June 26, 2013 8:00 AM
Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-01.txt


[ Feel free to forward this message whereever appropriate ]

Mouse <[email protected]> writes:

> I don't see why the netconf client has to be the one to initiate the
> subsystem open.

I agree. The draft draft-ietf-netconf-reverse-ssh-01 says

  It is necessary because SSH channels and subsystems can only be opened
  on the SSH Server.

That is plain wrong. E.g., channels of type "forwarded-tcpip" are
normally opened by the server. As for channels of type "session", used
for the subsystem request, the ssh spec says (RFC 4254, section 6.1):

<tp>
What Kent is saying on the Netconf list is that the devices are behind a
firewall which does not allow inbound SSH connections ie the
device/Netconf server must initiate the SSH connection (although not
necessarily the TCP connection).  I cannot see this in the current I-D
so I am confused as to what requirements this design is meeting.

And when the device does initiate the SSH connection then, arguably, the
security properties are wrong, as got discussed last time this came up
(and also in ISMS).  They may be right for alerts, that the NMS can know
that the alert came from a trusted device, but are wrong for
configuration, when the device needs to know it can trust the NMS.

What follows below is a fine addition to SSH, except that it does not
meet the requirements, as I understand them, of Netconf call home.

Tom Petch
</tp>

   Client implementations SHOULD reject any session channel open
   requests to make it more difficult for a corrupt server to attack the
   client.

netconf may well have a perfectly reasonable use-case for deviating from
that "SHOULD".

The SSH protocol is pretty flexible. It's also possible to have the
client initiate the channel open, and still have the server issue the
subsystem request. Or have the client initiate both the channel open
*and* the subsystem request, but define the meaning of that subsystem so
that it is the client that actually starts the "server" end of the
subsystem (the channel is just a bidirectional pipe, it doesn't matter
for the ssh protocol which end is connected to a "server"). Or introduce
a new channel type rather than using a "session" channel and a subsystem
request.

I think there are several ways of solving the problem which are both
simpler and more in the spirit of the ssh protocol, than introducing
some "role reversal" of the ssh *transport* layer.

After thinking for some 10 minutes about the problem, I think I'll
suggest the following: Introduce a new channel type "reverse-session".
It will work exactly like a "session" channel, except that the party
opening the channel expects the remote end to issue a "shell", "exec" or
"subsystem" request, and that any SSH_CHANNEL_EXTENDED_DATA messages
(for stderr) is sent in the same direction as the initial channel open
request.

As far as I understand, not doing protocol reversal seems to also
simplify authentication for netconf. Authenticating the server, which is
going to control the client, is done using ssh host authentication
mechanism in the ssh transport layer, and that's going to be important
for security.

Authenticating the client would be using the ssh user authentication
layer, but I imagine that in many cases that will not even be necessary.
I'd expect that the common case is that an attacker can't get any
benefit from configuring a "rogue" device, have that device call in to
the server, and say "please control me!". And that the server doesn't
trust any device anyway, authenticated or not.

Best regards,
/Niels

--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.