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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 24 August 2016 15:34 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AB312DE32; Wed, 24 Aug 2016 08:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngT98JCn5f7v; Wed, 24 Aug 2016 08:34:23 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CD212DE85; Wed, 24 Aug 2016 08:24:43 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CA920F14; Wed, 24 Aug 2016 17:24:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dYm7V-X_agqF; Wed, 24 Aug 2016 17:24:28 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Aug 2016 17:24:40 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FB24200AB; Wed, 24 Aug 2016 17:24:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3gKrc7VmGk0G; Wed, 24 Aug 2016 17:24:39 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C40CE200A3; Wed, 24 Aug 2016 17:24:38 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B59303C30FB7; Wed, 24 Aug 2016 17:24:37 +0200 (CEST)
Date: Wed, 24 Aug 2016 17:24:37 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Susan Hares <shares@ndzh.com>
Message-ID: <20160824152437.GC17330@elstar.local>
Mail-Followup-To: Susan Hares <shares@ndzh.com>, 'Jeffrey Haas' <jhaas@pfrc.org>, 'Andy Bierman' <andy@yumaworks.com>, i2rs@ietf.org, 'Alissa Cooper' <alissa@cooperw.in>, i2rs-chairs@ietf.org, 'Kathleen Moriarty' <Kathleen.Moriarty.ietf@gmail.com>, 'IESG' <iesg@ietf.org>, 'Joel Halpern' <joel.halpern@ericsson.com>, 'Lou Berger' <lberger@labn.net>, draft-ietf-i2rs-protocol-security-requirements@ietf.org
References: <F8C205FB-665C-422C-B991-2F97F75CAE42@cooperw.in> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <a0e36f97-b62d-228f-f8f7-fadefd1570a1@labn.net> <CABCOCHStcL9-j_ZzG+J+Gj2=kx+N_F9WVzAVTU2pdnLo5dOF+g@mail.gmail.com> <20160822194549.GA5600@pfrc.org> <000d01d1fd74$53dcd4b0$fb967e10$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000d01d1fd74$53dcd4b0$fb967e10$@ndzh.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/_peLcKvdvJJoMSqCtoiqL8BpkCI>
X-Mailman-Approved-At: Fri, 26 Aug 2016 04:18:15 -0700
Cc: i2rs@ietf.org, 'Alissa Cooper' <alissa@cooperw.in>, 'Andy Bierman' <andy@yumaworks.com>, i2rs-chairs@ietf.org, 'Kathleen Moriarty' <Kathleen.Moriarty.ietf@gmail.com>, 'IESG' <iesg@ietf.org>, 'Jeffrey Haas' <jhaas@pfrc.org>, 'Joel Halpern' <joel.halpern@ericsson.com>, 'Lou Berger' <lberger@labn.net>, 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)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2016 15:34:27 -0000

I fail to understand why it makes a difference whether something is
accessed via pub/sub or in a more traditional way. We need to look at
this from an architectural point of view. And I am a big fan of the
separation of mechanism from policy [1].

The question what can be sent over an insecure transport is a policy
decision of a specific deployment and hard-coding such policies
statically in a data model scares me. SNMP got this piece right since
SNMP left it to the access control subsystem to take the decision and
thus policies could be flexible.

If there is a need to document common policies that certain
applications may find useful, then simply write them down as NACM
rules in XML. (The only little issue is that NACM today does not know
whether a request came via a non-secure transport since it assumes
there are only secure transports. But this seems to be fixable and
required to fix if NETCONF indeed introduces non-secure transports.)

/js

[1] https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy

On Tue, Aug 23, 2016 at 03:27:01PM -0400, Susan Hares 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.  
> 
> 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
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
> 

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