Subject: [netmod] second draft for yang module security considerations

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

WG chairs, are we ready for a WG LC on this?

Thanks for comments and review sofar.

The first part (that follows here) is text that I have modified based on 
text
from the YANG usage draft. Maybe ANdy can look at that and see if it
should be changed accordingly in that draft as well.
It can also be used as a preface on the web page (URL TBD) that
we will setup for this.
 
   Each specification that defines one or more YANG
   modules MUST contain a section that discusses
   security considerations relevant to those modules.
   This section MUST be patterned after the latest
   approved template (available at [ed: URL TBD]).

   In particular, writable module objects that could
   be especially disruptive if abused MUST be
   explicitly listed by name and the associated
   security risks MUST be spelled out.

   Similarly, readable module objects that contain
   especially sensitive information or that raise
   significant privacy concerns MUST be explicitly
   listed by name and the reasons for the
   sensitivity/privacy concerns MUST be explained.

   Further, if new RPC operations have been defined,
   then it the security considerations of each new
   RPC operation MUST be explained.

And the following is the template:

X. Security Considerations

-- if you have any writeable data nodes (those are all the
-- "config true" nodes, and remember, that is the default)
-- describe their specific sensitivity or vulnerability.

There are a number of data nodes defined in this YANG module
which are writable/creatable/deletable (i.e. config true, which
is the default).  These data nodes may be considered sensitive
or vulnerable in some network environments.  Write operations
(e.g. edit-config) to these data nodes without proper protection
can have a negative effect on network operations.  These are
the subtrees and data nodes and their sensitivity/vulnerability:

 <list subtrees and data nodes and state why they are sensitive>

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

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

 <list RPC operations and state why they are sensitive>

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Apr 2010 22:04:22 +0200

>    RPC operation MUST be explained.

Not sure what "module objects" are - I think we should stick
to YANG terminology and s/module objects/data nodes/ above

>  <list RPC operations and state why they are sensitive>

Seems to be a reasonable template.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 09 Apr 2010 13:07:03 -0700

> Seems to be a reasonable template.

+1

I plan to update the YANG usage I-D when the text is finalized.

> /js

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 12 Apr 2010 09:29:24 +0200

Third revision, based on comments from Juergen and a typo
reported by Mark.

Bert
----

   In particular, writable data nodes that could
   be especially disruptive if abused MUST be
   explicitly listed by name and the associated
   security risks MUST be spelled out.

   Similarly, readable data nodes that contain

-- unauthorized parties)

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 12 Apr 2010 12:00:42 +0200

I apologize for commenting only now, but I was on vacation for the two
weeks after Anaheim. I did not yet read all mail and if the issue was
already raised please point me to the relevant thread. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bert (IETF) Wijnen

>    sensitivity/privacy concerns MUST be explained.

It looks to me that the optional mode language used here 'data nodes
that could be especially disruptive' and especially the word
'especially' :-) contradict the MUST and allow for the security
considerations section to not document nodes that are not considered
*especially* disruptive if abused. The practice with MIB objects is I
think to document all writeable objects. Do we want to depart from this
practice? 

I am more indulgent concerning readable only nodes. 

Dan

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 12 Apr 2010 12:21:46 +0200

> I am more indulgent concerning readable only nodes. 

I don't think it was discussed yet.
I am OK with taking out the word "especially", and in fact I think it 
would be good
to take it out in both cases.

Other opinions or supporting opinions?

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 12 Apr 2010 14:14:48 +0200

I would actually prefer to take out all the conditional language from
the writeable nodes text. 

OLD: 

NEW: 

In particular, writable data nodes MUST be
explicitly listed by name and the associated
security risks MUST be spelled out.

sensitive information or that raise

> From: Bert (IETF) Wijnen [mailto:[email-masked]] 
> Sent: Monday, April 12, 2010 1:22 PM
> To: Romascanu, Dan (Dan)
> Cc: NETMOD Working Group
> Subject: Re: [netmod] third draft for yang module security 
> considerations
> 
> > think to document all writeable objects. Do we want to depart from 
> > this practice?
> >
> I am OK with taking out the word "especially", and in fact I 
> think it would be good to take it out in both cases.
> 

