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

[Kent Watsen <[e-mail]>]

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

Kent Watsen <[e-mail]> writes:

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

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.

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

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

>
> 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
>
>
> On 3/16/2017 8:56 AM, Juergen Schoenwaelder wrote:
>> On Thu, Mar 16, 2017 at 08:37:39AM +0100, Benoit Claise wrote:
>>> Latest 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 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].
>> 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].
>>
>>      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.
> Yes, thank you.
>
> Regards, B.
>>
>> /js
>>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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