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

[Kent Watsen <[e-mail]>]

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


> 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