Re: [secdir] Security review of draft-ietf-netmod-yang-json-08
Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 17 March 2016 14:31 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 7A4D012D5A7; Thu, 17 Mar 2016 07:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 K3VxgrWJuOcx; Thu, 17 Mar 2016 07:31:13 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8138312D50F; Thu, 17 Mar 2016 07:31:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4C255BE59; Thu, 17 Mar 2016 14:31:12 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RMpP4TgI4Af; Thu, 17 Mar 2016 14:31:04 +0000 (GMT)
Received: from [10.87.48.83] (unknown [86.42.16.188]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E6762BE57; Thu, 17 Mar 2016 14:31:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458225064; bh=wJPOlEqb6GeYv/EZPw+Lk1YIUXwhVTexst7uZ4oD2kI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=r5TUp6a/dH2XjVOODRUYlDmZDxZdq1k/Y1kIC/yL0bdvuJJzyvnhZuR4YS3iiM9in jY80uGGzG++ta3CXXXtqYPoji3hqGGmYJPOy/ogWBnXV7TIuryAG3oSsE5mFwacOah g4ov/x/y0mQkzzUNBbSP2sumtRXKTdEMQVj4Gkr8=
To: Ladislav Lhotka <lhotka@nic.cz>, Hilarie Orman <hilarie@purplestreak.com>, iesg@ietf.org, secdir@ietf.org
References: <201603072216.u27MG09g002861@rumpleteazer.rhmr.com> <m2r3flouki.fsf@birdie.labs.nic.cz>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56EABFA7.6050506@cs.tcd.ie>
Date: Thu, 17 Mar 2016 14:31:03 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <m2r3flouki.fsf@birdie.labs.nic.cz>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020409070901080509020200"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/J9xcCDLu8xWmk6JxZOtknGTX0zA>
Cc: draft-ietf-netmod-yang-json.all@tools.ietf.org
Subject: Re: [secdir] Security review of draft-ietf-netmod-yang-json-08
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: Thu, 17 Mar 2016 14:31:16 -0000
Hi folks, This thread seemed to just trail off. Hilarie, did you want to follow up more or do we think the document is all set? Thanks, S. On 08/03/16 15:31, Ladislav Lhotka wrote: > Hi Hilarie, > > thank you for the review, please se my responses inline. > > Hilarie Orman <hilarie@purplestreak.com> writes: > >> Security review of >> JSON Encoding of Data Modeled with YANG draft-ietf-netmod-yang-json-08 >> >> Do not be alarmed. 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. >> >> "This document defines encoding rules for representing configuration, >> state data, parameters of RPC operations or actions, and notifications >> defined using YANG as JavaScript Object Notation (JSON) text. YANG is >> a data modeling language originally designed to model configuration >> and state data manipulated by the Network Configuration Protocol >> (NETCONF), NETCONF remote procedure calls, and NETCONF notifications." >> >> I have no specific recommendation for an action on this, just >> some observations. >> >> I'm not an expert on YANG, JSON, or XML, but I was taken aback to read >> in section 5.5: >> >> Anydata data node serves as a container for an arbitrary set of nodes >> that otherwise appear as normal YANG-modeled data. A data model for >> anydata content may or may not be known at run time. In the latter >> case, converting JSON-encoded instances to the XML encoding defined >> in [I-D.ietf-netmod-rfc6020bis] may be impossible. > > An "anydata" node represents data for which no schema is specified in > the data model. The schema for such data may be known at run time, but > the consensus in the NETMOD WG was to keep the possibility that this is > not the case. And if the schema is not available, translation between > XML and JSON encodings cannot be done because, for example, we use the > data model info for translating namespace identifiers. > > As long as we want to keep the option of specifying schema-less data in > the data model, we have to live with this. I don't think it is really > ominous, also because normal configuration and state data should almost > never be modelled with "anydata". > >> >> That seems ominous, and there are other warnings about the force >> fitting of JSON and XML: >> >> "JSON processing is rather different from XML, and JSON parsers may >> thus suffer from other types of vulnerabilities than their XML >> counterparts. To minimize these new security risks, software on the >> receiving side SHOULD reject all messages that do not comply to the >> rules of this document and reply with an appropriate error message to >> the sender." > > Implementors might be tempted to apply the Postel Principle and be > liberal on the receiving side. This paragraph warns against doing so, > unless, of course, the implementor knows what he or she is doing. > >> >> The security section refers back to the security considerations in >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-11 >> section 16 (should be 17) where we read: >> >> "Data modeled in YANG might contain sensitive information. RPCs or >> notifications defined in YANG might transfer sensitive information." >> >> "YANG parsers need to be robust with respect to malformed documents. >> Reading malformed documents from unknown or untrusted sources could >> result in an attacker gaining privileges of the user running the YANG >> parser. In an extreme situation, the entire machine could be >> compromised." >> >> There being no succinct description of correctness of YANG, JSON, or >> XML for NETCONF data, how would one determine that any of it, >> including mappings from one to another, was "robust"? If that simply > > In fact, it is one of the most important virtues of data modelling that > the correctness of configuration or state data can be reliably > verified. In the context of draft-ietf-netmod-yang-json, correctness has > two aspects: > > 1. All data is required to be I-JSON compliant [RFC 7493] which helps > avoid common JSON-specific interoperability and security problems. > > 2. The data model precisely specifies the schema, data types of all > values, and also semantic constraints. > > If an implementor pays attention to data model definitions (including > textual descriptions), then I believe the risk of any data-induced > issues is effectively minimised. > >> means "doesn't cause a buffer overflow or crash", I suppose it's >> achievable (and should be explicit). But how could anyone be sure >> that sensitive data was not leaked without a full analysis of the >> specifications of all the component parts? Perhaps this is an >> unaddressable question, but one does hope that the extreme situation >> does not occur. >> > > This question isn't specific to this document - sensitive data may be > present in any encoding. It is also one of the duties of a good data > model to identify such data, and sec. 6 in RFC 6087 puts forward specific > requirements in this direction. > > Thanks, Lada >
- [secdir] Security review of draft-ietf-netmod-yan… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-netmod… Ladislav Lhotka
- Re: [secdir] Security review of draft-ietf-netmod… Stephen Farrell
- Re: [secdir] Security review of draft-ietf-netmod… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-netmod… Stephen Farrell