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

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"
<netmod-bounces@ietf.org on behalf of kwatsen@juniper.net> wrote:

>
>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 <kwatsen@juniper.net> 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
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: 0xB8F92B08A9F76C67
>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod