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

From: Mouse <[email-masked]>
Date: Sat, 29 Jun 2013 11:11:01 -0400 (EDT)

> The point is that before _any_ connection is ever started, an SSH
> client knows who the host is supposed to be.

Well, in some sense of "who".

> It uses that as a key into its database of host keys, if you're using
> a keyex method that uses host keys.

It may.  For a server to have a host key at all is only a SHOULD, not a
MUST.  So, for that matter, is checking it; skipping that is NOT
RECOMMENDED, not MUST NOT.

> You cannot discover the host's identity from anything that appears as
> part of the connection; you need to know in advance what it is
> supposed to be.

This is at most semi-true.  If a client does know a host key, then a
server presenting it (and passing the usual challenge) is evidence that
the server is the one the host key belongs to, evidence approximately
as strong as the security of that server against leaking the
corresponding secret data (or of the algorithm against its being
cryptanalyzed, whichever is weaker).  My own implementation, for
example, uses this to hint to the user that a key is known and thus the
connected-to host might actually be known by some other name; typical
behaviour in such a case might look like

% ssh somename
No ssh-rsa key known for somename/22
Host key: ssh-rsa [fingerprints]
Other hosts for which this key is known: othername/22 thirdname/20000 somename.example.com/22
Continue connecting? (yes/no/save/?) 

I have used this to discover what host is at an address I don't
recognize (at work I often deal with multihomed hosts, often with rDNS
missing for some or sometimes even all of their addresses).

Of course, that's not to say that I then proceed to type passwords into
such connections.  I will typically ^C out at the prompt in cases like
the above - and I normally never use password auth anyway, even when
talking to known hosts.

> This is why it's fairly important, in SSH, for the endpoint that
> originated the connection to be the one that is the SSH client.  The
> connection originator knows in advance who it thinks it is going to
> talk to, which SSH requires,

I'm not convinced it does.  Require it, that is.  The security
properties of such use are not well studied, at least not as far as
I've seen, but it certainly can be done.

> whereas the endpoint accepting the connection does not -- it needs to
> decide whether whoever did connect is authorized.

True.  But I see no obvious reason why this can't be done via the usual
"authenticate (SSH) server to (SSH) client" mechanisms.

This may sound as though I'm arguing in favour of reverse SSH.  In a
sense perhaps I am; I certainly am arguing that it's not obviously
ludicrous.  I am far from convinced it's safe enough to standarize, but
I'm also far from convinced it's out of the question.

> Once an ssh connection is established, _channels_ can be opened by
> either end, at will.  In practice it generally only makes sense to
> open some kinds of channels in one direction or the other, but the
> protocol imposes no constraints here.

This is, of course, true, and I note that the existing implementations
do just that, for forwarded TCP connections if nothing else.

/~\ 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: Ladislav Lhotka <[email-masked]>
Date: Wed, 3 Jul 2013 14:54:32 +0200

[NETCONF list only]

Hi,

a colleague of mine proposed to define XMPP as a new transport for NETCONF. This would certainly solve the "calling home" issue, and may have other use cases, such as offloading authentication from the devices. The idea is to use a (dedicated) XMPP server as a proxy to which both NETCONF server and client connect as XMPP clients.

Looking into XMPP spec (RFC 6120), the protocols seems to be a perfect fit for transporting NETCONF. Strictly speaking, it doesn't satisfy the requirements of 6241 in that there is no direct connection between the NETCONF server and client, but IMO it could work fine even without it.

So I wonder - has anybody considered this option? At least one router vendor (Arista) does this, though not with NETCONF.

Lada

On Jun 29, 2013, at 1:23 PM, t.petch <[email-masked]> wrote:

> ---- Original Message -----
> From: "Kent Watsen" <[email-masked]>
> To: "t.petch" <[email-masked]>; "Martin Bjorklund" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Friday, June 28, 2013 10:26 PM
> On 6/26/13 1:36 PM, "t.petch" <[email-masked]> wrote:
> 
>> Yes, that I understand.
>> 
>> But ... the firewalls I know, at least the better ones, can look for
> and
>> reject PDU of protocols such as SSH, regardless of which ports the TCP
>> connection is using.  So in that sense, a device behind a firewall that
>> filters SSH connections still cannot be accessed.  Is this an
> acceptable
>> limitation?
> 
> I would think so - this is what Juniper has been doing for almost a
> decade
> now and I've never heard this raised as an issue before.
> 
>> My other point is that I cannot see how this is a generic solution as
>> the I-D claims.  You need something to signal that this three-way TCP
>> handshake is for Netconf over SSH and the only parameter I can see is
>> the port number, so this I-D cannot be used for anything else over
>> anything else; each combination of protocols will need a different port
>> number.
> 
> By "generic", the draft is trying to say that the solution applied to
> solve this problem can equally well be applied to other protocols that
> use
> SSH for their transport.
> 
> <tp>
> OK, so it is limited to reverse SSH (as opposed to a generic call home)
> and that is what the I-D says, so that is ok.
> 
> But ... I would like to see a note added that the server/device must be
> prepared to receive any SSH PDU and act appropriately and not just
> assume it is netconf.  I am wondering if there is a Security
> Consideration in there somewhere but cannot put my finger on one.
> 
> Tom Petch
> 
> </tp>
> 
> That said, I'll just add that the port number does not have to be bound
> to
> how the application might use the SSH connection.  For instance, when a
> Junos device connects to our management server, yes, it knows it can
> open
> the "netconf" subsystem, but it also knows all the other subsystems it
> can
> start...and it does!  For instance, it will open additional SSH channels
> for SFTP, notifications, packet captures, etc.  It would've been easier
> if
> SSH defined a subsystem-discovery mechanism, but we worked around that
> too.
> 
> Thanks,
> Kent
> 
> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C