Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

On Tue, Aug 23, 2016 at 12:27 PM, Susan Hares <shares@ndzh.com> wrote:

> Jeff:
>
> Thank you your comments.   I agree with your assessment of the WG's
> desires.
> It provides a helpful context for the IESG members.
>
> As I mentioned in another email, one of the first mechanisms is to describe
> what portions of an data model can be sent in the PUB/SUB Push via a
> non-secure HTTP session or what require a secure HTTP session.
>
> Sue
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Monday, August 22, 2016 3:46 PM
> To: Andy Bierman
> Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder;
> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Joel Halpern; Lou Berger;
> Susan Hares; draft-ietf-i2rs-protocol-security-requirements@ietf.org
> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
> I'm lagging in my email, as usual.  However, this one caught my eye:
>
> On Fri, Aug 19, 2016 at 07:23:47AM -0700, Andy Bierman wrote:
> > We could have been tagging MIB objects all along, but we don't.
> > Imagine if there was a debate for every single OBJECT-TYPE macro "is
> > this leaf OK for noAuth/noPriv?"
> >
> > Are there even clear SEC-DIR guidelines on how one would decide this
> > debate in a WG? Does SEC-DIR really want to be flooded with review
> > requests so they become a bottleneck in YANG RFC publication process?
>
> I wanted to point out some of the per-object security evaluation that is
> already imposed on MIB modules.  Consider the following text from RFC 4273:
>
> :    There are a number of managed objects in this MIB that contain
> :    sensitive information regarding the operation of a network.  For
> :    example, a BGP peer's local and remote addresses might be sensitive
> :    for ISPs who want to keep interface addresses on routers confidential
> :    in order to prevent router addresses used for a denial of service
> :    attack or spoofing.
> :
> :    Therefore, it is important in most environments to control read
> :    access to these objects and possibly to even encrypt the values of
> :    these object when sending them over the network via SNMP.
>
> In some respect, the discussion with regard to I2RS annotation of yang
> nodes
> with security considerations have precedence.  It could be done in the
> containing documents' security considerations section.  It could be part of
> the description clause for the node.
>
> Having some notion of the consideration available as a machine-parseable
> markup thus doesn't seem completely unreasonable.
>
> The essence of your point, Andy, and I believe Juergen's is given a
> presmise
> of "secure by default", is it okay to mark things as "the author of this
> module believes this to be okay to be insecure by default"?
>
> Possibly not.  As you both mention, it will depend on the circumstances of
> a
> given operator's deployment.
>

I believe the actual annotation needs to apply to a specific subtree.
There are corner-cases where the module-wide annotation does not work
(such as groupings used in a different module).

IMO the annotation needs to apply only to descendant-or-self nodes
in the same module namespace.

>
> The underlying I2RS question is how to mark nodes in such a way that the
> insecure transport protocols may be permitted to publish them without
> requiring every single node to be audited if you have relatively weak
> deployment considerations?  If the answer is "read the security
> considerations and write a filter", it's not the answer i2rs is looking
> for.
>
>
> -- Jeff
>

Andy

>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
>