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

From: "ietfdbh" <[email-masked]>
Date: Wed, 19 Jun 2013 10:02:21 -0400

Hi Kent,

I think your draft needs to target two different audiences - the security
audience for SSH security considerations, and application designers that
want to use reverse-SSH, such as Netconf.

Few people are experts both in hmac and SSH, and in Netconf and YANG.
I think this would be better written as two separate drafts, with different
audiences in mind, even if each draft would be short.

David Harrington
[email-masked]
+1-603-828-1401
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Wednesday, June 19, 2013 4:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-netconf-reverse-ssh-00.txt

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-00.txt
	Pages           : 16
	Date            : 2013-06-18

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 Jun 2013 13:21:56 -0400

> want to use reverse-SSH, such as Netconf.

This was discussed two years ago on the ietf-ssh mailing list, which is
the appropriate forum for discussion of SSH extensions and protocol
changes.  There was much discussion about what port number things should
run on, but unfortunately relatively little discussion of the security
aspects of running SSH "in reverse" like this.

I haven't read this recent document, but when this came up in 2011, I
was concerned about the security aspects of running SSH "in reverse"
like this; it's really not designed for that.  I expressed concerns
about the new hmac-* host key algorithms defined in that version, about
the layering violations inherent in using them for negotiation, and
commented that they don't really provide any operational advantage over
using X.509 certificates or pre-shared RSA keys.  Those comments were
never really addressed.

The SECSH WG concluded some time ago, but its mailing list is still
somewhat active and regularly discusses SSH protocol extensions.  I
would be very concerned if the NETCONF WG were to send the IESG an SSH
protocol document without the involvement of that group.  I will note
that the 2011 discussion included approaches that did not require this
level of protocol change, or indeed any.  I'm fine with NETCONF not
having chosen one of those approaches, but this really does need to
involve people with SSH expertise.

-- Jeff

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 19 Jun 2013 21:19:58 +0200

For anyone who wishes to access/subscribe to the secsh mailing list,
See http://www.ietf.org/wg/concluded/secsh.html

Jeff, I assume that is the list you refer to??

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Wednesday, June 19, 2013 7:22 PM
To: ietfdbh
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [saag] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt

On Wed, 2013-06-19 at 10:02 -0400, ietfdbh wrote:
> Hi Kent,
> 
> I think your draft needs to target two different audiences - the 
> security audience for SSH security considerations, and application 
> designers that want to use reverse-SSH, such as Netconf.

This was discussed two years ago on the ietf-ssh mailing list, which is the appropriate forum for discussion of SSH extensions and protocol changes.  There was much discussion about what port number things should run on, but unfortunately relatively little discussion of the security aspects of running SSH "in reverse" like this.

I haven't read this recent document, but when this came up in 2011, I was concerned about the security aspects of running SSH "in reverse"
like this; it's really not designed for that.  I expressed concerns about the new hmac-* host key algorithms defined in that version, about the layering violations inherent in using them for negotiation, and commented that they don't really provide any operational advantage over using X.509 certificates or pre-shared RSA keys.  Those comments were never really addressed.

The SECSH WG concluded some time ago, but its mailing list is still somewhat active and regularly discusses SSH protocol extensions.  I would be very concerned if the NETCONF WG were to send the IESG an SSH protocol document without the involvement of that group.  I will note that the 2011 discussion included approaches that did not require this level of protocol change, or indeed any.  I'm fine with NETCONF not having chosen one of those approaches, but this really does need to involve people with SSH expertise.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 Jun 2013 15:37:50 -0400

> Jeff, I assume that is the list you refer to??

Yes, that's the group, and [email-masked] is/was the mailing list.
The IETF archives are still subscribed, last time I checked.

-- Jeff

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jun 2013 20:16:54 +0000

Hi David,

Thanks for your comments.

