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

From: Benoit Claise <[email-masked]>
Date: Fri, 21 Apr 2017 18:30:37 +0200

Dear all,

The new YANG module security guidelines have been posted, in agreement 
with our SEC AD Kathleen.
See https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Regards, Benoit
> 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
>>
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod