Subject: [Netconf] Call Home for Notifications

From: Balazs Lengyel <[email-masked]>
Date: Tue, 11 Dec 2012 14:32:55 +0100

Hello,
On the last IETF the Call-Home feature (netconf session started by the 
managed node) was again raised. What is the situation with this.
Way back there where at least two ideas:
1) Start the SSH session and the Hello exchange from the managed node. 
This could also be done via TLS now.
2) Send an SNMP notification to the Netconf client to ask it to start a 
Netconf notification session

As I remember it was security problems that stopped call-home from 
happening.
Does anyone remember details? Is there interest to restart this issue?

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Phil Shafer <[email-masked]>
Date: Tue, 11 Dec 2012 08:52:35 -0500

>Netconf notification session

The connection has to come from the managed node, since we want
to be able to pass thru NAT and 6to4 gateways.

>Does anyone remember details? Is there interest to restart this issue?

Kent Watsen was persuing this with the SSH group, since it's a
generic facility.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Dec 2012 15:23:02 +0100

> >This could also be done via TLS now.

The TLS update may provide an answer for the TLS transport. With TLS
and certificates on both ends, it should not matter too much which
side is initiating the connection. But of course, I am not a security
expert, so this may need further checking.

With SSH, the situation is complicated due to its two very different
ways to authenticate the server and the client.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Dec 2012 17:19:53 +0000

Regrading the asymmetry in SSH client/server authentication, the crux of
the Reverse SSH protocol is to ensure that the device is *always* the
SSH-server and the NMS is *always* the SSH-client, regardless of which
side initiats the underlying TCP connection.   Thus there isn't any
"complication" to be concerned about.

To answer Balazs' original question, my plan is to publish a reference
implementation of Reverse SSH to code.google or sourceforge .  I should've
done this long ago, but it keeps getting preempted.  FWIW, I discussed
this with my CTO a couple days ago, so he knows that it's pending...

K.

On 12/11/12 9:23 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Dec 2012 21:20:52 +0100

> "complication" to be concerned about.

Back im ISMS days, some security folks argued that even then this is
not the same. The reasoning, as far as I understood it and recall it,
which may be completely wrong, was that in the normal case, the client
has a clear idea to which host it wants to connect and then the client
can check the discovered host key against what was expected. If you
turn this around, the 'client' gets presented with a host connecting
and since the initiative come from the remote entity, the client has a
harder time to decide whether the host is meaningful to engage into a
conversation with. This may sound like an artificial philosophical
argument, perhaps it is, perhaps it is just my poor recollection and
paraphrasing of it.

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 12 Dec 2012 15:24:15 -0500

>argument, perhaps it is, perhaps it is just my poor recollection and

Does having the device pre-configured with the hostkey of the manager
help?  It then knows that the incoming connection is from someone that
it's supposed to be talking with.

Thanks,
 Phil

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Dec 2012 21:30:25 +0000

>it's supposed to be talking with.

Assuming you meant host key of the *device*, absolutely, but
draft-kwatsen-reverse-ssh takes it a step further by enabling trust in the
host-key to be learned, per it being cryptographically signed with
something the manager trusts.

Juergon, I'm familiar with the need for TLS clients to verify a
certificate's subject matter matches expectations, as it is prudent to
validate the identity your peer.  In the case of device-initiated
connection, there is still a desire to validate its identity, though it
may take on other forms including serial-number, hash(serial-number),
ip-address, and/or fqdn.  Ideally the manager has some precognition of one
of these, but this may not always be possible.  This is why
draft-kwatsen-reverse-ssh introduced the ability for a CA to sign the
device's credentials, thus enabling a manager to extend its trust for the
CA to the device, even if never seeing its identity before.

FWIW, neither the IETF-SSH nor SAAG raised any security concerns when
discussing draft-kwatsen-reverse-ssh, though this may be due to them being
too preoccupied with protocol-purity and never getting to think about it ;)

K.