Subject: Re: [netmod] 4th draft for yang module security considerations

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 May 2010 10:39:02 +0200

FYI - this is going out to the Security AD's. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Tuesday, April 27, 2010 9:24 PM
> To: Bert Wijnen (IETF); Mark Ellison
> Cc: NETMOD Working Group
> Subject: Re: [netmod] 4th draft for yang module security 
> considerations
> 
> If there are no major issues I propose that we send this 
> version to the Security ADs for review (with nits fixed)
> 
> If there still are major issues please jump in in the next two days. 
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
> > Sent: Tuesday, April 27, 2010 9:04 PM
> > To: Mark Ellison
> > Cc: NETMOD Working Group
> > Subject: Re: [netmod] 4th draft for yang module security 
> > considerations
> > 
> > Yep. Thanks Mark.
> > 
> > Bert
> > ----- Original Message -----
> > From: "Mark Ellison" <[email-masked]>
> > To: "Bert Wijnen (IETF)" <[email-masked]>
> > Cc: "NETMOD Working Group" <[email-masked]>
> > Sent: Tuesday, April 27, 2010 7:27 PM
> > Subject: Re: [netmod] 4th draft for yang module security 
> > considerations
> > 
> > 
> > > Bert,
> > >
> > > One minor editorial nit in the following:
> > >
> > >> Further, if new RPC operations have been defined, then it the 
> > >> security considerations of each new RPC operation MUST be 
> > >> explained.
> > >
> > > s/then it the/then the/
> > >
> > > Regards,
> > >
> > > Mark
> > >
> > > On Tue, Apr 27, 2010 at 3:50 AM, Bert Wijnen (IETF)
> > > <[email-masked]>wrote:
> > >
> > >> We had quite a few discussions on the 3rd revision.
> > >> From my reading however, it seems we more or less agree that:
> > >>
> > >> - security considerations must be listed in the SC 
> section and  not 
> > >> in a separtely tagged description clause with the
> > nodes  themselves.
> > >> - we cannot do a blanket statement that basically ALL 
> config data  
> > >> is sensitive
> > >> - it is OK toi list a container or node list if all the 
> leaves have  
> > >> the sanme/similar secuirty considereations.
> > >> Based on that, I think it is best to make that last point
> > more explicit.
> > >> I basically had that, but I was still using the MIB term
> > of "subtrees".
> > >> So the 4th revision (last??) of the template-text would be as
> > >> follows:
> > >>
> > >> ----
> > >>
> > >>  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 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  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.
> > >>
> > >>  Note: it is best to list a container or list node if all the  
> > >> leaves in the container or list node share the same  or similar 
> > >> security considerations.
> > >>
> > >> 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 
> containers, 
> > >> list nodes and data nodes with their specific
> > >> sensitivity/vulnerability:
> > >>
> > >> <list containers, list nodes or data nodes, 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
> > >> -- unauthorized 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 
> > >> containers, list nodes and data nodes with their specific
> > >> sensitivity/vulnerability:
> > >>
> > >> <list containers, list nodes or data nodes, 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>
> > >>
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >>
> > > 
> > 
> > _______________________________________________
> > netmod mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>