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

[Benoit Claise <[e-mail]>]

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