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

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 10 Mar 2016 16:55:59 -0800

Tom,

Any update from your side?

> On Feb 26, 2016, at 3:12 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Tom,
> 
> Thanks for getting back to us. 
> 
> At the outset let me just say that this draft is defining a new mechanism for advertisement of capabilities within YANG modules. As such, the security considerations for this document are not very different from the security considerations one might have using the NETCONF protocol today. Some of the information is already being exchanged today through other mechanisms. 
> 
> To your specific comments...
> 
>> On Feb 25, 2016, at 5:01 PM, Tom Yu <[email-masked] <mailto:[email-masked]>> 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?
> 
> The attacker may have better success getting the information through some other means, and even then the information would be no more damaging than what they would be able to see if they had the right SSH/NACM credentials.
> 
>> 
>> 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?
> 
> With limited access most of the information about the modules/module will not be visible.
> 
>> 
>> 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?
> 
> No. There is no anonymous or minimal trusted user account (by default). Accounts have to be setup for users to access the box over NETCONF and then they are typically assigned to a authorized group with specific permissions.
> 
> Thanks.
> 
>> 
>> 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
>> 
>> Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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
>>> [email-masked] <mailto:[email-masked]>
> 
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Mar 2016 10:28:54 -0700

> otherwise be discovered by other kinds of probing within the NETCONF

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.

> be authorized to use NETCONF to access some public information about a

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

> deployments, maybe the current text is sufficient.

Andy

>
> Mahesh Jethanandani <[email-masked]> writes:
>
> > Tom,
> >
> > 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 <[email-masked]> wrote:
> >>

---

From: Tom Yu <[email-masked]>
Date: Tue, 22 Mar 2016 17:30:24 -0400

> the client know it is running on the server.

If the risk is the same as current NETCONF, then why mention it in this
document?  It seems to me that the YANG library provides somewhat more
detail than the NETCONF <hello> message, right?  The YANG library
provides deviation and conformance details, unlike what I see in the
NETCONF <hello> message description in RFC6241, unless there's something
I'm missing.

It would be good to clarify whether the risks of exposing
/modules-state/module include vulnerabilities in the NETCONF
implementation itself, or with vulnerabilities in the associated
underlying network device functionality for which NETCONF provides
configuration access (perhaps both, to different degrees?).

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Mar 2016 14:57:04 -0700

> NETCONF <hello> message description in RFC6241, unless there's something

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.

> configuration access (perhaps both, to different degrees?).

The library is intended for other protocols such as RESTCONF.

Is there some specific text you want changed?
This is the only non-boilerplate text in the section:
Is there some part of this that is incorrect?

   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.  For example, if a
      particular operation on a particular data node is known to cause a
      server to crash or significantly degrade device performance, then
      the module list information will help an attacker identify server
      implementations with such a defect, in order to launch a denial of
      service attack on the device.

---

From: Tom Yu <[email-masked]>
Date: Wed, 23 Mar 2016 15:39:33 -0400

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

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.

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Mar 2016 13:30:55 -0700

>    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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 Mar 2016 15:55:28 +0100

On 3/23/2016 9:30 PM, Andy Bierman wrote:
>
>
> On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Andy Bierman <[email-masked] <mailto:[email-masked]>> writes:
>
I would support this.

Regards, Benoit