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

[Kent Watsen <[e-mail]>]

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" <[e-mail]> wrote:

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