I would actually prefer to take out all the conditional language from
the writeable nodes text. 

OLD: 

NEW: 

In particular, writable data nodes MUST be
explicitly listed by name and the associated
security risks MUST be spelled out.

sensitive information or that raise

Dan

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 12 Apr 2010 15:12:45 +0200

Wow....

I thought in the MIB template, we assumed that any objects that are not 
mentioned
are not vulnerable. Your approachof course make it easier, for reviewers 
at least,
because they would have to list all data nodes, and for the ones that do 
not have
any security risks, they would need to say:
   <data node a>  security risk  abcd
   <data node b>  no vulenrability risk, but sensitive for privacy 
because of defg
   <data node c>  no security or privacy risks
or some such

That is sort of fine with me... but I am sure others may have different 
opinions

Bert

Romascanu, Dan (Dan) wrote:
>>> I apologize for commenting only now, but I was on vacation 
>>>       
>> for the two 
>>     
>>> weeks after Anaheim. I did not yet read all mail and if the 
>>>       
>> issue was 
>>     
>>> It looks to me that the optional mode language used here 
>>>       
>> 'data nodes 
>>     
>>> *especially* disruptive if abused. The practice with MIB 
>>>       
>> objects is I 
>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 12 Apr 2010 15:23:15 +0200

Actually the text in the guidelines for the security considerations in
MIB documents does not seem to leave the option to not mention writeable
objects. Here is the text.

-- if you have any read-write and/or read-create objects, please
-- describe their specific sensitivity or vulnerability.
-- RFC 2669 has a very good example.

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

    <list the tables and objects and state why they are sensitive>

This text was exactly the reason that triggered my input, because what
is now described in the 'third draft' seems to lower the bar. 

Dan

> Sent: Monday, April 12, 2010 4:13 PM
> To: Romascanu, Dan (Dan)
> Cc: NETMOD Working Group
> I thought in the MIB template, we assumed that any objects 
> that are not mentioned are not vulnerable. Your approachof 
> course make it easier, for reviewers at least, because they 
> would have to list all data nodes, and for the ones that do 
> not have any security risks, they would need to say:
>    <data node b>  no vulenrability risk, but sensitive for 
> privacy because of defg
>    <data node c>  no security or privacy risks or some such
> 
> That is sort of fine with me... but I am sure others may have 
> different opinions
> 
> Bert
> 
> > In particular, writable data nodes that could be especially 
> disruptive 
> > if abused MUST be explicitly listed by name and the associated 
> > Similarly, readable data nodes that contain especially sensitive 
> > information or that raise significant privacy concerns MUST be 
> > explicitly listed by name and the reasons for the 
> sensitivity/privacy 
> > In particular, writable data nodes MUST be explicitly 
> listed by name 
> > and the associated security risks MUST be spelled out.
> >
> > Similarly, readable data nodes that contain sensitive 
> information or 
> > that raise significant privacy concerns MUST be explicitly 
> listed by 
> > name and the reasons for the sensitivity/privacy concerns MUST be 
> > explained.
> >
> >   
> >> would be good to take it out in both cases.
> >>
> > In particular, writable data nodes that could be especially 
> disruptive 
> > if abused MUST be explicitly listed by name and the associated 
> > Similarly, readable data nodes that contain especially sensitive 
> > information or that raise significant privacy concerns MUST be 
> > explicitly listed by name and the reasons for the 
> sensitivity/privacy 
> > In particular, writable data nodes MUST be explicitly 
> listed by name 
> > and the associated security risks MUST be spelled out.
> >
> > Similarly, readable data nodes that contain sensitive 
> information or 
> > that raise significant privacy concerns MUST be explicitly 
> listed by 
> > name and the reasons for the sensitivity/privacy concerns MUST be 
> > explained.
> >
> > Dan
> >
> >   
> 
>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 14 Apr 2010 17:32:14 +0200

Hi,

does this then needs to be done for every grouping (which is potentially
an object)?
For a long YANG module I assume this would cause some effort right?
At least for keeping track of all possible objects and getting it
consistent.