My suggestion for partitioning this draft is to extract the
hmac-* family of public host key algorithms into its own draft.
There is precedent for defining new public key algorithms in a
distinct draft given by RFC 6187.  However, this strategy would
retain the YANG module definition in the current draft and thus
doesn't address your stated concern.  That said, please consider:

  1. It is generally hoped that the design of any device
     feature (e.g. a routing protocol) includes a YANG module
     for how it can be managed.  Keeping the YANG module
     definition in this draft is consistent with that goal.

  2. The configuration model has no impact on the protocol
     and hence can be ignored by those who are only interested
     in the protocol/security aspects.  The draft almost says
     this itself in the first paragraph of section 6 (Device
     Configuration).

Another option would to extract the YANG module definition into
its own draft.  As you say, it would be very small, but at least
it would be focused.

And, of course, we could do both options - resulting in a total
of three distinct drafts.

Which of these options you think is best?

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Jun 2013 22:03:20 +0000

Hi Jeff,

You've touched on a lot of points.

First, yes, this was discussed a couple years ago.  I wanted this
submission to indicate it was a continuation of the previous I-D
draft-kwatsen-reverse-ssh-01.  That it doesn't is only because
I didn't see an option to indicate that during submission - I'll
check again...

The discussion from two years ago died because no common ground
could be reached.  It has resurfaced now because operators have
requested the NETCONF WG to define strategies for devices to
"call home" using both NETCONF's transports, SSH and TLS.  The
NETCONF WG has now chartered this work and I volunteered to pick
it up again.

>From a protocol perspective, the solution presented in this draft
is the same as presented in draft-kwatsen-reverse-ssh-01 with one
exception, it now requests an IANA-assigned port, instead of using
port 22, to be consistent with draft-ietf-netconf-rfc5539bis-03,
which makes the same request.

Regarding the security aspects of running SSH "in reverse", this
draft's Security Considerations section has been greatly expanded
to address this concern and I very much hope that the SAAG will
take it up now.  I also hope SAAG will consider the security
aspects of running TLS "in reverse", as one of my comments on
rfc5539bis-03 [1] was that doing so would enable the "client" to
defer sending its client-certificate until after receiving the
server's cert, consistent with draft-agl-tls-encryptedclientcerts
and draft-badra-tls-identity-protection.  Though both of these
drafts are now defunct, it seems that there's sufficient interest
in protecting the client's identity, which a TLS-based "call home"
could only leverage someday if it ran TLS "in reverse" as well.

Finally, regarding the HMAC-* family of public host key algorithms,
I think herein lies a good reason to extract them into a draft of
their own, as it would be a shame for them to distract from the
primary discussion of running SSH (and TLS) in reverse.

[1] http://www.ietf.org/mail-archive/web/netconf/current/msg08075.html

Thanks,
Kent

On 6/19/13 1:21 PM, "Jeffrey Hutzelman" <[email-masked]> wrote:

>>security

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jun 2013 15:13:22 -0700

> which makes the same request.

Hi, all,

I was party to the discussion of this issue during the original draft 
(see archives of 5/24/2011), and thought there was appreciation that 
there was no reason to need a new port for this service.

Regarding the netconf draft, that might warrant a single port, but again 
not two ports for the different directions.

As I noted on this list in 2011, directionality should be negotiated 
in-band, not by port number.

Joe

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 Jun 2013 18:23:53 -0400

> which makes the same request.

Given the previous discussion about port numbers, I think that's both
prudent and unfortunate.  It would be nice to be able to multiplex
everything on one port, but the reality is that the netconf application
that a device is connecting to is unlikely to have anything to do with
the SSH server running on the same machine.  However, unless I'm
misunderstanding the intent here, using a fixed port at all seems
limiting to me.  What if I'm running two different applications on my
machine, and expect different devices to connect to them, or even the
same device to both?  What if there are other people sharing my machine?
Shouldn't be port be either one dynamically assigned to the application
by the OS, or configured by an administrator?

> take it up now.

OK; I'll try to find some time to re-review it, then.  In the meantime,
it would probably be good to bring this document up on the ietf-ssh list
again.

