Re: [secdir] [Netconf] FW: secdir review of draft-ietf-netconf-monitoring
"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> Mon, 14 June 2010 08:33 UTC
Return-Path: <mehmet.ersue@nsn.com>
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 78AAF3A67ED; Mon, 14 Jun 2010 01:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 3knscs1rLS0w; Mon, 14 Jun 2010 01:33:45 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 304533A6403; Mon, 14 Jun 2010 01:33:44 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8Xcxr016371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jun 2010 10:33:38 +0200
Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5E8XcW6001119; Mon, 14 Jun 2010 10:33:38 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:33:38 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB0B9C.48D1DB2B"
Date: Mon, 14 Jun 2010 10:33:36 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64984329@DEMUEXC006.nsn-intra.net>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0402283402@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring
Thread-Index: AcsJPDm7J0T/WgkZRiK5BECk8I3z6wBwixgwAAClTwA=
References: <EDC652A26FB23C4EB6384A4584434A0402283402@307622ANEX5.global.avaya.com>
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: secdir@ietf.org, iesg@ietf.org, aland@freeradius.org
X-OriginalArrivalTime: 14 Jun 2010 08:33:38.0106 (UTC) FILETIME=[4932C9A0:01CB0B9C]
X-Mailman-Approved-At: Mon, 14 Jun 2010 08:03:01 -0700
Cc: "ext Romascanu, Dan (Dan)" <dromasca@avaya.com>, draft-ietf-netconf-monitoring@tools.ietf.org, netconf@ietf.org
Subject: Re: [secdir] [Netconf] FW: 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: Mon, 14 Jun 2010 08:33:50 -0000
Dear Alan, I agree that the security consideration section should inform on the use of secure transport with NETCONF. We addressed this issue in the new version of the security considerations template (see attached mail). As defined in RFC 4741 NETCONF protocol has to be used on top of a secure transport and a NETCONF implementation MUST support SSH as secure transport. I hope this addresses your request. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Romascanu, > Dan (Dan) > Sent: Sunday, June 13, 2010 3:44 PM > To: netconf@ietf.org > Subject: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring > > > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of > Alan DeKok > Sent: Friday, June 11, 2010 11:01 AM > To: secdir@ietf.org; IESG IESG; > draft-ietf-netconf-monitoring@tools.ietf.org > Subject: secdir review of draft-ietf-netconf-monitoring > > 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? > > A statement about privacy and security, with a reference to an > existing netconf document would be good. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >
--- Begin Message --------Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen Sent: Monday, June 14, 2010 11:16 AM To: netmod Working Group Subject: [netmod] [Fwd: 5th draft for yang module security considerations] Since the 4th draft, we have been informed of one typo that is fixed in this revision. Further, the security ADs wanted something added about secure transport of the data, and the secdir review of the netconf-monitoring draft also had questions about that. As a result, Juergen Schoenwaelder has suggested to add some text about that. The resulting text is now as below. Bert --- draft 5 for tang module security considerations: Each specification that defines one or more YANG modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at [ed: URL TBD]). In particular, writable data nodes that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out. Similarly, readable data nodes that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. Further, if new RPC operations have been defined, then the security considerations of each new RPC operation MUST be explained. X. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC4742]. -- if you have any writeable data nodes (those are all the -- "config true" nodes, and remember, that is the default) -- describe their specific sensitivity or vulnerability. There are a number of data nodes defined in this YANG module which are writable/creatable/deletable (i.e. config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g. edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: <list subtrees and data nodes and state why they are sensitive> -- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties) 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. These are the subtrees and data nodes and their sensitivity/vulnerability: <list subtrees and data nodes and state why they are sensitive> -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: <list RPC operations and state why they are sensitive> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod--- End Message ---
- [secdir] secdir review of draft-ietf-netconf-moni… Alan DeKok
- Re: [secdir] secdir review of draft-ietf-netconf-… Juergen Schoenwaelder
- Re: [secdir] secdir review of draft-ietf-netconf-… Alan DeKok
- Re: [secdir] secdir review of draft-ietf-netconf-… Juergen Schoenwaelder
- Re: [secdir] secdir review of draft-ietf-netconf-… Bert Wijnen (IETF)
- Re: [secdir] secdir review of draft-ietf-netconf-… Martin Bjorklund
- Re: [secdir] [Netconf] FW: secdir review of draft… Ersue, Mehmet (NSN - DE/Munich)
- Re: [secdir] secdir review of draft-ietf-netconf-… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-netconf-… Juergen Schoenwaelder
- Re: [secdir] secdir review of draft-ietf-netconf-… Juergen Schoenwaelder
- Re: [secdir] secdir review of draft-ietf-netconf-… Sam Hartman