Cheers,
Mehmet

> [mailto:[email-masked]] On Behalf Of ext Romascanu, Dan (Dan)
> Sent: Monday, April 12, 2010 3:23 PM
> To: Bert (IETF) Wijnen
> Cc: NETMOD Working Group
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Apr 2010 08:55:43 -0700

> At least for keeping track of all possible objects and getting it

I do not want to enumerate every leaf in the module within
the security section.  That has never been the procedure
for MIBs -- with good reason.

There may be 100 leafs and 3 of them have security
implications.  Does the RFC reader really want to wade through
97 "I have nothing to say here" entries?

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 Apr 2010 18:11:16 +0200

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Wednesday, April 14, 2010 6:56 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: Romascanu, Dan (Dan); Bert (IETF) Wijnen; NETMOD Working Group
> > does this then needs to be done for every grouping (which is 
> > potentially an object)?
> the security section.  That has never been the procedure for 
> MIBs -- with good reason.
> 

Actually the procedure and boilerplate for MIB modules mandates listing
all writeable objects or group of objects. 

I understand the concern and also the fact that in a YANG module all or
most of the leaves are writeable, while for MIB objects this may be the
case only for a minority of objects or none. Yet, exactly because this
looks to me like a departure from what we have been accustomed to do in
MIB modules, our decision should be discussed and we must have good
arguments for the security reviewers who need to agree on this
boilerplate before we start using it. 

Then, do you believe that 3 out of 100 will be the real ratio of
security-sensitive configuration out of the total? Do you mean 97% of
what we configure in a router has no security implications - i.e. does
not result in the network mis-behaving and users connectivity being
impacted in case of mis-configuration? I doubt it. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Apr 2010 09:39:37 -0700

> impacted in case of mis-configuration? I doubt it. 

I do not see the value of listing the objects that do not
have any security issues, no matter what the percentage.
The percentage will vary, depending on the module subject matter.

Is there some assumption that every writable object is a security
risk because it can cause the network to change?

Large modules like ipfix-psamp.yang have a lot of writable leafs.
Listing all of them is going to hide the problem leafs in
pages of useless text.  It is going to be a lot of busy work
for the IPFIX authors to list every writable leaf and explain
why or why not be worried about security.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 Apr 2010 18:52:16 +0200

> Sent: Wednesday, April 14, 2010 7:40 PM
> To: Romascanu, Dan (Dan)
> Cc: Ersue, Mehmet (NSN - DE/Munich); Bert (IETF) Wijnen; 
> NETMOD Working Group
> >> I do not want to enumerate every leaf in the module within the 
> >> security section.  That has never been the procedure for 
> MIBs -- with 
> >> good reason.
> >>
> >> There may be 100 leafs and 3 of them have security implications.  
> >> Does the RFC reader really want to wade through
> > Actually the procedure and boilerplate for MIB modules mandates 
> > listing all writeable objects or group of objects.
> > 
> > I understand the concern and also the fact that in a YANG 
> module all 
> > or most of the leaves are writeable, while for MIB objects 
> this may be 
> > the case only for a minority of objects or none. Yet, 
> exactly because 
> > this looks to me like a departure from what we have been 
> accustomed to 
> > do in MIB modules, our decision should be discussed and we 
> must have 
> > good arguments for the security reviewers who need to agree on this 

OK, I can agree with this. This is however NOT was done with MIB
objects, and will need to be explained to the security people. 

> 
> Is there some assumption that every writable object is a 
> security risk because it can cause the network to change?
> 

That's one way to approximate the security risks. If by a configuration
command on a leaf you can put down a router or reduce its capacity to a
quarter, then it's a security risk. 

> why or why not be worried about security.

Listing all individual objects was avoided in the security consideration
sections of MIB documents by allowing to describe security risks for
'tables and objects' when the same security risks applied for example to
all writeable objects in a table. We may try something similar in YANG.

Dan

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Apr 2010 10:10:46 -0700

Romascanu, Dan (Dan) wrote:
....
> quarter, then it's a security risk. 

Maybe we need more precise text on this issue.

