Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03

[Tom Yu <[e-mail]>]

I also think that is reasonable.

-Tom

Benoit Claise <[e-mail]> writes:

> Hi Andy,
>
> I believe it works.
>
> Regards, Benoit
>> Hi,
>>
>> Here is the proposed text:
>>
>>
>> OLD:
>>
>>    o  /modules-state/module: The module list used in a server
>>       implementation may help an attacker identify the server
>>       capabilities and server implementations with known bugs. Server
>>       vulnerabilities may be specific to particular modules, module
>>       revisions, module features, or even module deviations. This
>>       information is included in each module entry. ...
>>
>> NEW:
>>
>>    o  /modules-state/module: The module list used in a server
>>       implementation may help an attacker identify the server
>>       capabilities and server implementations with known bugs.  Although
>>       some of this information may be available to all users via the
>>       NETCONF <hello> message (or similar messages in other management
>>       protocols), this YANG module potentially exposes additional
>>       details that could be of some assistance to an attacker.  Server
>>       vulnerabilities may be specific to particular modules, module
>>       revisions, module features, or even module deviations.  This
>>       information is included in each module entry. ...
>>
>>
>> If this is acceptable, I will post a -05 version.
>>
>>
>> Andy
>>
>>
>> On Thu, Mar 24, 2016 at 7:55 AM, Benoit Claise <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     On 3/23/2016 9:30 PM, Andy Bierman wrote:
>>>
>>>
>>>     On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>         Andy Bierman <[e-mail] <mailto:[e-mail]>>
>>>         writes:
>>>
>>>         > The YANG library provides the revision date of the
>>>         deviations module,
>>>         > which is not included in the NETCONF <hello>.
>>>         >
>>>         > It  also lists the submodules and their revisions, which is
>>>         > not contained in the NETCONF <hello>.
>>>         >
>>>         > The NETCONF <hello> message is not specified well enough to
>>>         > make any other generalizations about the differences.
>>>
>>>         I think it would be good to explicitly mention that the YANG
>>>         library
>>>         provides a superset of the module and version information
>>>         that might be
>>>         available by other means, e.g.,
>>>
>>>         OLD
>>>
>>>            Some of the readable data nodes in this YANG module may be
>>>         considered
>>>            sensitive or vulnerable in some network environments.  It
>>>         is thus
>>>            important to control read access (e.g., via get,
>>>         get-config, or
>>>            notification) to these data nodes.  These are the subtrees
>>>         and data
>>>            nodes and their sensitivity/vulnerability:
>>>
>>>         NEW
>>>
>>>            Some of the readable data nodes in this YANG module may be
>>>         considered
>>>            sensitive or vulnerable in some network environments and
>>>            authorization configurations.  Although some of this
>>>         information may
>>>            be available to all users via the NETCONF <hello> message
>>>         (or similar
>>>            messages in other management protocols), this YANG module
>>>         potentially
>>>            exposes additional details that could be of some
>>>         assistance to an
>>>            attacker.  It is thus important to control read access
>>>         (e.g., via
>>>            get, get-config, or notification) to these data nodes.
>>> These are the
>>>            subtrees and data nodes and their sensitivity/vulnerability:
>>>
>>>
>>>
>>>
>>>     This is the security boilterplate text that is supposed to
>>>     go into every YANG module
>>>
>>>
>>>     https://tools.ietf.org/html/rfc6087#section-6.1
>>>
>>>
>>>     I prefer to leave the boilerplate alone and move your text into
>>>     YANG library specific part.
>>     I would support this.
>>
>>     Regards, Benoit
>>>
>>>
>>>     Andy
>>>
>>>         I think if NETCONF access is restricted to a small number of
>>>         trusted
>>>         users (even for read-only access), the incremental risk posed by
>>>         revealing more details about the modules is small.  I imagine
>>>         that there
>>>         are use cases for providing (restricted) read-only NETCONF
>>>         access to a
>>>         wider, mostly untrusted population, in which case the
>>>         detailed module
>>>         version information provided by the YANG library could
>>>         constitute a
>>>         non-trivial additional risk.  I'm not sure of a good, concise
>>>         way to
>>>         express this.
>>>
>>>         > The library is intended for other protocols such as RESTCONF.
>>>         >
>>>         > Is there some specific text you want changed?
>>>
>>>         I think there could be ambiguity about whether "server"
>>>         refers to the
>>>         NETCONF (or other management protocol) server process on the
>>>         device, or
>>>         to the overall capabilities of the device.  If the YANG
>>>         library could
>>>         provide details that could reveal to an attacker the existence of
>>>         vulnerabilities in the underlying network device
>>>         capabilities, it might
>>>         be good to mention it, e.g.,
>>>
>>>             In addition to revealing the potential existence of
>>>         vulnerabilities
>>>             in the network management protocol server on a device,
>>>         the detailed
>>>             version information available in the module list could
>>>         help an
>>>             attacker to discover the existence of vulnerable code in the
>>>             implementation of the underlying network capabilities (or
>>>         other
>>>             functionality) of the device on which the management
>>>         server is
>>>             running.
>>>
>>>
>>
>>