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

[Andy Bierman <[e-mail]>]

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]> wrote:

> On 3/23/2016 9:30 PM, Andy Bierman wrote:
>
>
>
> On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu <[e-mail]> wrote:
>
>> Andy Bierman <[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.
>>
>
>
>