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

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Jun 2013 20:16:49 +0000

FYI, this -01 update simply removes the hmac-* family of public host key
algorithms, since they were distracting from the primary focus of the
document and can be easily defined in a draft of their own, at anytime,
without affecting the remaining draft's validity.

For ietf-ssh and saag list members, yesterday we had a snafu with the
mail-archives because messages were being sent to multiple lists.  If you
want to reply, please consider joining the NETCONF mailing list so we can
keep the discussion in one place.

Thanks,
Kent

On 6/21/13 9:33 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Network Configuration Working Group of
>the IETF.
>
>	Title           : Reverse Secure Shell (Reverse SSH)
>	Author(s)       : Kent Watsen
>	Filename        : draft-ietf-netconf-reverse-ssh-01.txt
>	Pages           : 13
>	Date            : 2013-06-20
>
>Abstract:
>   This memo presents a technique for a NETCONF server to initiate a SSH
>   connection to a NETCONF client.  This is accomplished by the NETCONF
>   client listening on IANA-assigned TCP port YYYY and starting the SSH
>   client protocol immediately after accepting a TCP connection on it.
>   This role-reversal is necessary as the NETCONF server must also be
>   the SSH Server, in order for the NETCONF client to open the IANA-
>   assigned SSH subsystem "netconf".
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-reverse-ssh-01
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: Mouse <[email-masked]>
Date: Fri, 21 Jun 2013 23:32:22 -0400 (EDT)

[Feel free to forward elselist as seems appropriate; after what saag@
started doing, I'm disinclined to subscribe to more @ietf.org lists.]

>>   This memo presents a technique for a NETCONF server to initiate a
>>   SSH connection to a NETCONF client.  This is accomplished by the
>>   NETCONF client listening on IANA-assigned TCP port YYYY and
>>   starting the SSH client protocol immediately after accepting a TCP
>>   connection on it.  This role-reversal is necessary as the NETCONF
>>   server must also be the SSH Server, in order for the NETCONF
>>   client to open the IANA-assigned SSH subsystem "netconf".

I don't see why the netconf client has to be the one to initiate the
subsystem open.  It seems to me it does less violence to ssh for the
netconf server to be the ssh client (and conversely of course), with
the netconf protocol designed to know that the ssh roles are reverse
from the netconf roles.  (If the netconf subsystem is too standardized
for this at this point, that seems to me like a reason to define a new
subsystem that works more usefully.)

Note that the ssh server on the netconf client does not necessarily
have to also operate as a normal ssh server; it might, for example,
refuse shell and exec requests and all subsystems except netconf.

Am I just revealing my ignorance of netconf here?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: [email-masked] (Niels Möller)
Date: Wed, 26 Jun 2013 09:00:23 +0200

[ Feel free to forward this message whereever appropriate ]

Mouse <[email-masked]> writes:

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

   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.

---

From: t.petch <[email-masked]>
Date: Wed, 26 Jun 2013 10:44:53 +0100

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

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

Best regards,
/Niels