> primary discussion of running SSH (and TLS) in reverse.

Yes, I think that's a good idea.  These should be able to be treated
independently.

-- Jeff

---

From: Kent Watsen <[email-masked]>
Date: Thu, 20 Jun 2013 00:37:53 +0000

>there was no reason to need a new port for this service.

This is why the -01 draft from before was using port 22, but
the problem is that there will be a conflict if the application
may want to run real SSH on port 22.

>not two ports for the different directions.

The same principle applies here.  Yes, we could repurpose the
NETCONF port (830), but then there will be a port conflict if
the application server itself wants to be managed via NETCONF
on port 830.  Besides, this draft is truly about reversing SSH,
any SSH subsystem could be run on top of it...

>in-band, not by port number.

This seem fine (assuming it's done in the SSH Transport protocol,
such the device is the SSH server and the application is the SSH
client), except for one thing, it's not implementable *today*.
Optimistically, it might take a couple years for implementations
to support it, if ever.  Case in point, did you know that after
more than two years, there is still not a single implementation
for RFC 6187 (x.509v3 certs for SSH)?

In contrast, I have running code for the solution presented in
the current draft that I hope to post to code.google.com as a
reference implementation.  Mind you that this implementation
doesn't make use of all the the host-key algs we'd like, but
it works with at least two SSH-implementations (Petrov's patch
to OpenSSH and a Java library called J2SSH Maverick).

A little off topic, but the -00 draft I submitted before, in
2011, worked with *every* SSH implementation I tried, without
any patches necessary.  But I chose to model this draft after
the -01 proposal because I believe it's better to leverage the
algorithm negotiation built into SSH and I have running code
for the common case of the device running openssh and the
management app written in Java.

Thanks,
Kent

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jun 2013 18:02:26 -0700

> may want to run real SSH on port 22.

Why is this a conflict in that way? It's just a matter of who initiates 
the connection, and who initiates the security exchange after that. 
I.e., why wouldn't this be most naturally implemented as "real SSH on 
port 22"?

> on port 830.

The same answer above applies.

>  Besides, this draft is truly about reversing SSH,

I understand why it has not yet been *implemented*, but disagree that it 
is not *implementable*.

> to OpenSSH and a Java library called J2SSH Maverick).

I sincerely hope you are posting code that uses some arbitrary dynamic 
port, rather than squatting on an assigned port.

However, it would be useful to explain further the issue here. So far, 
all I can tell is that it would be easier to pull up a demo 
implementation using a separate port, but there doesn't seem to be 
enough justification as to why this is a separate *service* than forward 
SSH.

Joe

---

From: Kent Watsen <[email-masked]>
Date: Thu, 20 Jun 2013 01:23:20 +0000

On 6/19/13 6:23 PM, "Jeffrey Hutzelman" <[email-masked]> wrote:

>However, unless I'm

Indeed, it is not uncommon for deployments to use non-standard ports.
For this reason, the YANG module presented in the Device Configuration
section defines the <port> field as optional, stating that the IANA-
assigned port is assumed if it's not filled in.

>it would probably be good to bring this document up on the ietf-ssh list

Very much looking forward to your review of the Security Considerations.
If at all possible, please also try to expand your review to the
possibility of reversing the TLS protocol in the same fashion (i.e. The
TCP client becomes the TLS server, and visa versa).

As for the ietf-ssh list, I know you're right, but we have a problem, the
mail archives have half of today's messages under the NETCONF list and
half under the SAAG list:

   http://www.ietf.org/mail-archive/web/netconf/current/maillist.html
   http://www.ietf.org/mail-archive/web/saag/current/maillist.html

Worse, at least one message shows up under both archives and clicking the
"Follow-Ups" links drops some of the responses because they're in the
other group's archive.  This will make it very hard for someone to piece
together the exchange that has occurred so far.  Suggestions?

Thanks again,
Kent