Re: [netmod] security considerations boilerplate updates to cover RESTCONF

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Mar 16, 2017 at 10:13:18AM -0400, Alia Atlas wrote:
> >
> > Keep in mind that I2RS believes in a requirement for cleartext
> > transport protocols. Perhaps this never makes it through the IESG but
> > so far it was not possible to stop this...
> >
> 
> This is solely for notifications that can be sent, just as IPFIX
> information may
> be sent unencrypted.  Those requirements are in
> draft-ietf-i2rs-protocol-security-requirements-17
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/>,
> which is in the RFC Editor queue.
>

   The new features are priority, an opaque secondary identifier, and an
   insecure protocol for read-only data constrained to specific standard
   usages.

   The optional insecure transport can only be used
   restricted set of publically data available (events or information)
   or a select set of legacy data.  Data passed over the insecure
   transport channel MUST NOT contain any data which identifies a
   person.

I think your statement that it is only for notifications is wrong.
The fact that some data ships in a notification does not mean the data
is not sensitive. Furthermore, I think we all meanwhile know that
IPFIX data is highly sensitive if you have the right context
information (so the analogy is flawed). And what the heck is a 'select
set of legacy data'?

      SEC-REQ-06: An I2RS agent receiving an I2RS message over an
      insecure transport MUST confirm that the content is suitable for
      transfer over such a transport.

An agent can't decide this. It is the context information that often
decides whether a piece of information is sensitive or not. So the
only decision an agent can do is to only allow messages with empty
content over an insecure transport.

   The I2RS architecture defines three scopes: read, write, and
   notification scope.  Insecure data can only be used for read scope
   and notification scope of "non-confidential data".

I understand that the IESG approved the security requirements. I do
not know why the security ADs did let this pass - perhaps since the
document is just about requirements and they will look closer at a
solution and then ask questions what 'non-confidentail' data' is, what
a 'select set of legacy data' is, or how an agent confirms that the
content of messages is suitable for an insecure transport.

Anyway, this does not belong here, the point I wanted to make is
simply that Kent's assumption that a protocol transporting YANG
defined data is always protecting the data is not true from the
viewpoint of the I2RS proponents. Thanks for confirming this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>