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

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Mar 2017 22:25:37 +0100

Hi,

this came up during IESG processing of a YANG module - is there a new
security guideline boilerplate text covering RESTCONF? This was
briefly discussed on the yang-doctors but somehow the discussion
stopped because RESTCONF was not published yet at that time. I think
this affects draft-ietf-netmod-rfc6087bis-12.txt.

draft-ietf-netmod-rfc6087bis-12.txt has several pointers to read
online documents - why do we need several points? I think some are
also not working. Ideally, there should be a single stable URL.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 15 Mar 2017 17:45:24 +0100

Dear all,

[copying the security ADs to make sure the new security section is fine]
Let's separate the two issues

1. the multiple URLs in draft-ietf-netmod-rfc6087bis-12.txt
Basically, I agree with Jürgen
I see section 4.7:

        This section MUST be patterned after the latest approved template
        (available athttp://trac.tools.ietf.org/area/ops/trac/wiki/
    <http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>
        yang-security-guidelines
    <http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>).Section 7.1
    <https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-7.1>  contains the security
        considerations template dated 2013-05-08.  Authors MUST check the WEB
        page at the URL listed above in case there is a more recent version
        available.

Then, I see section 7:

       The following section contains the security considerations template
        dated 2010-06-16.

Not sure why it contains this cut/paste? It should just say: the latest 
version is at this URL.
Then, I see in the same section:

    This section MUST be patterned after the latest approved
        template (available at

         http://www.ops.ietf.org/netconf/yang-security-considerations.txt

This page is not found.
This should be corrected in rfc6087bis.

2. the new security guidelines must include RESTCONF.
At this point, this is a blocking factor for the publication of YANG 
module. As an example,
draft-ietf-lmap-yang-11 
<https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/>, A YANG Data 
Model for LMAP Measurement Agents, on the telechat tomorrow.
As mentioned the most up to date version is 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Here is the proposal, discussed on the YANG doctors list:

             OLD

        The YANG module defined in this memo is designed to be accessed
        via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is
        the secure transport layer, and the mandatory-to-implement
        secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF
        access control model [RFC6536] provides the means to restrict
        access for particular NETCONF users to a pre-configured subset
        of all available NETCONF protocol operations and content.

        NEW

        The YANG module defined in this memo is designed to be accessed
        via the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The
        lowest NETCONF layer is the secure transport layer, and
        mandatory-to-implement is Secure Shell (SSH) [RFC6242], while
        the lowest RESTCONF layer is HTTP, and the
        mandatory-to-implement secure transport is Transport Layer
        Security (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.

Any objections?
Have covered all that we need for the new RESTCONF protocol?

Regards, Benoit

---

From: "Mehmet Ersue" <[email-masked]>
Date: Wed, 15 Mar 2017 18:09:07 +0100

Looks good to me. 

However, I think we should change:

s/and mandatory-to-implement is Secure Shell/

and the mandatory-to-implement secure transport is Secure Shell/

Mehmet

From: netmod [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, March 15, 2017 5:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] security considerations boilerplate updates to cover
RESTCONF

Dear all,

   This section MUST be patterned after the latest approved template
   (available at http://trac.tools.ietf.org/area/ops/trac/wiki/
<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines> 
   yang-security-guidelines
<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines> ).
Section 7.1
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-7.1>
contains the security
   considerations template dated 2013-05-08.  Authors MUST check the WEB
   page at the URL listed above in case there is a more recent version
   available.

Then, I see section 7: 

 

This page is not found.

2. the new security guidelines must include RESTCONF.
At this point, this is a blocking factor for the publication of YANG module.
As an example, 

draft-ietf-lmap-yang-11
<https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/> , A YANG Data Model
for LMAP Measurement Agents, on the telechat tomorrow.

        OLD

The YANG module defined in this memo is designed to be accessed via the
NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport
layer, and the mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The NETCONF access control model [RFC6536] provides the means to
restrict access for particular NETCONF users to a pre-configured subset of
all available NETCONF protocol operations and content.

NEW

The YANG module defined in this memo is designed to be accessed via the
NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest NETCONF layer
is the secure transport layer, and mandatory-to-implement is Secure Shell
(SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the
mandatory-to-implement secure transport is Transport Layer Security (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.

Any objections?

Regards, Benoit

Hi,

 
/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 15 Mar 2017 17:32:32 +0000

Benoit,

I fixed this text in my drafts already.  Actually, I found the old text difficult to
read, so I fixed it like this:

   The YANG module defined in this document is designed to be accessed
   via YANG based management protocols, such as NETCONF [RFC6241<https://tools.ietf.org/html/rfc6241>] and
   RESTCONF [RFC8040<https://tools.ietf.org/html/rfc8040>].  Both of these protocols have mandatory-to-
   implement secure transport layers (e.g., SSH, TLS) with mutual
   authentication.

   The NETCONF access control model (NACM) [RFC6536<https://tools.ietf.org/html/rfc6536>] provides the means
   to restrict access for particular users to a pre-configured subset of
   all available protocol operations and content.

   (from: https://tools.ietf.org/html/draft-ietf-netconf-keystore-01#section-4).

Related, I wasn't entirely sure how to handle the situation where a draft uses
groupings from another draft.  Does it simply point to the other draft's Security
Considerations, or recreate them in its Security Considerations section?  For now,
I chose the former, for instance:

   The YANG module defined in this document uses groupings defined in
   [I-D.ietf-netconf-ssh-client-server<https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#ref-I-D.ietf-netconf-ssh-client-server>] and [I-D.ietf-netconf-tls-client-server<https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#ref-I-D.ietf-netconf-tls-client-server>].
   Please see the Security Considerations section in those documents for
   concerns related those groupings.

   (from: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#section-5)

Thanks,
Kent  // contributor

-----ORIGINAL MESSAGE------

On 3/15/17, 12:45 PM, "netmod on behalf of Benoit Claise" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Dear all,

   (available at http://trac.tools.ietf.org/area/ops/trac/wiki/<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>

   yang-security-guidelines<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>).  Section 7.1<https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-7.1> contains the security

   available.
Then, I see section 7:

   dated 2010-06-16.
Not sure why it contains this cut/paste? It should just say: the latest version is at this URL.
Then, I see in the same section:

   template (available at

2. the new security guidelines must include RESTCONF.
At this point, this is a blocking factor for the publication of YANG module. As an example,
draft-ietf-lmap-yang-11<https://datatracker.ietf.org/doc/draft-ietf-lmap-yang/>, A YANG Data Model for LMAP Measurement Agents, on the telechat tomorrow.
As mentioned the most up to date version is https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

        OLD
The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content.
NEW

The YANG module defined in this memo is designed to be accessed via the NETCONF [RFC6241] or RESTCONF [RFC8040] protocol. The lowest NETCONF layer is the secure transport layer, and mandatory-to-implement is Secure Shell (SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement secure transport is Transport Layer Security (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.
Any objections?
Have covered all that we need for the new RESTCONF protocol?
Regards, Benoit

Hi,

/js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 15 Mar 2017 20:10:22 +0100

On 3/15/2017 6:32 PM, Kent Watsen wrote:
>    via YANG based management protocols, such as NETCONF [RFC6241 
> <https://tools.ietf.org/html/rfc6241>] and
>
> RESTCONF [RFC8040 <https://tools.ietf.org/html/rfc8040>].  Both of 
> these protocols have mandatory-to-
>
>    The NETCONF access control model (NACM) [RFC6536 
> <https://tools.ietf.org/html/rfc6536>] provides the means
>
>    (from: 
> https://tools.ietf.org/html/draft-ietf-netconf-keystore-01#section-4).
>

I like the "YANG based management protocols" part

Trying the combine the different proposals:
    The YANG module defined in this document is designed to be accessed
    via YANG based management protocols, NETCONF [RFC6241 
<https://tools.ietf.org/html/rfc6241>] or
RESTCONF [RFC8040 <https://tools.ietf.org/html/rfc8040>]. The lowest 
NETCONF layer is the secure transport layer,
     and mandatory-to-implement secure transport is Secure Shell (SSH) 
[RFC6242],
     while the lowest RESTCONF layer is HTTP, and the 
mandatory-to-implement secure
     transport is Transport Layer Security (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.

>    [I-D.ietf-netconf-ssh-client-server 
> <https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#ref-I-D.ietf-netconf-ssh-client-server>] 
> and [I-D.ietf-netconf-tls-client-server 
> <https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#ref-I-D.ietf-netconf-tls-client-server>]. 
>
>
I believe this is the right approach.

Regards, Benoit
>
>    (from: 
> https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02#section-5)
>
> Thanks,
>
> Kent  // contributor
>
> On 3/15/17, 12:45 PM, "netmod on behalf of Benoit Claise" 
> <[email-masked] <mailto:[email-masked]> on behalf of 
> [email-masked] <mailto:[email-masked]>> wrote:
>
> Dear all,
>
>         The YANG module defined in this memo is designed to be
>         accessed via the NETCONF protocol [RFC6241]. The lowest
>         NETCONF layer is the secure transport layer, and the
>         mandatory-to-implement secure transport is Secure Shell (SSH)
>         [RFC6242]. The NETCONF access control model [RFC6536] provides
>         the means to restrict access for particular NETCONF users to a
>         pre-configured subset of all available NETCONF protocol
>         operations and content.
>
>         NEW
>
>         The YANG module defined in this memo is designed to be
>         accessed via the NETCONF [RFC6241] or RESTCONF [RFC8040]
>         protocol. The lowest NETCONF layer is the secure transport
>         layer, and mandatory-to-implement is Secure Shell (SSH)
>         [RFC6242], while the lowest RESTCONF layer is HTTP, and the
>         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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Mar 2017 08:27:57 +0100

> I like the "YANG based management protocols" part

I think 'YANG based' is not needed (and to some extend even incorrect)
and I would spell out 'network management' instead of 'management':
 
  The YANG module defined in this document is designed to be accessed
  via network management protocols such as NETCONF [RFC6241] or
  RESTCONF [RFC8040].

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Mar 2017 08:37:39 +0100

>    via network management protocols such as NETCONF [RFC6241] or
I could live with that.
Latest proposal:

     RESTCONF [RFC8040]. The lowest NETCONF layer is the secure 
transport layer,

I'll discuss this proposal with the security ADs during the telechat 
today, even if these changes should non controversial.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Mar 2017 08:56:57 +0100

On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote:
>     RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
> layer,
>     while the lowest RESTCONF layer is HTTP, and the mandatory-to-implement
> secure

Picking wording from Section 12 of RFC 8040 to replace your second
sentence I get this:

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

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Mar 2017 09:02:06 +0100

>      protocol operations and content.
Yes, thank you.

Regards, B.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 16 Mar 2017 12:48:34 +0000

A couple comments:

1) drilling down on the mandatory-to-implement NC/RC protocols
   is somewhat missing the point.  The important bit is that
   *all* protocols transporting YANG-modeled data *only* have
   secure transport layers.  More specifically, YANG-modeled
   data may be transported over other protocols (e.g., coap),
   and also one of the protocols have an insecure transport
   protocol (e.g., it doesn't much help to talk about HTTPS
   being mandatory-to-implement if RESTCONF allowed HTTP).

2) just stating that there are secure transport layers still
   isn’t sufficient, as these protocols must also require
   mutual authentication in order to be secure, and for 
   statements regarding NACM to make sense.  The text I posted
   before had a statement like this in it.  

I'm beginning to become a fan of the idea of defining a generic
"Requirements for Protocols Transporting YANG-modeled Data"
document - that would not only discuss security aspects, but
also generic protocol operations, that documents like NC, RC,
CoAP, etc. can point to...and even YANG (RFC 7950), rather than
pointing directly at NETCONF as it does today...

Kent // contributor

Yes, thank you.

Regards, B.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 16 Mar 2017 13:22:14 +0000

typo:

 new: one of the protocols *may* have an insecure protocol

K.

-----ORIGINAL MESSAGE-----

A couple comments:

Kent // contributor

Yes, thank you.

Regards, B.
> /js

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 16 Mar 2017 09:39:56 -0400

I just have a general comment, I'm happy with the direction and
objective of the new text.  It looks like you are down to editorial
nits and I'll stay out of that now that secure transport for RESTCONF
is covered in the considerations.

Thank you for the updated boilerplate!
Kathleen

-- 

Best regards,
Kathleen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Mar 2017 14:51:45 +0100

>    being mandatory-to-implement if RESTCONF allowed HTTP).

RESTCONF says MUST use TLS. Making an open ended statement about
security properties of unknown protocols sounds risky.

> pointing directly at NETCONF as it does today...

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

/js

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Mar 2017 10:13:18 -0400

Juergen,

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

Regards,
Alia

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Mar 2017 15:38:05 +0100

> 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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Mar 2017 18:43:20 +0100

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:

          layer is HTTPS, and the mandatory-to-implement secure
    transport is
          TLS [RFC5246].

Regards, Benoit

---

From: Kent Watsen <[email-masked]>
Date: Thu, 16 Mar 2017 19:49:45 +0000

>>    and also a protocols might have an insecure transport

I wasn't trying to make and open-ended statement, or even an
assumption about those protocols.  I was trying to say that 1)
Benoit's text goes into the weeds talking about mandatory to
implement aspects of a couple specific protocols and 2) the 
text should instead make general statements about the 
expectations of protocols transporting the YANG-modeled data.
Of course, if a protocol sends data in the clear or doesn't
require mutual authentication, then the entire Security 
Consideration is a somewhat pointless read.

K.  // contributor

---

From: Phil Shafer <[email-masked]>
Date: Thu, 16 Mar 2017 16:04:55 -0400

The considerations should say more about how we delegate encryption
and authentication to the underlaying protocols, whatever they may
be.  We don't need details, just an understanding of the role of
each layer.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Mar 2017 14:50:19 +0100

Kent Watsen <[email-masked]> writes:

>    secure transport layers.  More specifically, YANG-modeledq

I agree, and it will become even more relevant if we make YANG
protocol-independent. In fact, data models may be useful even without
any network transport involved, e.g. for a local CLI implementation.

>    before had a statement like this in it.

Right, security considerations attached to data models should deal with
security aspects of the static data (which items are security-sensitive
etc.) and not with transport security.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Mar 2017 15:36:13 +0000

Adding a final thought to this, I found it strange when I copied the
Security guidelines into some of my YANG-model focused drafts, that
I suddenly had to add Informative References for some transport
protocols.   Why should a YANG model care about transport protocols?
Are we going to extend this statement to include all future protocols
too (CoAP, gRPC, etc.)?  Not to mention YANG modules that only define
an artifact (i.e. rc:yang-data).  Where does it end?

I think the 90% of the guidelines are okay, putting focus on select
readable nodes, writable nodes, and RPCs is good.  It's just the 
first  paragraph I have issue with.  The more I think about it, the
more I think the first paragraph should, for the most part, disappear.

K. // contributor

-----ORIGINAL MESSAGE-----

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 17 Mar 2017 15:41:48 +0000

I¹m if I looked hard enough I'd find it. However, I imagine many others
will have the same question.

Where is Wiki or format URL where the boilerplate will be maintained?

Thanks,
Acee

On 3/17/17, 11:36 AM, "netmod on behalf of Kent Watsen"
<[email-masked] on behalf of [email-masked]> wrote:

>>    isn¹t sufficient, as these protocols must also require
>>>>accessed
>>>>transport