Need to be listed:

 1) affects network behavior (routing, VPN)
 2) affects network services (dhcp, dns)
 3) affects a device's ability to use the network (interfaces)
 4) operator access related parameters (NACM, user table, radius, etc.)
 5) parameters to control output of data to the network (syslog,
    netconf subscriptions)

Does not need to be listed:

 A) parameters to affect how the device implementation behaves
    (performance tuning, cache sizes)
 B) parameters for user or session preferences
 C) parameters for functional options (polling interval, timezone)

> all writeable objects in a table. We may try something similar in YANG.

good point.
If most of a list or container needs to be listed, then 1 entry can
cover the entire subtree.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 14 Apr 2010 12:38:03 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: "NETMOD Working Group" <[email-masked]>
> Sent: Wednesday, April 14, 2010 10:10 AM
> Subject: Re: [netmod] third draft for yang module security considerations
...
>  C) parameters for functional options (polling interval, timezone)

To me these are all potentially sensitive.
Messing up the performance tuning, session preferences,
polling intervals or timezone could have severe operational
consequences.  Imagine changing a timezone and performance
tuning parameters for a branch office's file server, causing its
late-night backup script to run during the middle of the day.

I'd put it another way:  if something is important enough to
make configurable, it is by definition potentially sensitive.

I'd go so far as to say that if there's some bit of configuration data
that is not deemed sensitive, the spec bears the burden of
explaining why it's worth configuring.

Randy

---

From: David Kessens <[email-masked]>
Date: Wed, 14 Apr 2010 12:37:39 -0700

I am a bit afraid that we are going to make things more difficult then
what makes sense:

Per definition, writable objects come with security risks as they might
leave the device in a different state.

The yang module already documents what is writable or readable, I don't see
much reason why this should be enumerated again. Basically, the security
section should say to read the module to find out which ones are at such a
higher risk because they are writable.

As for the specifics of the risk, that is really not something that was
introduced by the management system (yang) but are more fundamental to
whatever you are managing.

I can live with a statement that refers to the inherent risks of the
protocol being managed and a reference to the security section of that
document and the inherent risks of using buggy code.

Basically, we should say something that configuring your device using yang
can be risky if you don't know understand what you are configuring. The yang
module cannot prevent you from doing dumb things. In the end, everything
writable is a risk under the wrong circumstances, whether it is just a "user
preference" option or bringing down/up an interface.

David Kessens
---

> cover the entire subtree.

David Kessens
---

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Apr 2010 13:08:31 -0700

> I am a bit afraid that we are going to make things more difficult then

amen to that!

> higher risk because they are writable.

Good idea, especially since we will never agree on
rules for deciding if an object needs to be listed or not.

The NETCONF NACM module (in draft-bierman-netconf-nacm-01.txt)
contains the nacm:secure and nacm:very-secure extensions.
These can used to tag YANG constructs that should be read-only
or no-access by default.

Tools can process YANG nodes based on the tags.
For example, the server implementing NACM must not
allow default access to such nodes.  Another tool
might generate the list of secure and very-secure objects
in xml2rfc format.  An NMS might high-light these objects
in a YANG browser.

I think a good compromise is to put the security concerns in the
description-stmt for the node, and just list the writable nodes in
the security considerations section, without any additional text.
Instead there would be something like:

   Refer to the YANG definitions of the following objects,
   which allow write access, for security considerations:

      /top-node/foo
      /top-node/bar
      /other-node/some/leaf

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Apr 2010 22:18:59 +0200 (CEST)

> These can used to tag YANG constructs that should be read-only

[...]

> the security considerations section, without any additional text.

I like this idea.  I think it can be useful to make things a bit more
clear by putting the security consideration text not in the
description statement, but in the nacm:secure statement:

  leaf foo {
    ...
    description
      "what the leaf means";
    nacm:secure
      "why it is marked as secure";
  }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Apr 2010 13:36:12 -0700

>       "why it is marked as secure";

This seems like it would be useful, but in reality,
it introduces the same problem as David is trying to avoid,
which is to define the criteria for 'security text' vs. 'non-security text'.

I also do not want the most important descriptive text in an extension
that can be tossed by every compiler.  That would be bad.

