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

[Benoit Claise <[e-mail]>]

Dear all,

As discussed during the IESG telechat today, we should only focus on the 
addition of the RESTCONF bits, and not attempt to include the I2RS 
future protocol now.
Hence this minimum change proposal:

          The YANG module defined in this document is designed to be
          accessed via network management protocols such as NETCONF
          [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the
          secure transport layer, and the mandatory-to-implement secure
          transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF
          layer is HTTPS, and the mandatory-to-implement secure
    transport is
          TLS [RFC5246].

          The NETCONF access control model [RFC6536] provides the means to
          restrict access for particular NETCONF or RESTCONF users to a
          pre-configured subset of all available NETCONF or RESTCONF
          protocol operations and content. 

Regards, Benoit
> 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
>