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

Sam Hartman <hartmans-ietf@mit.edu> Thu, 17 June 2010 00:26 UTC

Return-Path: <hartmans@mit.edu>
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 963013A67FA; Wed, 16 Jun 2010 17:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.875
X-Spam-Level:
X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
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 JvNB2-7QsO4J; Wed, 16 Jun 2010 17:26:43 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C5E193A67B5; Wed, 16 Jun 2010 17:26:40 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 243EF20394; Wed, 16 Jun 2010 20:26:45 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DCEEC40D4; Wed, 16 Jun 2010 20:26:33 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Alan DeKok <aland@deployingradius.com>
References: <4C11ED2B.1070707@deployingradius.com> <20100611080956.GA5257@elstar.local>
Date: Wed, 16 Jun 2010 20:26:33 -0400
In-Reply-To: <20100611080956.GA5257@elstar.local> (Juergen Schoenwaelder's message of "Fri, 11 Jun 2010 10:09:56 +0200")
Message-ID: <tsl631ipkqu.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: netconf@ietf.org, "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
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: Thu, 17 Jun 2010 00:26:44 -0000

>>>>> "Juergen" == Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

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

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

I'll admit that if I read the netconf document and it described
something as "secure transport," it would raise a concern in my mind.
"secure" as an adjective is generally meaningless.  Typically it's
applied to make people feel that security objectives are met without
actually stating those objectives.

Presumably by secure, you mean something like:

* Transport authenticates identity of server to client and client to
  server
* Transport provides integrity protection and confidentiality for data
  transported
* Transport provides replay protection on a per-session level as well as
  within a session

I'd be far more interested in the core document making these security
services explicit than in having it replace all instances of transport
with "secure transport."