Re: [secdir] SecDir review of draft-ietf-ipfix-mib-variable-export.

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 19 November 2015 15:34 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7041B2B70 for <secdir@ietfa.amsl.com>; Thu, 19 Nov 2015 07:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.435
X-Spam-Level:
X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham
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 arLiFdP8oeBL for <secdir@ietfa.amsl.com>; Thu, 19 Nov 2015 07:34:25 -0800 (PST)
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 CABAE1B2B6E for <secdir@ietf.org>; Thu, 19 Nov 2015 07:34:24 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9622D1033; Thu, 19 Nov 2015 16:34:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6Du-27ZcXiGB; Thu, 19 Nov 2015 16:34:21 +0100 (CET)
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; Thu, 19 Nov 2015 16:34:21 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB7BA20055; Thu, 19 Nov 2015 16:34:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9PYaTAC0_7tq; Thu, 19 Nov 2015 16:34:19 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64D702003B; Thu, 19 Nov 2015 16:34:19 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1F98A38E35FE; Thu, 19 Nov 2015 16:34:17 +0100 (CET)
Date: Thu, 19 Nov 2015 16:34:17 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Paul Aitken <paitken@brocade.com>
Message-ID: <20151119153417.GB3518@elstar.local>
Mail-Followup-To: Paul Aitken <paitken@brocade.com>, Benoit Claise <bclaise@cisco.com>, Warren Kumari <warren@kumari.net>, IETF Security Directorate <secdir@ietf.org>, draft-ietf-ipfix-mib-variable-export.all@tools.ietf.org
References: <CAHw9_i+qp7Y1Eu8YiJj6AOUG22NMz=1PCK3k=BkHoxPgxR-8rw@mail.gmail.com> <20151118101339.GA17028@elstar.local> <564CA202.8030605@cisco.com> <564DE0BE.5080200@brocade.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <564DE0BE.5080200@brocade.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/mH6-sLQoUZlg0syV_iF0r1OiOUA>
Cc: Benoit Claise <bclaise@cisco.com>, draft-ietf-ipfix-mib-variable-export.all@tools.ietf.org, IETF Security Directorate <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mib-variable-export.
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2015 15:34:29 -0000

See my latest suggestion which adds a bunch of references to the third
paragraph - which was the original request of the security directorate
reviewer.

    However, if the exporter is implemented as an SNMP manager
    accessing an SNMP agent, it MUST authenticate itself to the SNMP
    agent [RFC3414], [RFC5591], [RFC5592], RFC6353] and the SNMP agent
    MUST enforce SNMP access control rules [RFC3415] as required by
    the SNMP architecture [RFC 3411].

The additional sentence is somewhat unclear:

    [...] An Exporter MUST NOT bypass SNMP access control rules to
    export a MIB object for which it is not granted access.

Does this apply to any exporter or only to an exporter implemented as
an SNMP manager accessing an SNMP agent? In the later case, I would
say this sentence is not needed since the sentence before already says
that the SNMP agent MUST enforce SNMP access control rules (and this
is the entity that has knowledge about the access control rules). In
the former case, more information would be needed since in order to
apply SNMP access control rules, you need to have an authenticated
identity to work with.

/js

On Thu, Nov 19, 2015 at 02:46:22PM +0000, Paul Aitken wrote:
> I've updated section 10 to capture both of these comments.
> 
> Note that I haven't yet addressed Sephen Farrell's comment on privacy, 
> which will also be in this section.
> 
> 
>   10.  Security Considerations
> 
>      For this extension to the IPFIX protocol, the same security
>      considerations as for the IPFIX protocol apply [RFC7011].
> 
>      If the exporter is generating or capturing the field values itself,
>      e.g. using the MIB objects only as an encoding or type mechanism,
>      there are no extra security considerations beyond standard IPFIX.
> 
>      However, if the exporter is implemented as an SNMP manager accessing
>      an SNMP agent, it MUST authenticate itself to the SNMP agent and the
>      SNMP agent MUST enforce SNMP access control rules as it would for any
>      other SNMP manager.  An Exporter MUST NOT bypass SNMP access control
>      rules to export a MIB object for which it is not granted access.
> 
>      The access to particular MIB objects is controlled by the
>      configuration of the IPFIX exporter.  This is consistent with the way
>      IPFIX controls access to other Information Elements in general.
> 
>      The configuration of an IPFIX Exporter determines which MIB objects
>      are included in IPFIX Data Records sent to certain collectors.
>      Network operators should take care that the only MIB objects which
>      are included in IPFIX Data Records are ones which the receiving flow
>      collector is allowed to receive.
> 
> P.
> 
> On 18/11/15 16:06, Benoit Claise wrote:
> >On 11/18/2015 11:13 AM, Juergen Schoenwaelder wrote:
> >>On Sat, Nov 14, 2015 at 02:17:20AM +0900, Warren Kumari wrote:
> >>>Be ye not afraid...
> >>>I have reviewed this document as part of the security directorate's
> >>>ongoing effort to review all IETF documents being processed by the
> >>>IESG.  These comments were written primarily for the benefit of the
> >>>security area directors.  Document editors and WG chairs should treat
> >>>these comments just like any other last call comments.
> >>>
> >>>Version reviewed: draft-ietf-ipfix-mib-variable-export-09 - Exporting
> >>>MIB Variables using the IPFIX Protocol
> >>>
> >>>Summary:
> >>>LGTM, Security AD attention not required, modulo questions below.
> >>>
> >>>I'm not quite sure what:
> >>>"However if the exporter is a client of an SNMP engine on the same
> >>>  device it MUST abide by existing SNMP security rules." is supposed to
> >>>mean. What exactly are "existing SNMP security rules"? Those defined
> >>>in RFCs? Configured on the device?
> >>I agree that this statement is a bit confusing. In the SNMP world, a
> >>client must authenticate against the agent and then the agent uses the
> >>clients authenticated identity to apply access control rules. This text
> >>talks about a client of an "SNMP engine", which is a bit confusing.
> >>
> >>Perhaps the sentence was meant to say this:
> >>
> >>      However, if the exporter is implemented as an SNMP manager
> >>      accessing an SNMP agent, it MUST authenticate itself to the SNMP
> >>      agent and the SNMP agent MUST enforce SNMP access control rules
> >>      as it would for any other SNMP manager.
> >Yes, that was the meaning.
> >For example, we can't export via IPFIX a MIB object for which we're 
> >not granted access, completely bypassing the SNMP access control rules
> >
> >Regards, Benoit (as a document author)
> >>
> >>/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/>