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

Benoit Claise <> Thu, 16 March 2017 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 194761296CB; Thu, 16 Mar 2017 10:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X5P5ViqEjYPP; Thu, 16 Mar 2017 10:43:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A50201296FA; Thu, 16 Mar 2017 10:43:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8737; q=dns/txt; s=iport; t=1489686205; x=1490895805; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=dkhzIi2WkblxC/O3jBoUtXSpTHZFgPBd9UbCoeCQFtM=; b=S+EWcnlQFn+TQk4gNDVpbuemUyDNIUjQpBBg6por4XfJ3P7H4mLKSR5U kgETVLYUshoLKW70xCrm+4zJLV8pKxgKWnk4ReljXqw55YPkQhTmAkb8p vXn0nPCPiImTazOhRwpzGNiX66wIIWZbkpVZ8DwuXQMIiWcmKUBmDpytP g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.36,173,1486425600"; d="scan'208,217";a="650479244"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 17:43:21 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v2GHhKXT014717; Thu, 16 Mar 2017 17:43:20 GMT
To: Alia Atlas <>, Kent Watsen <>, "" <>, "" <>
References: <> <> <> <20170316072757.GD59114@elstar.local> <> <20170316075657.GF59114@elstar.local> <> <> <20170316135145.GB23450@elstar.local> <> <20170316143803.GB23686@elstar.local>
From: Benoit Claise <>
Message-ID: <>
Date: Thu, 16 Mar 2017 18:43:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20170316143803.GB23686@elstar.local>
Content-Type: multipart/alternative; boundary="------------184BC62530535F7C5500B4BA"
Archived-At: <>
Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Mar 2017 17:43:29 -0000

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