Subject: [secdir] Security review of draft-ietf-netmod-yang-json-08

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 7 Mar 2016 15:16:00 -0700

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.

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."

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Mar 2016 16:31:09 +0100

Hi Hilarie,

thank you for the review, please se my responses inline.

>      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".

>    rules of this document and reply with an appropriate error message to

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.

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

> unaddressable question, but one does hope that the extreme situation

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Mar 2016 14:31:03 +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.

---

From: "Hilarie Orman" <[email-masked]>
Date: Thu, 17 Mar 2016 16:39:15 -0600

It is difficult to feel that the generic dont-worry response ("knows
what he or she is doing", "almost never", and "pay(s) attention to the
data model", etc.)  is sufficient to address security concerns.  My
review boils down to "surely you can do better", but I do not have the
expertise to write specific text that would improve the situation.

Hilarie

>  From: Stephen Farrell <[email-masked]>
>  Date: Thu, 17 Mar 2016 14:31:03 +0000

>  >>      Anydata data node serves as a container for an arbitrary set of n>  odes
>  >>      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 latt>  er
>  >>      case, converting JSON-encoded instances to the XML encoding defin>  ed
>  >>    counterparts.  To minimize these new security risks, software on th>  e
>  >>    rules of this document and reply with an appropriate error message >  to
>  >>    the sender."
>  > 
>  >>    notifications defined in YANG might transfer sensitive information.>  "
>  >>
>  >>    "YANG parsers need to be robust with respect to malformed documents>  .
>  >>    result in an attacker gaining privileges of the user running the YA>  NG
>  > verified. In the context of draft-ietf-netmod-yang-json, correctness ha>  s
>  > two aspects:
>  > 
>  > model to identify such data, and sec. 6 in RFC 6087 puts forward specif>  ic

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Mar 2016 23:51:23 +0000

Thanks Hilarie,

Ok, I'll take a peek again at the thread. For some reason
it was also daunting to me so I tried to re-delegate again,
I guess I find XML + anydata just off-putting as a concept;-)

Anyway, I'll get back tomorrow.

Cheers,
S.

On 17/03/16 22:39, Hilarie Orman wrote:
>>  >=20
>>  >=20
>>  >=20
>>  >> JSON Encoding of Data Modeled with YANG draft-ietf-netmod-yang-json-08=
> 
>>  >>
>>  >> state data, parameters of RPC operations or actions, and notifications=
> 
>>  >> defined using YANG as JavaScript Object Notation (JSON) text.  YANG is=
> 
>>  >> (NETCONF), NETCONF remote procedure calls, and NETCONF notifications."=
> 
>>  >>
>>  >> 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 n=
>>  odes
>>  >>      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 latt=
>>  er
>>  >>      case, converting JSON-encoded instances to the XML encoding defin=
>>  ed
>>  >=20
>>  > the consensus in the NETMOD WG was to keep the possibility that this is=
> 
>>  >=20
>>  > As long as we want to keep the option of specifying schema-less data in=
> 
>>  > ominous, also because normal configuration and state data should almost=
> 
>>  >=20
>>  >>    "JSON processing is rather different from XML, and JSON parsers may=
> 
>>  >>    counterparts.  To minimize these new security risks, software on th=
>>  e
>>  >>    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."
>>  >=20
>>  >=20
>>  >>    "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=
>>  =2E
>>  >>    Reading malformed documents from unknown or untrusted sources could=
> 
>>  >>    result in an attacker gaining privileges of the user running the YA=
>>  NG
>>  >=20
>>  > In fact, it is one of the most important virtues of data modelling that=
> 
>>  > verified. In the context of draft-ietf-netmod-yang-json, correctness ha=
>>  s
>>  > two aspects:
>>  >=20
>>  >=20
>>  >=20
>>  >=20
>>  >=20
>>  > model to identify such data, and sec. 6 in RFC 6087 puts forward specif=
>>  ic
>>  >=20