Re: [secdir] secdir review of draft-ietf-netconf-monitoring

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 11 June 2010 08:10 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6966C3A68E0; Fri, 11 Jun 2010 01:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.384
X-Spam-Level:
X-Spam-Status: No, score=0.384 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWDycLXR-ett; Fri, 11 Jun 2010 01:10:13 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D47E23A68F0; Fri, 11 Jun 2010 01:10:12 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26D1FC0016; Fri, 11 Jun 2010 10:10:11 +0200 (CEST)
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 phpEH8gtXIOu; Fri, 11 Jun 2010 10:10:10 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A7BCC0032; Fri, 11 Jun 2010 10:09:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3881512F9717; Fri, 11 Jun 2010 10:09:56 +0200 (CEST)
Date: Fri, 11 Jun 2010 10:09:56 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Alan DeKok <aland@deployingradius.com>
Message-ID: <20100611080956.GA5257@elstar.local>
Mail-Followup-To: Alan DeKok <aland@deployingradius.com>, "secdir@ietf.org" <secdir@ietf.org>, IESG IESG <iesg@ietf.org>, "draft-ietf-netconf-monitoring@tools.ietf.org" <draft-ietf-netconf-monitoring@tools.ietf.org>
References: <4C11ED2B.1070707@deployingradius.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4C11ED2B.1070707@deployingradius.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "draft-ietf-netconf-monitoring@tools.ietf.org" <draft-ietf-netconf-monitoring@tools.ietf.org>, IESG IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-netconf-monitoring
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 11 Jun 2010 08:10:14 -0000

On Fri, Jun 11, 2010 at 10:00:43AM +0200, Alan DeKok wrote:
> 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.
> 
> The document defines a data model for netconf monitoring.  The security
> considerations section says in part:
> 
>    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.
> 
> What is unclear from the document is whether or not the data is secure
> *after* access is gained.  i.e. is there a secure transport layer?
> Should one be used?  If not, why?

NETCONF runs over SSH or TLS or TLS/BEEP or SOAP/HTTPS. In other
words, all existing NETCONF transports are "secure". The revision of
the NETCONF specification being worked on is going to make this
hopefully clearer by calling the transport layer "secure transports".

There has been progress very recently on formulating a security
considerations template for documents that contain NETCONF/YANG data
models and I think it would be good if this document would indeed
follow these guidelines.

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