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

[Andy Bierman <[e-mail]>]

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.


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