Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 11 March 2016 00:56 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2872612DF4D; Thu, 10 Mar 2016 16:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cj2lFCdJyVzN; Thu, 10 Mar 2016 16:56:01 -0800 (PST)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C08912DF47; Thu, 10 Mar 2016 16:56:01 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id 124so81797842pfg.0; Thu, 10 Mar 2016 16:56:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=gumtKCDqNgGInsae8hCxEzHbjv3KX0I5WUy19jhvhFw=; b=sDn2mlIDXMaGk4WFoKCAHpt5XGhsYhvU4g5hGb3uk5TYiS/ojIk8uqr+28t+gGGHHY 2NV48EL9cb/IaDpJnaS2NdA57TYhImcT1HtkbzYkSCngiwrNcSjxERV16azro4BxLgob e2aBNFnKsQSOPQ44HPGIcHuV7jTJXrYjtUhzWunAyBJmnGr8DKJao+OLr6dCvueyS3S/ o/6kHXeRBAu71Egdt4efqyrd8F9NSAq6XlSDN2Ddk9l3FQvDigk4Ao+txCvz0RuX5Ly8 d1HpG1saYZxONmHTHxhyde0DIBnKdWvQispXe6cbwBv/fqwg8dSxsYxQ7mx+Hd1aN2Pb YPRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gumtKCDqNgGInsae8hCxEzHbjv3KX0I5WUy19jhvhFw=; b=c1opfqFKlhArafZ2JhGu4MjqDgstUYpVaGxSIxVi6i6dD8ytKZKhZ+XOkSqCYp0t8/ mi2alFCwS7avqry52vUOjiJ7HkLagJfDA70GzwhgLUFfhIzqHxDsDa7exy7NuYMWCd6V 31Lt2/bXBDtz/DYpUjwHLJu/bBqVuj9UhRJ+DasJ5eNAp87qrobFoW/vCCREmPSGaqNT OHHoL8FT5SB+jWDzUxHi0o+pOtzc1MJPpUqdt6VwJFbY2SQgcMRl7YOjaob/6lVWhr7L lFpU5uaroU22foUaT/FSsisvA63CJwGyxRaNnNvk7j1v88whXZMorHPj8WqKIA5v+b28 h8kA==
X-Gm-Message-State: AD7BkJKZHCUWca5YR3qPu/lfflOQei4f5Tws0tsuHMcP+yvAGwLkrYOmMzgFMuRltPkr2A==
X-Received: by 10.98.71.149 with SMTP id p21mr9335151pfi.133.1457657760631; Thu, 10 Mar 2016 16:56:00 -0800 (PST)
Received: from ?IPv6:2001:420:290:1330:d51a:b8bc:3a23:fcd? ([2001:420:290:1330:d51a:b8bc:3a23:fcd]) by smtp.gmail.com with ESMTPSA id o185sm8175266pfo.36.2016.03.10.16.55.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Mar 2016 16:55:59 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_28763446-A8CE-48F8-BE37-2C9EA6CEF8F2"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <2BC76448-BCD9-4B69-AF8E-A1D81D40A33B@gmail.com>
Date: Thu, 10 Mar 2016 16:55:59 -0800
Message-Id: <B6D4A996-020E-4F8C-9282-4B4176FB05E2@gmail.com>
References: <ldvbn7z6f7s.fsf@sarnath.mit.edu> <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> <ldvwppsjnde.fsf@sarnath.mit.edu> <2BC76448-BCD9-4B69-AF8E-A1D81D40A33B@gmail.com>
To: Tom Yu <tlyu@mit.edu>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/KfDnCi2fEYb_2ek8h7WKvcbHtSM>
Cc: draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Fri, 11 Mar 2016 00:56:03 -0000

Tom,

Any update from your side?

> On Feb 26, 2016, at 3:12 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> 
> Tom,
> 
> Thanks for getting back to us. 
> 
> At the outset let me just say that this draft is defining a new mechanism for advertisement of capabilities within YANG modules. As such, the security considerations for this document are not very different from the security considerations one might have using the NETCONF protocol today. Some of the information is already being exchanged today through other mechanisms. 
> 
> To your specific comments...
> 
>> On Feb 25, 2016, at 5:01 PM, Tom Yu <tlyu@mit.edu <mailto:tlyu@mit.edu>> wrote:
>> 
>> Hi Mahesh,
>> 
>> Sorry about the delay.
>> 
>> I was looking at the specific comments in the Security Considerations of
>> this document about the sensitivity of the contents of /modules/module.
>> How do the risks of an attacker being able to inspect /modules/module
>> compare with other information that could be available to an attacker,
>> such as fingerprinting through non-NETCONF means?
> 
> The attacker may have better success getting the information through some other means, and even then the information would be no more damaging than what they would be able to see if they had the right SSH/NACM credentials.
> 
>> 
>> If an attacker has limited NETCONF access on a server, what would the
>> contents of /modules/module reveal to the attacker that might not
>> otherwise be discovered by other kinds of probing within the NETCONF
>> protocol?
> 
> With limited access most of the information about the modules/module will not be visible.
> 
>> 
>> These other risks might be trivial in comparison to the one mentioned in
>> the document, but lacking specific knowledge of the broader context of
>> NETCONF and how it is deployed, I'm not sure how they compare.  For
>> example, is it expected that anonymous or minimally trusted users could
>> be authorized to use NETCONF to access some public information about a
>> server?
> 
> No. There is no anonymous or minimal trusted user account (by default). Accounts have to be setup for users to access the box over NETCONF and then they are typically assigned to a authorized group with specific permissions.
> 
> Thanks.
> 
>> 
>> If these other risks are similar in magnitude to the possible exposures
>> allowed by /modules/module, you should consider mentioning them, and
>> give the implementor or operator some guidance about how to weigh these
>> risks.  If the exposures allowed by /modules/module vastly outweigh
>> those from other avenues of obtaining similar capability or
>> configuration information, in most environments and forseeable
>> deployments, maybe the current text is sufficient.
>> 
>> -Tom
>> 
>> Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> writes:
>> 
>>> Tom,
>>> 
>>> It is not entirely clear from this e-mail, what action you want the authors to take. 
>>> 
>>> YANG module information or more like its encodings are sent over a secure session (SSH/TLS) and are no more specific to this draft than they are to any NETCONF/RESTCONF session. As such it is not clear what you want  the authors to do. Could you clarify or provide text for the Security Consideration section?
>>> 
>>> Thanks.
>>> 
>>>> On Feb 1, 2016, at 6:03 PM, Tom Yu <tlyu@mit.edu <mailto:tlyu@mit.edu>> 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 Security Considerations of this document seem reasonable.  It might
>>>> be useful to add a comparison of the risks posed by sensitive
>>>> information exposed by this YANG module with information exposed by
>>>> other aspects of NETCONF, or available through methods such as
>>>> fingerprinting.  Admittedly, a meaningful comparison might be highly
>>>> context-specific, so a general comparison might have limited utility.
>>> 
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
> 
> 
> 

Mahesh Jethanandani
mjethanandani@gmail.com