Special-purpose description clauses are a slippery-slope.
We already have description, presence, reference, organization,
and contact.  That is plenty.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 14 Apr 2010 16:48:15 -0400

>explaining why it's worth configuring.

If all config data is sensitive, then we don't need to burn words
crawling thru the details for each node.  In many cases explaining
the attack scenarios or implications of a config error is a very
complex task.  For example, if the domain search list is not entered
correctly, will my syslog data (IDP/SNMP/etc) get discarded?  Or
if the system location is not entered correctly, will my network
fail if I turn off power to rack 13 after checking that nothing on
rack 13 is needed anymore?  How far down this road do we need to go?

Perhaps we just need a more blanket statement like:

  Caveat Configurator:

  Configuring network equipment is inherently dangerous.  Improper
  usage, manipulation, handling, storage, and transportation of
  configuration data create a risk of security-related issues.  The
  chief concern is controlling access to the devices, but the
  configuration of the network will affect the ability of the network
  to function correctly, including reporting security-related issues.
  Configuration data must be dealt with correctly to allow the
  network to operate in a useful and secure manner.

  Please read the YANG module thoroughly before using, and consider
  the issues that can arise from improper configuration handling.
  Any specific issues with particular data nodes are described in
  the YANG module with the appropriate node definition.

Thanks,
 Phil

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 15 Apr 2010 12:15:48 +0200

I doubt that a blanket statement like the one proposed below will ever
be approved by the security area experts. This goes against the practice
and guidance provided to authors of RFCs in the last decade or maybe
longer time which requires 'strong' security considerations sections -
see RFC 3552 (BCP 72). I think (and Bert should correct me here if I am
wrong) that the Security Considerations guidelines for MIB documents
were created by Bert and Steve Bellovin to help people writing MIB
documents implement the recommendations of RFC 3552 in a way that makes
sense for MIB modules. What we need is something similar for YANG
modules that can be written in a manner that does not create a huge
overhead for people writing, reading and deploying YANG modules. 

Dan

