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

From: Tom Yu <[email-masked]>
Date: Mon, 01 Feb 2016 21:03:35 -0500

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.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 15 Feb 2016 13:28:40 -0800

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

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 19 Feb 2016 15:07:13 -0800

Tom,

How did you want to proceed on this?

> On Feb 15, 2016, at 1:28 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Tom,
> 
> YANG module information or more like its encodings are sent over a secure session (SSH) 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.
> 

Mahesh Jethanandani
[email-masked]

---

From: Tom Yu <[email-masked]>
Date: Thu, 25 Feb 2016 20:01:33 -0500

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?

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 26 Feb 2016 15:12:01 -0800

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]> wrote:
> 
> Hi Mahesh,
> 
> Sorry about the delay.
> 

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.

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

With limited access most of the information about the modules/module will not be visible.

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

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.

Mahesh Jethanandani
[email-masked]