Re: [OPSAWG] [Netconf] guidance on draft-kwatsen-reverse-ssh

----- Original Message -----
From: "Kent Watsen" <kwatsen@juniper.net>
To: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>;
<f@elstar.local>
Cc: <opsawg@ietf.org>; <netconf@ietf.org>
Sent: Wednesday, July 13, 2011 9:26 PM
>
> > There is some history of this discussion in the ISMS working group.
> > When ISMS did SNMP over SSH, we had a hard time dealing with
> > notifications and the Juniper approach was already put on the table at
> > that time as "running code that seems to work in practice to solve an
> > operational problem". As far as I recall, there was no doubt about the
> > operational problem and the need to solve it _but_ there were security
> > concerns brought forward. I would have to do several hours of reading
> > of ISMS archives in order to phrase them correctly. But simply put (as
> > far as I recall - and I don't really recall any details and so I might
> > be totally off), the concern had to do with something not truely
> > authenticated to tell a box to SSH somewhere which involves the usage
> > of identities with cryptographic keys. In ISMS, we ended up making the
> > notification originator the SSH client - and this caused quite some
> > costs since the amount of config increases and the identity to bind
> > access control to becomes different.
>
> As a security person myself, I'm fairly confident that the "Juniper approach"
is OK.  We've also had numerous security folks look at it as well as the US
government (it's FIPS certified) and Tier-1 SPs...
>
> The only security issue raised so far by the SAAG and IETF-SSH lists was
regarding the new HMAC family of host-key algorithms defined in the -01 draft.
By nature, it requires a symmetric key and they didn't see how a symmetric-key
could be provided in a first-time "call-home" scenario.  Of course, the
symmetric key can be provided to the device, either keyed in or read off a USB
pen-drive...
>
> > So in essence, I believe we have been for years at a deadlock
> > situation where operational people were clear that a solution for
> > devices to "call home" is clearly needed but the security people had
> > security concerns with the solutions presented and the solutions liked
> > more by security people to be operationally a pain.
>
> Exactly.

Kent

My recollection is somewhat different to Juergen's.

Call home was requested by Eliot Lear but did not get much support in isms WG.

Sam Hartman, as AD, ruled it out of scope since the WG already had a lot to do,
the charter was to add security to SNMPv3 and not to introduce functions that
SNMPv3 did not have (like call home).  You will find this in the archives in
August 2005, particularly around August 18th.

For myself, I have always thought it obvious that the direction, client-server,
of
the TCP layer can and should be decoupled from that of the security layer, SSL,
SSH, TLS ... but whenever I have proposed that, I have not got much support:-(

Tom Petch

> > Perhaps one path forward is to have the operational people push a
> > solution that is implementable and solves an operational problem
> > (without creating a new operational problem) through the whole IETF
> > process forcing the security people to clearly document their security
> > concerns and then it can be seen whether that text all goes into the
> > Security Considerations and the protocol passes or the document stops
> > at the IESG. This is potentially a painful exercise.
>
> As painful as it may be, I think this is our best-case scenario.  We could
push it forward as an independent submission (EXPERIMENTAL?), but it would be
much better if either the NETCONF and OPSAWG WGs could sponsor it.  Personally,
I still agree that it's not NETCONF-specific and hence not for the NETCONF WG,
but it makes sense for OPSAWG, if the WG agrees...
>
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf