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

[Andy Bierman <[e-mail]>]

On Thu, Feb 25, 2016 at 5:01 PM, Tom Yu <[e-mail]> wrote:

> Hi Mahesh,
>
> Sorry about the delay.
>
> I was looking at the specific comments in the Security Considerations of
> this document about the sensitivity of the contents of /modules/module.
> How do the risks of an attacker being able to inspect /modules/module
> compare with other information that could be available to an attacker,
> such as fingerprinting through non-NETCONF means?
>
> If an attacker has limited NETCONF access on a server, what would the
> contents of /modules/module reveal to the attacker that might not
> otherwise be discovered by other kinds of probing within the NETCONF
> protocol?
>
>

The YANG library provides the same information that is currently
in the NETCONF <hello> message.

It is expected that NACM (RFC 6536) will be used to prevent access
to sensitive operations, notifications, and data.
However NACM is optional-to-implement with NETCONF and RESTCONF.

The risk is the same as current NETCONF.
If a specific module/revision implementation is known to
be vulernable, then NETCONF and this library both let
the client know it is running on the server.





> These other risks might be trivial in comparison to the one mentioned in
> the document, but lacking specific knowledge of the broader context of
> NETCONF and how it is deployed, I'm not sure how they compare.  For
> example, is it expected that anonymous or minimally trusted users could
> be authorized to use NETCONF to access some public information about a
> server?
>


If NACM is implemented and deployed correctly, no.
Otherwise -- yes, if all users have all access to all YANG modules,


>
> If these other risks are similar in magnitude to the possible exposures
> allowed by /modules/module, you should consider mentioning them, and
> give the implementor or operator some guidance about how to weigh these
> risks.  If the exposures allowed by /modules/module vastly outweigh
> those from other avenues of obtaining similar capability or
> configuration information, in most environments and forseeable
> deployments, maybe the current text is sufficient.
>
> -Tom
>


Andy


>
> Mahesh Jethanandani <[e-mail]> writes:
>
> > Tom,
> >
> > It is not entirely clear from this e-mail, what action you want the
> authors to take.
> >
> > YANG module information or more like its encodings are sent over a
> secure session (SSH/TLS) and are no more specific to this draft than they
> are to any NETCONF/RESTCONF session. As such it is not clear what you want
> the authors to do. Could you clarify or provide text for the Security
> Consideration section?
> >
> > Thanks.
> >
> >> On Feb 1, 2016, at 6:03 PM, Tom Yu <[e-mail]> wrote:
> >>
> >> I have reviewed this document as part of the security directorate's
> >> ongoing effort to review all IETF documents being processed by the
> >> IESG.  These comments were written primarily for the benefit of the
> >> security area directors.  Document editors and WG chairs should treat
> >> these comments just like any other last call comments.
> >>
> >> The Security Considerations of this document seem reasonable.  It might
> >> be useful to add a comparison of the risks posed by sensitive
> >> information exposed by this YANG module with information exposed by
> >> other aspects of NETCONF, or available through methods such as
> >> fingerprinting.  Admittedly, a meaningful comparison might be highly
> >> context-specific, so a general comparison might have limited utility.
> >
> > Mahesh Jethanandani
> > [e-mail]
>