Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]

From: Randy Presuhn <[email-masked]>
Date: Sun, 25 May 2014 23:08:52 -0700 (GMT-07:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: May 25, 2014 9:35 PM
>To: Randy Presuhn <[email-masked]>, [email-masked]
>Subject: Re: [netmod] trim vs. NACM [WAS: draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
...
>I still don't get it. The client had received the server's
>hello message so he knows the complete data model. Then, in
>my view, not receiving a node (subtree) is semantically
>equivalent to receiving it with the contents of <no-access/>.

No, the two are not semantically equivalent.
The server's hello message reveals the sorts
of things that are *potentially* present.
It doesn't identify all the instances.

So, for example, the hello message might tell
me that a system contains "jewels".  The hello
message does not tell me *which* jewels might
be there, but "access denied" responses allow
me to probe to see whether some jewels named
"crown" or "ER" are present, even if I lack
the authority to examine them.

>In your example, a client could receive something like
>
><sys:platform>
>  <nacm:no-access/>
></sys:platform>
>
>I don't see how this helps an attacker compared to the case when <sys:platform> is not present.

It's much more interesting in cases where multiple instances
of a resource may be present, and some instances are more
interesting than others.

>> Even in the case of HTTP, RFC 2616 section 10.4.4 on
>> "403 Forbidden" specifies that "[i]f the server does
>> not wish to make this information available to the client,
>> the status code 404 (Not Found) can be used instead."
>> That's also the motivation for disabling directory
>> listings on websites.
>
>This doesn't work for NETCONF/YANG exactly because the
>server reveals its full data model. It would make sense
>only if the server could suppress advertising parts of the
>data model or features.

I agree that the hello unnecessarily exposes information,
but that risk is mitigated to some extent by the fact
that hello only says what a system is capable of supporting,
and doesn't inform the attacker what is actually present
nor does it enumerate the instances.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 May 2014 08:26:13 +0200

> the authority to examine them.

If a user has no read access to a list node, say “jewel”, he should of course always receive the same data, no matter what the number of list entries is (even zero):

<jewel>
  <nacm:no-access/>
</jewel>

This gives no extra information to an attacker but still provides quite a useful clue to regular users.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 May 2014 09:21:44 -0700

On Sun, May 25, 2014 at 11:26 PM, Ladislav Lhotka <[email-masked]> wrote:

> >> Subject: Re: [netmod] trim vs. NACM [WAS:
> draft-ietf-netmod-routing-cfg-14.txt (review of changes)]
> > ...
> If a user has no read access to a list node, say "jewel", he should of
> course always receive the same data, no matter what the number of list
> entries is (even zero):
>
> <jewel>
>   <nacm:no-access/>
> </jewel>
>

It tells an unauthorized user that the data they are trying to hack does
in fact exist on the device.  That is disclosure of unauthorized
information.

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 May 2014 18:36:56 +0200

On 26 May 2014, at 18:21, Andy Bierman <[email-masked]> wrote:

> in fact exist on the device.  That is disclosure of unauthorized information.

No, it isn’t. As I wrote, the same element would be returned even if there are no instances of the “jewel” list at all. The node exists in server’s data model but the attacker already knows this. On the other hand, a proper client needn’t guess whether no instances are present because none were configured or whether they were filtered by access control.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 May 2014 09:43:36 -0700

On Mon, May 26, 2014 at 9:36 AM, Ladislav Lhotka <[email-masked]> wrote:

> No, it isn't. As I wrote, the same element would be returned even if there
> are no instances of the "jewel" list at all. The node exists in server's
> data model but the attacker already knows this. On the other hand, a proper
> client needn't guess whether no instances are present because none were
> configured or whether they were filtered by access control.
>
>
You mean the same data structure, except for the <nacm:no-access/> leaf
that tells the client "the parent contains child nodes you are
not allowed to even know about."  The insertion of a "you found something
interesting" flag for attackers to use does not seem like a great idea.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 26 May 2014 18:58:57 +0200

> interesting" flag for attackers to use does not seem like a great idea.

Clever attackers already know there might be something interesting from the data model. The only new information is that some (unspecified) access control is applied to a particular node but in most cases this will be hardly surprising. 

Lada