Subject: [netmod] [Fwd: Re: [Fwd: first draft for yang module security considerations]]

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 06 Apr 2010 17:33:22 +0200

I asked Martin for some suggested text w.r.t. security considerations
for RPX. Below is what he has suggested. I think it is best if we
have this discussion on this mailing list.

Bert

-------- Original Message --------
Subject: 	Re: [Fwd: first draft for yang module security considerations]
Date: 	Tue, 06 Apr 2010 14:59:29 +0200 (CEST)
From: 	Martin Bjorklund <[email-masked]>
To: 	[email-masked]
CC: 	[email-masked]
References: 	<[email-masked]>

Hi,

[Cc:ing Andy as well, since this somewhat touches the nacm work]

"Bert (IETF) Wijnen" <[email-masked]> wrote:
> MArtin, you had some remarks about the need to say something
> about RPC and/or operations? Can you suggest text and the location where
> to put it?

Yes, I think we need to mention rpc as well:

-- if your YANG module has defined any rpc operations
-- describe their specific sensitivity or vulnerability.

Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments.  It is thus
important to control access to these operations.  These are the
operations and their sensitivity/vulnerability:

> -- for all YANG modules you must evaluate whether any readable data
> -- nodes (those are all the "config false" nodes, but also all other
> -- nodes, because they can also be read via operations like get or
> -- get-config) are sensitive or vulnerable (for instance, if they
> -- might reveal customer information or violate personal privacy
> -- laws such as those of the European Union if exposed to
> -- unathorized parties)
> 
> 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:
> 
> <list subtrees and data nodes and state why they are sensitive>

I wonder if it is correct to treat notifications like this.  The
problem is that the text seems to suggest that if one of the nodes in
a notification is sensitive, it should be listed.  This, in turn,
seems to imply that an access control solution for NETCONF should be
able to filter on nodes in notification content.  The NACM draft by
Andy (which I agree with) does not support this level of detail.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 Apr 2010 09:24:47 -0700

> -- describe their specific sensitivity or vulnerability.

This is especially important since NETCONF supports arbitrary
actions like 'rebooot', that have obvious DoS issues.

> Andy (which I agree with) does not support this level of detail.

IMO, the current security considerations are still relevant.
An author should list 'newval' as a security risk (see below).
That doesn't mean NACM must support subtree pruning though.

Part of the concern is that enforcing detailed access control
for read operations is too expensive, and slows down the server.
Then there is the assumption that operators actually
want to configure detailed access control rules for notification content.

A data model designer should be careful about defining
notification payloads that are 'risky', like Sharon's
early 'config-change' notifications that included all the config
values that were affected (not just a name in an instance-identifier).

The WG needs to decide if the server MUST, SHOULD, MAY provide
configurable access control mechanisms for arbitrary sub-trees
within NETCONF messages, and what that really means.

For example, the nacm:secure extension theoretically could
apply to notification nodes:

   notification create-event {
      description "Dumb config-change for create event";

      leaf username {
          description "User who made the config change.";
          type string;
      }
      leaf node {
          description "Node that was created.";
          type instance-identifier;
      }
      anyxml newval {
         nacm:secure;
         description "The new value node";
      }
   }

But this would require the server to support data-rules for
notification content, so some behavior other than the
default could ever be achieved.

IMO, it is OK if NACM requires the operator to secure
the entire 'event-type' message, and not prune-to-order ACLs.

> /martin

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 09 Apr 2010 09:49:40 +0200

I agree with Andy here in that it IS important to list the 
vulnerabilities/privacy issues
for anobject that could be read/seen via a notification.

The fact that such is listed does not mean that NACM MUST provide a 
mechanism
to filter out one (or some) specific nodes/objects from a notification. 
If the WG decides
that in such a case the wholenotification must not be sent, that is up 
to the WG.

Martin, thanks for the input. I my next posting I will send a renewed 
complete
security considerations template.

Bert