> [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Wednesday, April 14, 2010 11:48 PM
> To: Randy Presuhn
> Cc: NETMOD Working Group
> If all config data is sensitive, then we don't need to burn 
> words crawling thru the details for each node.  In many cases 
> explaining the attack scenarios or implications of a config 
> error is a very complex task.  For example, if the domain 
> search list is not entered correctly, will my syslog data 
> (IDP/SNMP/etc) get discarded?  Or if the system location is 
> not entered correctly, will my network fail if I turn off 
> power to rack 13 after checking that nothing on rack 13 is 
> needed anymore?  How far down this road do we need to go?
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 15 Apr 2010 12:18:51 +0200

> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Wednesday, April 14, 2010 11:36 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> >> These can used to tag YANG constructs that should be read-only or 
> >> no-access by default.
> > 
> > [...]
> > 
> This seems like it would be useful, but in reality, it 
> introduces the same problem as David is trying to avoid, 
> I also do not want the most important descriptive text in an 
> extension that can be tossed by every compiler.  That would be bad.
> 
> We already have description, presence, reference, 
> organization, and contact.  That is plenty.
> 
> 

+1 

Moreover, it looks to me that it does not create less lines of text but
potentially more than listing individual leaves and their security (or
non-security) concerns in the Security Considerations section. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Apr 2010 08:45:57 -0700

> overhead for people writing, reading and deploying YANG modules. 

I remember the motivation for strong SMIv2 SC sections
was to avoid having to read the entire MIB module
to find out if there are any objects of interest.

I think listing the writable objects (in the SC section) is a good idea.
This does not mean every leaf -- it can be per list or container
if the author wants to do that.

Andy

>>> I'd go so far as to say that if there's some bit of 
>>>       
>> configuration data 
>>     
>> explaining 
>>> why it's worth configuring.
>>>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 15 Apr 2010 17:55:07 +0200

> Sent: Thursday, April 15, 2010 6:46 PM
> To: Romascanu, Dan (Dan)
> Cc: Phil Shafer; Randy Presuhn; NETMOD Working Group
> > be approved by the security area experts. This goes against the 
> > practice and guidance provided to authors of RFCs in the 
> last decade 
> > or maybe longer time which requires 'strong' security 
> considerations 
> > sections - see RFC 3552 (BCP 72). I think (and Bert should 
> correct me 
> > here if I am
> > documents implement the recommendations of RFC 3552 in a way that 
> > makes sense for MIB modules. What we need is something similar for 
> > YANG modules that can be written in a manner that does not create a 
> > huge overhead for people writing, reading and deploying 
> YANG modules.
> >
> >   
> 
> I remember the motivation for strong SMIv2 SC sections was to 
> avoid having to read the entire MIB module to find out if 
> there are any objects of interest.
> 
> This does not mean every leaf -- it can be per list or 
> container if the author wants to do that.
> 

I agree. This seems to me the best variant of those discussed until now
and is similar to what we do in MIB documents.

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Apr 2010 10:55:21 +0200 (CEST)

> and is similar to what we do in MIB documents.

Let me see if I understand this proposal correctly:

  All config true nodes MUST be listed in the SC section, but a
  container or list node can be listed, and if so, covers the entire
  subtree.

  In the SC section, the node is just mentioned by name, and the text
  describing the security concerns MUST be written in the YANG module
  (e.g. in the description statement).

If this is the proposal, I still think it makes sense to put this
security text in the nacm:secure and nacm:very-secure statements.  If
you don't like the text to be an argument to these statements, it
could go into a description statement as a substement to
nacm:secure/very-secure:

  nacm:secure {
    description
      "Modification of this node blah blah...";
  }

 [This is similar to what we do with enum values - each enum has its
 own description statement, instead of describing them all in the
 node's description.]

 If we don't do this, it will be harder to find the text, and at best
 we'll end up with some convention for structure in the node's
 description statement, such as:

  description
    "blah blah...
     blah blah...

     Security Concerns
    
       Modification of this node blah blah...
     ";
   nacm:secure;

/martin

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 16 Apr 2010 05:39:31 -0700

>>>>> On Thu, 15 Apr 2010 08:45:57 -0700, Andy Bierman <[email-masked]> said:

AB> I think listing the writable objects (in the SC section) is a good
AB> idea.  This does not mean every leaf -- it can be per list or
AB> container if the author wants to do that.

The important thing to document is not the actual items, IMHO, it's how
they can be used and misused and the dangers imposed by allowed remote
access to them.

A list of writable objects xyz:thatAreBadlyNamed doesn't help anyone
from any perspective get a notion of the security related to the module.
A list of statements or grouping objects, as proposed, combined with
statements saying "incorrectly authorized access to this tree would
allow remote attackers to perform man-in-the-middle attacks of critical
local network resources".

Personally, I'd like to see each object in the tree documented by some
blanket coverage (including read-only objects).  But the blanket
shouldn't be at the leaf level unless that's necessary for the
discussion.  The important thing isn't the objects, it's the security
ramification of the objects.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Apr 2010 06:36:40 -0700

Martin Bjorklund wrote:
>>>> I doubt that a blanket statement like the one proposed 
>>>>         
>>> below will ever 
>>>       
>>>> wrong) that the Security Considerations guidelines for MIB 
>>>>         
>>> documents 
>>>       

But compilers are allowed to toss the entire nacm:secure extension
statement.
We need this text inside standard YANG statements.

We should not micro-manage the description-stmt.
We should enumerate what is supposed to be in there, but
not any specific order or structure to the contents.

Also, the nacm:secure and nacm:very-secure extensions have
a specific meaning in NACM (read-only or no-access).
They are not intended to be used in every node as a documentation
mechanism.

Andy

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 18 Apr 2010 16:21:10 +0200

> From: Martin Bjorklund [mailto:[email-masked]] 

> > I agree. This seems to me the best variant of those discussed until 
> > now and is similar to what we do in MIB documents.
> 

Actually I incline towards placing the text describing the security
concerns in the Security Considerations section rather than overloading
the YANG module. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Apr 2010 09:22:27 -0700

> concerns in the Security Considerations section rather than overloading

This is fine with me.

We should optimize for the readers anyway.

Andy