Subject: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change

From: Benoit Claise <[email-masked]>
Date: Thu, 2 Nov 2017 15:18:44 +0100

Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by 
the Security AD Eric Rescola part of the IESG review, which I would like 
to validate with the WG. See 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt

The NETCONF WG was cc'ed for the entire discussion.
What do you think? I will draw the conclusions by Friday Nov 10th.

Note: If the WG is fine, the next step is to approve this document.

Regards, Benoit

---

From: Kent Watsen <[email-masked]>
Date: Thu, 2 Nov 2017 14:54:44 +0000

Looks okay.

Kent // contributor

On 11/2/17, 10:18 AM, "Netconf on behalf of Benoit Claise" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetconf-2Drfc6536bis-2D08.txt&d=DwMCaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=69uf3w40pQxK9GfYDzu-d1S6Wwv-VTobrIC7GY7auw8&s=Kg17X1i2nfDWgoEYuD4uhq3595q3JJM5fdSMAmbaUgw&e=>

Regards, Benoit

---

From: Robert Wilton <[email-masked]>
Date: Wed, 8 Nov 2017 16:33:10 +0000

Hi,

I'm not sure about this change.

I'm not that familiar with NACM, but if you want to give a particular 
set of users read/write access to a subtree, but not allow them to have 
any other access to the configuration in the running datastore then with 
the existing RFC, that could be expressed with a single rule (example in 
6536bis, appendix B.4)

With this new change, I think that you may need to configure many more 
rules to achieve the same thing.  I think that you would need to give 
read access to the top node in the desired path, and then separate 
explicit "deny" rules for every sibling child node walking from the top 
of the tree down to the data node that read/write access is actually 
being given to.  The example below may explain my understanding better:

E.g. For a tree of data nodes, rooted at A, if we wanted to give 
read/write access only to "J" subtree, and no access for the rest of the 
tree then:

                  A
                  |
         --------------------
         |      |     |     |
         B      C     D     E
         |
    -----------
    |   |  |  |
    F   G  H  J
              |
             ...

In the old model, I think that the ACL rules would be 1 rules long 
(assuming default deny all):
    "read/write 'A/B/J'

In the new model, I think that the equivalent ACL rules would need to be 
8 rules long (assuming default deny all):
    "read/write 'A/B/J'
    "read A"
    "deny C"
    "deny D"
    "deny E"
    "deny F"
    "deny G"
    "deny H"

Note, I am assuming that a "path" rule matches for the given path and 
all descendant nodes.  The draft doesn't seem to be particularly clear 
on this point (it states that the rule applies when the path matches, 
but this would seem to be counter intuitive), and perhaps it could be 
clarified.

If this change is allowed, then the example in appendix B.4 looks like 
it would need to be fixed, since the "limited-acl" probably wouldn't 
give any access at all, unless default read access had been given.

But, possibly I'm misunderstanding how this all works!  If so, apologies 
for the noise :-)

Thanks,
Rob

On 02/11/2017 14:18, Benoit Claise wrote:
> the Security AD Eric Rescola part of the IESG review, which I would 
> like to validate with the WG. See 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 8 Nov 2017 11:23:45 -0800

Hi,

On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <[email-masked]> wrote:

> I'm not that familiar with NACM, but if you want to give a particular set
> of users read/write access to a subtree, but not allow them to have any
> other access to the configuration in the running datastore then with the
> existing RFC, that could be expressed with a single rule (example in
> 6536bis, appendix B.4)
>
> rules to achieve the same thing.  I think that you would need to give read
> access to the top node in the desired path, and then separate explicit
> "deny" rules for every sibling child node walking from the top of the tree
> down to the data node that read/write access is actually being given to.
> The example below may explain my understanding better:
>
> In the new model, I think that the equivalent ACL rules would need to be 8
> rules long (assuming default deny all):
>    "read/write 'A/B/J'
>    "read A"
>    "deny C"
>    "deny D"
>    "deny E"
>    "deny F"
>    "deny G"
>    "deny H"
>

If the /nacm/read-default is "permit" then these deny rules might be needed.

In the current NACM, you only need a rule allowing write-access to J.
This could be via a module rule, not just data rule (e.g. J is from augment
and the user has write access to the module defining J)

In the new NACM, (assuming default-read="deny") you would need rules
allowing
a read on /A and /A/B, even though the access operation is "none" for these
nodes.

Note, I am assuming that a "path" rule matches for the given path and all
> descendant nodes.  The draft doesn't seem to be particularly clear on this
> point (it states that the rule applies when the path matches, but this
> would seem to be counter intuitive), and perhaps it could be clarified.
>
> If this change is allowed, then the example in appendix B.4 looks like it
> would need to be fixed, since the "limited-acl" probably wouldn't give any
> access at all, unless default read access had been given.
>
>

limited-acl (permit-exec rule) would only allow exec access to actions if
the group has
read permission on the ancestor nodes.  The 'comment' field could be
updated to point that out.
There is no affect on executing <rpc> operations, just <action>.

> Rob
Andy

> Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the
> Security AD Eric Rescola part of the IESG review, which I would like to
> validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-
> netconf-rfc6536bis-08.txt
>
>
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 8 Nov 2017 12:05:29 -0800

Hi,

This change has no impact on the server if /nacm/read-default is "permit".
In that case, the extra read rules for /A and /A/B are not needed.
An operator worried about read access should set read-default to "deny".
In that case, explicit rules to read /A and /A/B would be needed
in the new NACM.  The deny rules would not be needed.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 9 Nov 2017 10:44:57 +0000

Hi Andy,

It isn't clear to me whether matching a path in NACM either:
   (i) Only applies to the specific node, and not any children, or
   (ii) Applies to the specific node and all descendant children nodes 
as well.

As an example, using the tree below.  if I have a rule that matches path 
"A/B" then does that apply to only the specific node "A/B", or does it 
also apply to all descendant children of "A/B" as well?

In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", step 6 
states:

         *  The rule does not have a "rule-type" defined or the "rule-
            type" is "data-node" and the*"path" matches the requested data node*, action node, or notification node.

My reading of this is that it implies that the interpretation of the 
path rule is (i), but this is not how I would normally expect an ACL 
rule to apply in a tree like object (e.g a directory file system).

However, the examples in Appendix B.4. imply that the path rule is to be 
interpreted like (ii), or otherwise the example rules seem to be mostly 
pointless.

E.g. taking this example from appendix B.4:

        <rule>
          <name>permit-dummy-interface</name>
          <path xmlns:acme="http://example.com/ns/itf">
            /acme:interfaces/acme:interface[acme:name='dummy']
          </path>
          <access-operations>read update</access-operations>
          <action>permit</action>
          <comment>
            Allow the limited and guest groups read
            and update access to the dummy interface.
          </comment>
        </rule>

If the rule is (i)  then the access rule allows the client to read the 
specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but 
not any child leafs/containers of that interface, this doesn't seem useful.

Further comments inline below ...

> In that case, the extra read rules for /A and /A/B are not needed.
I agree.

> An operator worried about read access should set read-default to "deny".
I agree.  This is the scenario that I'm considering.

> in the new NACM.
Yes, if the interpretation of the rule is (i) above.
Otherwise if the interpretation is (ii) then you only need "read /A" 
since that implies "read A/B" as well (as long as the rules are listed 
in the correct order).

>   The deny rules would not be needed.
Only if the interpretation of the rule is (i) above.  In which case the  
"read/write 'A/B/J' rule would not be sufficient.  It would be necessary 
to define an Xpath expressions that contains all children nodes as 
well.  Perhaps 'A/B/J//*'?

If the interpretation of the rule is (ii) then you would also need all 
the explicit deny statements as well, otherwise they would be allowed by 
the "read /A" rule above.

Thanks,
Rob

>
>
> Andy
>
>
> On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     I'm not that familiar with NACM, but if you want to give a
>     particular set of users read/write access to a subtree, but not
>     allow them to have any other access to the configuration in the
>     running datastore then with the existing RFC, that could be
>     expressed with a single rule (example in 6536bis, appendix B.4)
>
>     With this new change, I think that you may need to configure many
>     more rules to achieve the same thing.  I think that you would need
>     to give read access to the top node in the desired path, and then
>     separate explicit "deny" rules for every sibling child node
>     walking from the top of the tree down to the data node that
>     read/write access is actually being given to.  The example below
>     may explain my understanding better:
>
>     read/write access only to "J" subtree, and no access for the rest
>     of the tree then:
>
>                      A
>                      |
>             --------------------
>             |      |     |     |
>             B      C     D     E
>             |
>        -----------
>        |   |  |  |
>        F   G  H  J
>                  |
>                 ...
>
>
>     In the new model, I think that the equivalent ACL rules would need
>     to be 8 rules long (assuming default deny all):
>        "read/write 'A/B/J'
>        "read A"
>        "deny C"
>        "deny D"
>        "deny E"
>        "deny F"
>        "deny G"
>        "deny H"
>
>     Note, I am assuming that a "path" rule matches for the given path
>     and all descendant nodes.  The draft doesn't seem to be
>     particularly clear on this point (it states that the rule applies
>     when the path matches, but this would seem to be counter
>     intuitive), and perhaps it could be clarified.
>
>     If this change is allowed, then the example in appendix B.4 looks
>     like it would need to be fixed, since the "limited-acl" probably
>     wouldn't give any access at all, unless default read access had
>     been given.
>
>     But, possibly I'm misunderstanding how this all works!  If so,
>     apologies for the noise :-)
>
>     Thanks,
>     Rob
>
>
>>     Here is a major change in draft-ietf-netconf-rfc6536bis,
>>     suggested by the Security AD Eric Rescola part of the IESG
>>     review, which I would like to validate with the WG. See
>>     <https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt>
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/netconf>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Nov 2017 20:37:48 -0800

Hi,

The term "data node" is used in the document to refer to the top-level node
of the specified object, not the entire subtree (if any).

The data-rule /foo does not match /foo/child1 in the text below.
The child nodes are omitted because of step 11.
The admin has to explicitly permit individual child nodes (or modules).
This seems correct if the read-default is "deny".

Should any text be added or changed to make this more clear?

Andy

On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <[email-masked]> wrote:

>   (ii) Applies to the specific node and all descendant children nodes as
> well.
>
> "A/B" then does that apply to only the specific node "A/B", or does it also
> apply to all descendant children of "A/B" as well?
>
>            type" is "data-node" and the *"path" matches the requested
>            data node*, action node, or notification node.
>
>
> My reading of this is that it implies that the interpretation of the path
> rule is (i), but this is not how I would normally expect an ACL rule to
> apply in a tree like object (e.g a directory file system).
>
>          <path xmlns:acme="http://example.com/ns/itf" <http://example.com/ns/itf>>
> Otherwise if the interpretation is (ii) then you only need "read /A" since
> that implies "read A/B" as well (as long as the rules are listed in the
> correct order).
>
>
> "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to
> define an Xpath expressions that contains all children nodes as well.
> Perhaps 'A/B/J//*'?
>
> If the interpretation of the rule is (ii) then you would also need all the
> explicit deny statements as well, otherwise they would be allowed by the
> "read /A" rule above.
>
> Thanks,
> Rob
>
>
>
>
> Andy
>
>
>> validate with the WG. See https://tools.ietf.org/rfcdiff
>> ?url2=draft-ietf-netconf-rfc6536bis-08.txt
>>
>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 10 Nov 2017 15:32:55 +0530

Mahesh Jethanandani 
[email-masked]
> On Nov 10, 2017, at 10:07 AM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

I would agree with Robert that it was not entirely clear that rule applied on the parent data-node does not apply to the child nodes. So yes, it would help to clarify it. 

Thanks 

>>   (ii) Applies to the specific node and all descendant children nodes as well. 
>> As an example, using the tree below.  if I have a rule that matches path "A/B" then does that apply to only the specific node "A/B", or does it also apply to all descendant children of "A/B" as well?
>> 
>> In rfc6536bis-08, section "3.4.5.  Data Node Access Validation", step 6 states:
>> 
>>            type" is "data-node" and the "path" matches the requested
>>            data node, action node, or notification node.
>> 
>> My reading of this is that it implies that the interpretation of the path rule is (i), but this is not how I would normally expect an ACL rule to apply in a tree like object (e.g a directory file system).
>> 
>> However, the examples in Appendix B.4. imply that the path rule is to be interpreted like (ii), or otherwise the example rules seem to be mostly pointless.
>> 
>> If the rule is (i)  then the access rule allows the client to read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']" but not any child leafs/containers of that interface, this doesn't seem useful.
>> 
>> Otherwise if the interpretation is (ii) then you only need "read /A" since that implies "read A/B" as well (as long as the rules are listed in the correct order).
>> 
>> 
>> Only if the interpretation of the rule is (i) above.  In which case the  "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to define an Xpath expressions that contains all children nodes as well.  Perhaps 'A/B/J//*'?
>> 
>> If the interpretation of the rule is (ii) then you would also need all the explicit deny statements as well, otherwise they would be allowed by the "read /A" rule above.
>> 
>> Thanks,
>> Rob
>> 
>> 
>>> 
>>> 
>>> Andy
>>> 
>>> 
>>>> I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the running datastore                     then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)
>>>> With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The example below may explain my understanding better:
>>>> E.g. For a tree of data nodes, rooted at A, if we wanted to give read/write access only to "J" subtree, and no access for the rest of the tree then:
>>>>                  A
>>>>                  |
>>>>         --------------------
>>>>         |      |     |     |
>>>>         B      C     D     E
>>>>         |
>>>>    -----------
>>>>    |   |  |  |
>>>>    F   G  H  J
>>>>              |
>>>>             ...
>>>> 
>>>> 
>>>> 
>>>> In the old model, I think that the ACL rules would be 1 rules long (assuming default deny all):
>>>>    "read/write 'A/B/J'
>>>> In the new model, I think that the equivalent ACL rules would need to be 8 rules long (assuming default deny all):
>>>>    "read/write 'A/B/J'
>>>>    "read A"
>>>>    "deny C"
>>>>    "deny D"
>>>>    "deny E"
>>>>    "deny F"
>>>>    "deny G"
>>>>    "deny H"
>>>> Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point                   (it states that the rule applies when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.
>>>> 
>>>> If this change is allowed, then the example in appendix B.4 looks like it would need to be fixed, since the "limited-acl" probably wouldn't give any access at all, unless default read access had been given.
>>>> 
>>>> But, possibly I'm misunderstanding how this all works!  If so, apologies for the noise :-)
>>>> 
>>>> Thanks,
>>>> Rob
>>>> 
>>>> 
>>>>> Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt
>>>>> 

Mahesh Jethanandani 
[email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Fri, 10 Nov 2017 10:42:39 +0000

On 10/11/2017 10:02, Mahesh Jethanandani wrote:
>
>
>
>
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> On Nov 10, 2017, at 10:07 AM, Andy Bierman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi,
>>
> I would agree with Robert that it was not entirely clear that rule 
> applied on the parent data-node does not apply to the child nodes. So 
> yes, it would help to clarify it.
We should be doing more than clarifying it.  We need to fix it so that 
it works in a sensible way.  I.e. to make the normative text consistent 
with the behaviour currently described in the examples in the appendix B.4.

If we follow Andy's interpretation that a data rule doesn't match child 
nodes then those examples are completely wrong.  E.g. the 4th rule is 
described as "This rule gives the 'admin' group read-write access to all 
acme <interface> entries."  But If the path only strictly matches 
"/acme:interfaces/acme:interface" then the admin group rule achieves 
nothing useful at all.  The admin is not even allowed to create an 
interface because they would not even have permission to write to the 
list key 'name' node required to create a list entry!  Instead, a 
separate rule would be required for every single possible schema node 
under "/acme:interfaces/acme:interface"!  I think that this makes 
"permit" data-node rules completely unusable.

To fix this properly, we need to make the data-node path rule a prefix 
match.  In particular, we need text that specifies:

(i) that a data-node path match succeeds if it matches the path prefix 
from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" 
and all of foo's descendant children nodes.

(ii) if a data-node rule has action "permit" then it implicitly allows 
read access for all ancestor parent nodes up to the root. (I.e. to 
mitigate the original change proposed on this thread.)

Thanks,
Rob

>
> Thanks
>
>>
>>
>> Andy
>>
>>
>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <[email-masked] 
>>     As an example, using the tree below.  if I have a rule that
>>     matches path "A/B" then does that apply to only the specific node
>>     "A/B", or does it also apply to all descendant children of "A/B"
>>     as well?
>>
>>     My reading of this is that it implies that the interpretation of
>>     the path rule is (i), but this is not how I would normally expect
>>     an ACL rule to apply in a tree like object (e.g a directory file
>>     system).
>>
>>     However, the examples in Appendix B.4. imply that the path rule
>>     is to be interpreted like (ii), or otherwise the example rules
>>     seem to be mostly pointless.
>>
>>     If the rule is (i)  then the access rule allows the client to
>>     read the specific node
>>     "/acme:interfaces/acme:interface[acme:name='dummy']" but not any
>>     child leafs/containers of that interface, this doesn't seem useful.
>>
>>     Otherwise if the interpretation is (ii) then you only need "read
>>     /A" since that implies "read A/B" as well (as long as the rules
>>     are listed in the correct order).
>>
>>
>>     Only if the interpretation of the rule is (i) above.  In which
>>     case the  "read/write 'A/B/J' rule would not be sufficient.  It
>>     would be necessary to define an Xpath expressions that contains
>>     all children nodes as well.  Perhaps 'A/B/J//*'?
>>
>>     If the interpretation of the rule is (ii) then you would also
>>     need all the explicit deny statements as well, otherwise they
>>     would be allowed by the "read /A" rule above.
>>
>>     Thanks,
>>     Rob
>>
>>
>>>
>>>
>>>     Andy
>>>
>>>
>>>         particular set of users read/write access to a subtree, but
>>>         not allow them to have any other access to the configuration
>>>         in the running datastore then with the existing RFC, that
>>>         could be expressed with a single rule (example in 6536bis,
>>>         appendix B.4)
>>>
>>>         With this new change, I think that you may need to configure
>>>         many more rules to achieve the same thing.  I think that you
>>>         would need to give read access to the top node in the
>>>         desired path, and then separate explicit "deny" rules for
>>>         every sibling child node walking from the top of the tree
>>>         down to the data node that read/write access is actually
>>>         E.g. For a tree of data nodes, rooted at A, if we wanted to
>>>         give read/write access only to "J" subtree, and no access
>>>         for the rest of the tree then:
>>>
>>>                          A
>>>                          |
>>>                 --------------------
>>>                 |      |     |     |
>>>                 B      C     D     E
>>>                 |
>>>            -----------
>>>            |   |  |  |
>>>            F   G  H  J
>>>                      |
>>>                     ...
>>>
>>>
>>>         In the new model, I think that the equivalent ACL rules
>>>         would need to be 8 rules long (assuming default deny all):
>>>            "read/write 'A/B/J'
>>>            "read A"
>>>            "deny C"
>>>            "deny D"
>>>            "deny E"
>>>            "deny F"
>>>            "deny G"
>>>            "deny H"
>>>
>>>         Note, I am assuming that a "path" rule matches for the given
>>>         path and all descendant nodes.  The draft doesn't seem to be
>>>         particularly clear on this point (it states that the rule
>>>         applies when the path matches, but this would seem to be
>>>         counter intuitive), and perhaps it could be clarified.
>>>
>>>         If this change is allowed, then the example in appendix B.4
>>>         looks like it would need to be fixed, since the
>>>         "limited-acl" probably wouldn't give any access at all,
>>>         unless default read access had been given.
>>>
> [email-masked] <mailto:[email-masked]>

---

From: Per Hedeland <[email-masked]>
Date: Fri, 10 Nov 2017 14:07:48 +0100

On 2017-11-10 11:42, Robert Wilton wrote:
>> On Nov 10, 2017, at 10:07 AM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> Hi,
>>>
> We should be doing more than clarifying it.  We need to fix it so that it works in a sensible way.  I.e. to make the normative text consistent with the behaviour currently described in the examples in
> the appendix B.4.
> 
> If we follow Andy's interpretation that a data rule doesn't match child nodes then those examples are completely wrong.  E.g. the 4th rule is described as "This rule gives the 'admin' group read-write
> access to all acme <interface> entries."  But If the path only strictly matches "/acme:interfaces/acme:interface" then the admin group rule achieves nothing useful at all.  The admin is not even
> allowed to create an interface because they would not even have permission to write to the list key 'name' node required to create a list entry!  Instead, a separate rule would be required for every
> single possible schema node under "/acme:interfaces/acme:interface"!  I think that this makes "permit" data-node rules completely unusable.

I strongly agree with this, and I would say that it isn't only the case
for "permit" rules - e.g. denying some access to a subtree of the data
model that would otherwise be permitted due to defaults is at least as
common, and the rules would be just as unusable for that.

Besides the examples, I think that the very use of the term "match",
though unfortunately not defined, strongly suggests that it is something
other than use of e.g. the term "identify" would imply. Additionally,
this text in the description of the 'path' leaf is consistent with the
match being a prefix match:

       The special value '/' refers to all possible
       datastore contents.";

FWIW, our NACM implementation, available to (and used by) customers
since 2012, follows the prefix match logic, and I have yet to hear of
any user expecting it to do otherwise.

> To fix this properly, we need to make the data-node path rule a prefix match.  In particular, we need text that specifies:
> 
> (i) that a data-node path match succeeds if it matches the path prefix from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and all of foo's descendant children nodes.

Strongly agree.

> (ii) if a data-node rule has action "permit" then it implicitly allows read access for all ancestor parent nodes up to the root.  (I.e. to mitigate the original change proposed on this thread.)

This seems reasonable to me, although I haven't at this point evaluated
the suggestion in detail. In any case I think the main point both
regarding this and the prefix match is that this update to 6536 can't
make radical changes to the semantics compared to a "reasonable
interpretation" (hard to define, I know) of the under-specified
original.

--Per

> Thanks,
> Rob
> 
> 
>>
>> Thanks 
>>
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     Hi Andy,
>>>
>>>                type" is "data-node" and the *"path" matches the requested data node*, action node, or notification node.
>>>
>>>
>>>     Only if the interpretation of the rule is (i) above.  In which case the  "read/write 'A/B/J' rule would not be sufficient.  It would be necessary to define an Xpath expressions that contains
>>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         I'm not that familiar with NACM, but if you want to give a particular set of users read/write access to a subtree, but not allow them to have any other access to the configuration in the
>>>>         running datastore then with the existing RFC, that could be expressed with a single rule (example in 6536bis, appendix B.4)
>>>>
>>>>         With this new change, I think that you may need to configure many more rules to achieve the same thing.  I think that you would need to give read access to the top node in the desired
>>>>         path, and then separate explicit "deny" rules for every sibling child node walking from the top of the tree down to the data node that read/write access is actually being given to.  The
>>>>         example below may explain my understanding better:
>>>>
>>>>         Note, I am assuming that a "path" rule matches for the given path and all descendant nodes.  The draft doesn't seem to be particularly clear on this point (it states that the rule applies
>>>>         when the path matches, but this would seem to be counter intuitive), and perhaps it could be clarified.
>>>>
>>>>>         Here is a major change in draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric Rescola part of the IESG review, which I would like to validate with the WG. See
>>>>>         https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt>
>>>>>
>>>>>         https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>>>>
>>>>
>>>
>>>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Nov 2017 07:49:10 -0800

On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <[email-masked]> wrote:

> applied on the parent data-node does not apply to the child nodes. So yes,
> it would help to clarify it.
> described as "This rule gives the 'admin' group read-write
> > access to all acme <interface> entries."  But If the path only strictly
> matches "/acme:interfaces/acme:interface" then the admin group rule
> achieves nothing useful at all.  The admin is not even
> > allowed to create an interface because they would not even have
> permission to write to the list key 'name' node required to create a list
> entry!  Instead, a separate rule would be required for every
> > single possible schema node under "/acme:interfaces/acme:interface"!  I
> think that this makes "permit" data-node rules completely unusable.
>
> from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" and
> all of foo's descendant children nodes.
>
> Strongly agree.
>
>

I do not see how the text can be interpreted this way.
There is nothing that says this is how it works.
If it did, once could never have privileged sub-fiolders

     /var/log -> permit
     /var/log/apache2  -> deny

> interpretation" (hard to define, I know) of the under-specified

The text does not say this at all so I do not approve of this change

Andy

> matches path "A/B" then does that apply to only the specific node "A/B", or
> does it also apply to all descendant children of "A/B" as
> >>>     well?
> >>>
> >>>                type" is "data-node" and the *"path" matches the
> requested data node*, action node, or notification node.
> >>>
> >>>
> the path rule is (i), but this is not how I would normally expect an ACL
> >>>     However, the examples in Appendix B.4. imply that the path rule is
> to be interpreted like (ii), or otherwise the example rules seem to be
> mostly pointless.
> >>>
> >>>     If the rule is (i)  then the access rule allows the client to read
> the specific node "/acme:interfaces/acme:interface[acme:name='dummy']"
> but not any child leafs/containers of that interface,
> >>>     this doesn't seem useful.
> >>>
> /A" since that implies "read A/B" as well (as long as the rules are listed
> in the correct order).
> >>>
> >>>
> case the  "read/write 'A/B/J' rule would not be sufficient.  It would be
> necessary to define an Xpath expressions that contains
> >>>     If the interpretation of the rule is (ii) then you would also need
> all the explicit deny statements as well, otherwise they would be allowed
> by the "read /A" rule above.
> >>>
> >>>     Thanks,
> >>>     Rob
> >>>
> >>>
> >>>>
> >>>>
> >>>>     Andy
> >>>>
> >>>>
> particular set of users read/write access to a subtree, but not allow them
> to have any other access to the configuration in the
> many more rules to achieve the same thing.  I think that you would need to
> give read access to the top node in the desired
> >>>>         path, and then separate explicit "deny" rules for every
> sibling child node walking from the top of the tree down to the data node
> that read/write access is actually being given to.  The
> give read/write access only to "J" subtree, and no access for the rest of
> the tree then:
> >>>>
> >>>>                          A
> >>>>                          |
> >>>>                 --------------------
> >>>>                 |      |     |     |
> >>>>                 B      C     D     E
> >>>>                 |
> >>>>            -----------
> >>>>            |   |  |  |
> >>>>            F   G  H  J
> >>>>                      |
> >>>>                     ...
> >>>>
> >>>>
> >>>>         In the new model, I think that the equivalent ACL rules would
> need to be 8 rules long (assuming default deny all):
> >>>>            "read/write 'A/B/J'
> >>>>            "read A"
> >>>>            "deny C"
> >>>>            "deny D"
> >>>>            "deny E"
> >>>>            "deny F"
> >>>>            "deny G"
> >>>>            "deny H"
> >>>>
> path and all descendant nodes.  The draft doesn't seem to be particularly
> clear on this point (it states that the rule applies
> looks like it would need to be fixed, since the "limited-acl" probably
> wouldn't give any access at all, unless default read
> >>>>         access had been given.
> >>>>
> suggested by the Security AD Eric Rescola part of the IESG review, which I
> would like to validate with the WG. See
> >>>>>         https://tools.ietf.org/rfcdiff?url2=draft-ietf-
> netconf-rfc6536bis-08.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-
> netconf-rfc6536bis-08.txt>
> >>>>>
> >>>>>         https://www.ietf.org/mailman/listinfo/netconf <
> https://www.ietf.org/mailman/listinfo/netconf>
> >>>>
> >>>>
> >>>
> >>>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 10 Nov 2017 16:16:29 +0000

On 10/11/2017 15:49, Andy Bierman wrote:
>
>
> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >>
>     >>> Hi,
>     >>>
>     >> I would agree with Robert that it was not entirely clear that
>     rule applied on the parent data-node does not apply to the child
>     nodes. So yes, it would help to clarify it.
>     > We should be doing more than clarifying it.  We need to fix it
>     so that it works in a sensible way.  I.e. to make the normative
>     text consistent with the behaviour currently described in the
>     examples in
>     > the appendix B.4.
>     >
>     > If we follow Andy's interpretation that a data rule doesn't
>     match child nodes then those examples are completely wrong.  E.g.
>     the 4th rule is described as "This rule gives the 'admin' group
>     read-write
>     > access to all acme <interface> entries."  But If the path only
>     strictly matches "/acme:interfaces/acme:interface" then the admin
>     group rule achieves nothing useful at all. The admin is not even
>     permission to write to the list key 'name' node required to create
>     a list entry!  Instead, a separate rule would be required for every
>     > single possible schema node under
>     "/acme:interfaces/acme:interface"!  I think that this makes
>     > To fix this properly, we need to make the data-node path rule a
>     prefix match.  In particular, we need text that specifies:
>     >
>     > (i) that a data-node path match succeeds if it matches the path
>     prefix from the root of the tree.  I.e. so the data-rule "/foo"
>     matches "/foo" and all of foo's descendant children nodes.
>
>     Strongly agree.
>
>
>

Because otherwise the path match part of the NACM solution is really 
broken, and the path based examples in the appendix are entirely 
misleading and wrong.  The only way those examples make sense is the 
paths match descendant children nodes as well.

> If it did, once could never have privileged sub-fiolders

Yes, you can, you just list the longest path first in the list of rules:

  (1)  /var/log/apache2  -> deny
   (2) /var/log -> permit

Any requests that attempt to access anything under /var/log/apache2 
would match rule (1) and be denied.
Any requests that attempt to access anything under /var/log, but not 
under /var/log/apache2, would fail to match rule (1), but would match 
rule (2) instead and be permitted.

>
>
>     > (ii) if a data-node rule has action "permit" then it implicitly
>     allows read access for all ancestor parent nodes up to the root. 
>     (I.e. to mitigate the original change proposed on this thread.)
>

In the RFC version of the NACM this wasn't required because operation 
'none' didn't require read access.  Now read access is required even for 
operation 'none', then this change makes sense to make the NACM changes 
backwards compatible, whilst still closing the security hole.

Thanks,
Rob

>
>
>     --Per
>
>
>
> Andy
>
>     > Thanks,
>     > Rob
>     >
>     >
>     >>
>     >> Thanks
>     >>
>     >>>
>     >>>
>     >>> Andy
>     >>>
>     >>>
>     >>> On Thu, Nov 9, 2017 at 2:44 AM, Robert Wilton
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>>
>     >>>     Hi Andy,
>     >>>
>     >>>     As an example, using the tree below.  if I have a rule
>     that matches path "A/B" then does that apply to only the specific
>     node "A/B", or does it also apply to all descendant children of
>     "A/B" as
>     >>>     well?
>     >>>
>     >>>                type" is "data-node" and the *"path" matches
>     the requested data node*, action node, or notification node.
>     >>>
>     >>>
>     >>>     My reading of this is that it implies that the
>     interpretation of the path rule is (i), but this is not how I
>     would normally expect an ACL rule to apply in a tree like object
>     (e.g a directory
>     >>>     file system).
>     >>>
>     >>>     However, the examples in Appendix B.4. imply that the path
>     rule is to be interpreted like (ii), or otherwise the example
>     rules seem to be mostly pointless.
>     >>>
>     >>>              <path xmlns:acme="http://example.com/ns/itf
>     <http://example.com/ns/itf>" <http://example.com/ns/itf>>
>     >>>     If the rule is (i)  then the access rule allows the client
>     to read the specific node
>     >>>     Otherwise if the interpretation is (ii) then you only need
>     "read /A" since that implies "read A/B" as well (as long as the
>     rules are listed in the correct order).
>     >>>
>     >>>
>     >>>     Only if the interpretation of the rule is (i) above.  In
>     which case the  "read/write 'A/B/J' rule would not be sufficient. 
>     It would be necessary to define an Xpath expressions that contains
>     >>>     If the interpretation of the rule is (ii) then you would
>     also need all the explicit deny statements as well, otherwise they
>     >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>>>
>     >>>>         Hi,
>     >>>>
>     >>>>         I'm not that familiar with NACM, but if you want to
>     give a particular set of users read/write access to a subtree, but
>     not allow them to have any other access to the configuration in the
>     >>>>         running datastore then with the existing RFC, that
>     >>>>         With this new change, I think that you may need to
>     configure many more rules to achieve the same thing.  I think that
>     you would need to give read access to the top node in the desired
>     >>>>         path, and then separate explicit "deny" rules for
>     every sibling child node walking from the top of the tree down to
>     the data node that read/write access is actually being given to.  The
>     >>>>         E.g. For a tree of data nodes, rooted at A, if we
>     wanted to give read/write access only to "J" subtree, and no
>     access for the rest of the tree then:
>     >>>>
>     >>>>                          A
>     >>>>                          |
>     >>>>                 --------------------
>     >>>>                 |      |     |     |
>     >>>>                 B      C     D     E
>     >>>>                 |
>     >>>>            -----------
>     >>>>            |   |  |  |
>     >>>>            F   G  H  J
>     >>>>                      |
>     >>>>                     ...
>     >>>>
>     >>>>
>     >>>>         In the old model, I think that the ACL rules would be
>     1 rules long (assuming default deny all):
>     >>>>            "read/write 'A/B/J'
>     >>>>
>     >>>>         In the new model, I think that the equivalent ACL
>     rules would need to be 8 rules long (assuming default deny all):
>     >>>>            "read/write 'A/B/J'
>     >>>>            "read A"
>     >>>>            "deny C"
>     >>>>            "deny D"
>     >>>>            "deny E"
>     >>>>            "deny F"
>     >>>>            "deny G"
>     >>>>            "deny H"
>     >>>>
>     >>>>         Note, I am assuming that a "path" rule matches for
>     the given path and all descendant nodes. The draft doesn't seem to
>     be particularly clear on this point (it states that the rule applies
>     >>>>         when the path matches, but this would seem to be
>     >>>>         If this change is allowed, then the example in
>     appendix B.4 looks like it would need to be fixed, since the
>     "limited-acl" probably wouldn't give any access at all, unless
>     default read
>     >>>>         access had been given.
>     >>>>
>     >>>>         But, possibly I'm misunderstanding how this all
>     works!  If so, apologies for the noise :-)
>     >>>>
>     >>>>         Thanks,
>     >>>>         Rob
>     >>>>
>     >>>>
>     >>>>>         Here is a major change in
>     draft-ietf-netconf-rfc6536bis, suggested by the Security AD Eric
>     Rescola part of the IESG review, which I would like to validate
>     with the WG. See
>     >>>>>
>     <https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt
>     <https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-08.txt>>
>     >>>>>
>     >>>>>         
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <https://www.ietf.org/mailman/listinfo/netconf
>     <https://www.ietf.org/mailman/listinfo/netconf>>
>     >>>>
>     >>>>
>     >>>
>     >>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >
>     >
>     >

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Nov 2017 08:33:31 -0800

On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton <[email-masked]> wrote:

>> > single possible schema node under "/acme:interfaces/acme:interface"!
>> I think that this makes "permit" data-node rules completely unusable.
>>
> broken, and the path based examples in the appendix are entirely misleading
> and wrong.  The only way those examples make sense is the paths match
> descendant children nodes as well.
>
>

IMO the text does not support this interpretation.
There is nothing said about inheriting state from the parent data node.
I think no matter how the permissions are derived, one can
find examples that work better or worse because of it.
IMO the number of rules required to implement a use-case is not
very relevant or objective criteria.

Using the previous example of /home and /home/user1,
if the user1 is given read access to /home, then (according to you)
it also has read access to every user subtree under /home.
Instead of 1 rule per user, 2 rules are needed

   read-default=deny
   group=*, path=/home, action=permit
   group=user1, path=/home/user1, action=permit

The above rules would allow access for every user to every other user.
The 2nd rule has no effect, which is counter-intuitive.
Every user dir would need 2 rules

   read-default=deny
   group=*, path=/home, action=permit
   group=user1, path=/home/user1, action=permit
   group=*, path=/home/user1, action=deny

> Any requests that attempt to access anything under /var/log/apache2 would
> match rule (1) and be denied.
> Any requests that attempt to access anything under /var/log, but not under
> /var/log/apache2, would fail to match rule (1), but would match rule (2)
> instead and be permitted.
>
>
>
I do not see any text in the draft or RFC 7950 that
suggests that /var/log and /var/log/apache2 represent the same data node.

Andy

>> is to be interpreted like (ii), or otherwise the example rules seem to be
>> mostly pointless.
>> >>>
>> read the specific node "/acme:interfaces/acme:interface[acme:name='dummy']"
>> need all the explicit deny statements as well, otherwise they would be
>> allowed by the "read /A" rule above.
>> >>>
>> >>>     Thanks,
>> >>>     Rob
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>>     Andy
>> >>>>
>> >>>>
>> >>>>>         https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-
>> rfc6536bis-08.txt <https://tools.ietf.org/rfcdif
>> f?url2=draft-ietf-netconf-rfc6536bis-08.txt>
>> >>>>>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 10 Nov 2017 17:24:04 +0000

On 10/11/2017 16:33, Andy Bierman wrote:
>
>
> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton <[email-masked] 
>>         >> On Nov 10, 2017, at 10:07 AM, Andy Bierman
>>         <[email-masked] <mailto:[email-masked]>
>>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>         >>
>>         >>> Hi,
>>         >>>
>>         >> I would agree with Robert that it was not entirely clear
>>         that rule applied on the parent data-node does not apply to
>>         the child nodes. So yes, it would help to clarify it.
>>         > We should be doing more than clarifying it.  We need to fix
>>         it so that it works in a sensible way.  I.e. to make the
>>         normative text consistent with the behaviour currently
>>         described in the examples in
>>         > the appendix B.4.
>>         >
>>         match child nodes then those examples are completely wrong. 
>>         E.g. the 4th rule is described as "This rule gives the
>>         'admin' group read-write
>>         > access to all acme <interface> entries."  But If the path
>>         only strictly matches "/acme:interfaces/acme:interface" then
>>         the admin group rule achieves nothing useful at all.  The
>>         admin is not even
>>         > allowed to create an interface because they would not even
>>         have permission to write to the list key 'name' node required
>>         to create a list entry!  Instead, a separate rule would be
>>         required for every
>>         > To fix this properly, we need to make the data-node path
>>         rule a prefix match.  In particular, we need text that specifies:
>>         >
>>         > (i) that a data-node path match succeeds if it matches the
>>         path prefix from the root of the tree.  I.e. so the data-rule
>>         "/foo" matches "/foo" and all of foo's descendant children nodes.
>>
>>         Strongly agree.
>>
>>
>>
>     Because otherwise the path match part of the NACM solution is
>     really broken, and the path based examples in the appendix are
>     entirely misleading and wrong.  The only way those examples make
>     sense is the paths match descendant children nodes as well.
>
>
>
The examples in B.4, and the definition of "/" matching all nodes 
supports this interpretation.

Hence, my opinion is that it is the text in 3.4.5 that is incorrectly 
specified; and that the examples, definition of "/" and standard 
practice are right.

Otherwise, how did IETF manage to publish an RFC where the path based 
examples are so completely wrong?   Whoever wrote and reviewed those 
examples clearly had a different interpretation of how these path based 
ACLs worked.

> find examples that work better or worse because of it.
No.  If the rules apply to descendant children, all normal examples work 
well (including the ones in the appendix).

> very relevant or objective criteria.
Yes it is, particularly when the difference is between needing a 1 line 
rule, and a 100+ line rule.

> Instead of 1 rule per user, 2 rules are needed
No, just 1 rule per user:
    read-default=deny
    group=user1, path=/home/user1, action=permit

This is because of my two proposed changes:

(i) that a data-node path match succeeds if it matches the path prefix 
from the root of the tree.  I.e. so the data-rule "/foo" matches "/foo" 
and all of foo's descendant children nodes.
<- This means that you only need 1 entry instead of 100 entries.

(ii) if a data-node rule has action "permit" then it implicitly allows 
read access for all ancestor parent nodes up to the root. (I.e. to 
mitigate the original change proposed on this thread.)
<- This means that you don't need a separate read rule for "/home".  
Read access to that node it is implicitly given via "group=user1, 
path=/home/user1, action=permit", hence meaning that the rule works the 
same way as it does on an rfc6536 compliant implementation.

>     Any requests that attempt to access anything under
>     /var/log/apache2 would match rule (1) and be denied.
>     Any requests that attempt to access anything under /var/log, but
>     not under /var/log/apache2, would fail to match rule (1), but
>     would match rule (2) instead and be permitted.
>
>
>
They are different data nodes, but I don't see how that is relevant.

Thanks,
Rob

>
>
> Andy
>
>>
>>
>>         > (ii) if a data-node rule has action "permit" then it
>>         implicitly allows read access for all ancestor parent nodes
>>         up to the root.  (I.e. to mitigate the original change
>>         proposed on this thread.)
>>
>     In the RFC version of the NACM this wasn't required because
>     operation 'none' didn't require read access. Now read access is
>     required even for operation 'none', then this change makes sense
>     to make the NACM changes backwards compatible, whilst still
>     closing the security hole.
>
>     Thanks,
>     Rob
>
>>
>>
>>         --Per
>>
>>
>>
>>     Andy
>>
>>         > Thanks,
>>         > Rob
>>         >
>>         >
>>         >>
>>         >> Thanks
>>         >>
>>         >>>
>>         >>>
>>         >>> Andy
>>         >>>
>>         >>>
>>         >>>     As an example, using the tree below.  if I have a
>>         rule that matches path "A/B" then does that apply to only the
>>         specific node "A/B", or does it also apply to all descendant
>>         children of "A/B" as
>>         >>>     well?
>>         >>>
>>         >>>                type" is "data-node" and the *"path"
>>         matches the requested data node*, action node, or
>>         notification node.
>>         >>>
>>         >>>
>>         would normally expect an ACL rule to apply in a tree like
>>         object (e.g a directory
>>         >>>     file system).
>>         >>>
>>         >>>     However, the examples in Appendix B.4. imply that the
>>         path rule is to be interpreted like (ii), or otherwise the
>>         example rules seem to be mostly pointless.
>>         >>>
>>         >>>     If the rule is (i)  then the access rule allows the
>>         client to read the specific node
>>         "/acme:interfaces/acme:interface[acme:name='dummy']" but not
>>         any child leafs/containers of that interface,
>>         >>>     Otherwise if the interpretation is (ii) then you only
>>         need "read /A" since that implies "read A/B" as well (as long
>>         as the rules are listed in the correct order).
>>         >>>
>>         >>>
>>         >>>     Only if the interpretation of the rule is (i) above. 
>>         In which case the "read/write 'A/B/J' rule would not be
>>         sufficient.  It would be necessary to define an Xpath
>>         expressions that contains
>>         >>>     If the interpretation of the rule is (ii) then you
>>         would also need all the explicit deny statements as well,
>>         otherwise they would be allowed by the "read /A" rule above.
>>         >>>
>>         >>>     Thanks,
>>         >>>     Rob
>>         >>>
>>         >>>
>>         >>>>
>>         >>>>
>>         >>>>     Andy
>>         >>>>
>>         >>>>
>>         >>>>         I'm not that familiar with NACM, but if you want
>>         to give a particular set of users read/write access to a
>>         subtree, but not allow them to have any other access to the
>>         configuration in the
>>         >>>>         running datastore then with the existing RFC,
>>         that could be expressed with a single rule (example in
>>         6536bis, appendix B.4)
>>         >>>>
>>         >>>>         With this new change, I think that you may need
>>         to configure many more rules to achieve the same thing.  I
>>         think that you would need to give read access to the top node
>>         in the desired
>>         >>>>         path, and then separate explicit "deny" rules
>>         for every sibling child node walking from the top of the tree
>>         being given to.  The
>>         >>>>         E.g. For a tree of data nodes, rooted at A, if
>>         we wanted to give read/write access only to "J" subtree, and
>>         no access for the rest of the tree then:
>>         >>>>
>>         >>>>                          A
>>         >>>>                          |
>>         >>>>  --------------------
>>         >>>>                 |      |  |     |
>>         >>>>                 B      C  D     E
>>         >>>>                 |
>>         >>>>            -----------
>>         >>>>            |   |  |  |
>>         >>>>            F   G  H  J
>>         >>>>                      |
>>         >>>>                     ...
>>         >>>>
>>         >>>>
>>         >>>>         In the old model, I think that the ACL rules
>>         would be 1 rules long (assuming default deny all):
>>         >>>>            "read/write 'A/B/J'
>>         >>>>
>>         >>>>         In the new model, I think that the equivalent
>>         ACL rules would need to be 8 rules long (assuming default
>>         deny all):
>>         >>>>            "read/write 'A/B/J'
>>         >>>>            "read A"
>>         >>>>            "deny C"
>>         >>>>            "deny D"
>>         >>>>            "deny E"
>>         >>>>            "deny F"
>>         >>>>            "deny G"
>>         >>>>            "deny H"
>>         >>>>
>>         >>>>         Note, I am assuming that a "path" rule matches
>>         for the given path and all descendant nodes.  The draft
>>         doesn't seem to be particularly clear on this point (it
>>         states that the rule applies
>>         draft-ietf-netconf-rfc6536bis, suggested by the Security AD
>>         Eric Rescola part of the IESG review, which I would like to
>>         validate with the WG. See
>>         >>>>>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Nov 2017 09:45:17 -0800

On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton <[email-masked]> wrote:

>>> > If we follow Andy's interpretation that a data rule doesn't match
>>> child nodes then those examples are completely wrong.  E.g. the 4th rule is
>>> strictly matches "/acme:interfaces/acme:interface" then the admin group
>>> rule achieves nothing useful at all.  The admin is not even
> The examples in B.4, and the definition of "/" matching all nodes supports
> this interpretation.
>
> specified; and that the examples, definition of "/" and standard practice
> are right.
>

Only the examples for "update" support this interpretation since
the read-default=permit and write-default=deny in the example

> rule, and a 100+ line rule.

Depending on how the defaults are set.
If they are set to "permit" then only "deny" rules need to be added since
access procedures do not proceed to a child node after a deny outcome is
reached.

> <- This means that you only need 1 entry instead of 100 entries.

I will define a data-rule to apply to a data node if it is a descendant or
the node itself
if this is what the WG wants

(ii) if a data-node rule has action "permit" then it implicitly allows read
> access for all ancestor parent nodes up to the root.  (I.e. to mitigate the
> original change proposed on this thread.)
> <- This means that you don't need a separate read rule for "/home".  Read
> access to that node it is implicitly given via "group=user1,

I do not agree at all that the definition of data node /home/foo includes
its ancestors
and this is brand new behavior that is not shown in the document at all.

>> under /var/log/apache2, would fail to match rule (1), but would match rule
>> (2) instead and be permitted.
>>
>>
>>

The NACM procedures refer to "the data node", not "the data node or its
descendants",

Andy

>>> >>>>     On Wed, Nov 8, 2017 at 8:33 AM, Robert Wilton <
>>> [email-masked] <mailto:[email-masked]>> wrote:
>>> >>>>
>>> >>>>         Hi,
>>> >>>>
>>> configure many more rules to achieve the same thing.  I think that you
>>> would need to give read access to the top node in the desired
>>> >>>>         Note, I am assuming that a "path" rule matches for the
>>> given path and all descendant nodes.  The draft doesn't seem to be
>>> >>>>>         https://tools.ietf.org/rfcdif
>>> f?url2=draft-ietf-netconf-rfc6536bis-08.txt <

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Nov 2017 10:23:05 -0800

Hi,

Here are some proposed edits to make the data rule consistent with the
examples.
Note that this issue is not related to the edit in the original 1-week
change.

sec. 3.3.5:

OLD:

      data node rule:  controls access for a specific data node, identified
      by its path location within the conceptual XML document for the
      data node.

NEW:

      data node rule:  controls access for a specific data node and its
descendants,
      identified by its path location within the conceptual XML document
for the
      data node.

sec 3.4.5, step 6, bullet 2:

OLD:

NEW:

        *  The rule does not have a "rule-type" defined or the "rule-
           type" is "data-node" and the "path" matches the requested
           data node, action node, or notification node. A path is
           considered to match if the current data node is the data node
           specified by the path, or is a descendant data node of this
data node.

appendix B.4: (2 bugs in explanation)

OLD:

      deny-nacm:  This rule denies the "guest" group any access to the
      <nacm> subtree.  Note that the default namespace is only
      applicable because this subtree is defined in the same namespace
      as the <data-rule> element.

 NEW:

      deny-nacm:  This rule denies the "guest" group any access to the
      <nacm> subtree.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Fri, 10 Nov 2017 18:42:14 +0000

On 10/11/2017 17:45, Andy Bierman wrote:
>
>
> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton <[email-masked] 
>>>         On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             <mailto:[email-masked]>
>>>             >> I would agree with Robert that it was not entirely
>>>             clear that rule applied on the parent data-node does not
>>>             apply to the child nodes. So yes, it would help to
>>>             clarify it.
>>>             > We should be doing more than clarifying it.  We need
>>>             to fix it so that it works in a sensible way.  I.e. to
>>>             make the normative text consistent with the behaviour
>>>             currently described in the examples in
>>>             > the appendix B.4.
>>>             >
>>>             > If we follow Andy's interpretation that a data rule
>>>             doesn't match child nodes then those examples are
>>>             completely wrong.  E.g. the 4th rule is described as
>>>             "This rule gives the 'admin' group read-write
>>>             > access to all acme <interface> entries."  But If the
>>>             path only strictly matches
>>>             "/acme:interfaces/acme:interface" then the admin group
>>>             > allowed to create an interface because they would not
>>>             even have permission to write to the list key 'name'
>>>             node required to create a list entry!  Instead, a
>>>             separate rule would be required for every
>>>             "/acme:interfaces/acme:interface"! I think that this
>>>             makes "permit" data-node rules completely unusable.
>>>
>>>             > To fix this properly, we need to make the data-node
>>>             path rule a prefix match.  In particular, we need text
>>>             that specifies:
>>>             >
>>>             > (i) that a data-node path match succeeds if it matches
>>>             the path prefix from the root of the tree.  I.e. so the
>>>             data-rule "/foo" matches "/foo" and all of foo's
>>>             descendant children nodes.
>>>
>>>             Strongly agree.
>>>
>>>
>>>
>>         really broken, and the path based examples in the appendix
>>         are entirely misleading and wrong.  The only way those
>>         examples make sense is the paths match descendant children
>>         nodes as well.
>>
>>
>>
>     Hence, my opinion is that it is the text in 3.4.5 that is
>     incorrectly specified; and that the examples, definition of "/"
>     and standard practice are right.
>
>     Otherwise, how did IETF manage to publish an RFC where the path
>     based examples are so completely wrong? Whoever wrote and reviewed
>     those examples clearly had a different interpretation of how these
>     path based ACLs worked.
>
>
>
> the read-default=permit and write-default=deny in the example.

Well, no.  Not with your interpretation that a path rule only applies to 
the specific node and not it's descendant children.

A client would be allowed to write to any children nodes below the node 
with a path deny rule (if the deny node already exists).  They can do 
this as long as they have read permissions (or with RFC 6536 they don't 
need any access rules at all).

E.g.  read-default=permit.
   path rule: "/interfaces/"  - write - deny

Then a client can delete "/interfaces/interface[name=eth0]/mtu" by 
setting the default operation to "none", and "remove" on the mtu leaf.

Similarly, the "nacm:default-deny-all;" rule will also be broken. It 
will only prevent users from modifying the "nacm" container, then would 
have full access to anything below that!

>     No.  If the rules apply to descendant children, all normal
>     examples work well (including the ones in the appendix).
>
>
>
>
>
>     Yes it is, particularly when the difference is between needing a 1
>     line rule, and a 100+ line rule.
>
>
>
> access procedures do not proceed to a child node after a deny outcome 
> is reached.

I think that NACM is completely broken if the rules only apply to the 
specific datanode and not their descendants.

> I will define a data-rule to apply to a data node if it is a 
> descendant or the node itself

I don't think that any extra data-rule is required.  I think that we 
just need to fix the one that we have.

>     <- This means that you don't need a separate read rule for
>     "/home".  Read access to that node it is implicitly given via
>     "group=user1, path=/home/user1, action=permit", hence meaning that
>     the rule works the same way as it does on an rfc6536 compliant
>     implementation.
>
>>
>
>
> I do not agree at all that the definition of data node /home/foo 
> includes its ancestors

This is proposed new behavior to mitigate the change from "none" 
requiring no access to "none" requiring read access.

>>         Any requests that attempt to access anything under /var/log,
>>         but not under /var/log/apache2, would fail to match rule (1),
>>         but would match rule (2) instead and be permitted.
>>
>>
>>
> The NACM procedures refer to "the data node", not "the data node or 
> its descendants",
But logically each data node that is accessed is checked, so implicitly 
the descendants will already be checked.

Thanks,
Rob

>>>             implicitly allows read access for all ancestor parent
>>>             nodes up to the root.  (I.e. to mitigate the original
>>>             change proposed on this thread.)
>>>
>>         operation 'none' didn't require read access.  Now read access
>>         is required even for operation 'none', then this change makes
>>         sense to make the NACM changes backwards compatible, whilst
>>         still closing the security hole.
>>
>>         Thanks,
>>         Rob
>>
>>>
>>>
>>>             --Per
>>>
>>>
>>>
>>>         Andy
>>>
>>>             > Thanks,
>>>             > Rob
>>>             >
>>>             >
>>>             >>
>>>             >> Thanks
>>>             >>
>>>             >>>
>>>             >>>
>>>             >>> Andy
>>>             >>>
>>>             >>>
>>>             >>>     As an example, using the tree below.  if I have
>>>             a rule that matches path "A/B" then does that apply to
>>>             only the specific node "A/B", or does it also apply to
>>>             all descendant children of "A/B" as
>>>             >>>     well?
>>>             >>>
>>>             interpretation of the path rule is (i), but this is not
>>>             how I would normally expect an ACL rule to apply in a
>>>             tree like object (e.g a directory
>>>             >>>     file system).
>>>             >>>
>>>             >>>     However, the examples in Appendix B.4. imply
>>>             that the path rule is to be interpreted like (ii), or
>>>             otherwise the example rules seem to be mostly pointless.
>>>             >>>
>>>             >>>     If the rule is (i)  then the access rule allows
>>>             the client to read the specific node
>>>             "/acme:interfaces/acme:interface[acme:name='dummy']" but
>>>             >>>     Otherwise if the interpretation is (ii) then you
>>>             only need "read /A" since that implies "read A/B" as
>>>             well (as long as the rules are listed in the correct order).
>>>             >>>
>>>             >>>
>>>             >>>     Only if the interpretation of the rule is (i)
>>>             above.  In which case the "read/write 'A/B/J' rule would
>>>             not be sufficient.  It would be necessary to define an
>>>             Xpath expressions that contains
>>>             >>>     If the interpretation of the rule is (ii) then
>>>             you would also need all the explicit deny statements as
>>>             well, otherwise they would be allowed by the "read /A"
>>>             rule above.
>>>             >>>
>>>             >>>     Thanks,
>>>             >>>     Rob
>>>             >>>
>>>             >>>
>>>             >>>>
>>>             >>>>
>>>             >>>>     Andy
>>>             >>>>
>>>             >>>>
>>>             >>>>         I'm not that familiar with NACM, but if you
>>>             want to give a particular set of users read/write access
>>>             to a subtree, but not allow them to have any other
>>>             access to the configuration in the
>>>             >>>>         running datastore then with the existing
>>>             RFC, that could be expressed with a single rule (example
>>>             in 6536bis, appendix B.4)
>>>             >>>>
>>>             >>>>         With this new change, I think that you may
>>>             need to configure many more rules to achieve the same
>>>             thing.  I think that you would need to give read access
>>>             to the top node in the desired
>>>             >>>>         path, and then separate explicit "deny"
>>>             rules for every sibling child node walking from the top
>>>             of the tree down to the data node that read/write access
>>>             is actually being given to.  The
>>>             >>>>         E.g. For a tree of data nodes, rooted at A,
>>>             if we wanted to give read/write access only to "J"
>>>             subtree, and no access for the rest of the tree then:
>>>             >>>>
>>>             >>>>         A
>>>             >>>>         |
>>>             >>>>  --------------------
>>>             >>>>  |      |     |     |
>>>             >>>>  B      C     D     E
>>>             >>>>                 |
>>>             >>>> -----------
>>>             >>>>            |   | |  |
>>>             >>>>            F   G H  J
>>>             >>>>     |
>>>             >>>>    ...
>>>             >>>>
>>>             >>>>
>>>             >>>>         In the old model, I think that the ACL
>>>             rules would be 1 rules long (assuming default deny all):
>>>             >>>> "read/write 'A/B/J'
>>>             >>>>
>>>             >>>>         In the new model, I think that the
>>>             equivalent ACL rules would need to be 8 rules long
>>>             >>>>         Note, I am assuming that a "path" rule
>>>             matches for the given path and all descendant nodes. 
>>>             The draft doesn't seem to be particularly clear on this
>>>             point (it states that the rule applies
>>>             >>>>         when the path matches, but this would seem
>>>             to be counter intuitive), and perhaps it could be clarified.
>>>             >>>>
>>>             >>>>         If this change is allowed, then the example
>>>             in appendix B.4 looks like it would need to be fixed,
>>>             since the "limited-acl" probably wouldn't give any
>>>             >>>>         But, possibly I'm misunderstanding how this
>>>             all works!  If so, apologies for the noise :-)
>>>             >>>>
>>>             >>>>         Thanks,
>>>             >>>>         Rob
>>>             >>>>
>>>             >>>>
>>>             draft-ietf-netconf-rfc6536bis, suggested by the Security
>>>             AD Eric Rescola part of the IESG review, which I would
>>>             <mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 10 Nov 2017 20:36:03 +0000

Hi Andy,

Yes, I think those changes look OK.

In addition, in 3.3.4, does it make sense to clarify that descendant 
data nodes are excluded on get requests:

OLD:

   Data nodes to which the client does not have read access are silently
    omitted from the <rpc-reply> message.

NEW:

   Data nodes to which the client does not have read access are silently
    omitted, along with any descendants, from the <rpc-reply> message.

Also, rules 9 and 10 of 3.4.5 may also need to be updated to indicate 
that the operation is rejected if the data node, or any ancestor parent 
data node, has a default-deny-write/all statement.

---

I think that these changes above fix the NACM draft to make it 
consistent with the examples.

The remaining issue is the one first raised in this thread, i.e. the 
change of operation 'none' now requiring 'read' permissions.  If that 
change is retained to mitigate the security issue, then we also need to 
think about how to reduce the impact of the change (i.e. the issue in my 
original response to this thread still applies.)

Thanks,
Rob

On 10/11/2017 18:23, Andy Bierman wrote:
>       data node rule:  controls access for a specific data node and 
> its descendants,
>       identified by its path location within the conceptual XML 
> document for the
>       data node.
>
>
> deny-nacm: This rule denies the "guest" group any access to the <nacm> 
> subtree. Note that the default namespace is only applicable because 
> this subtree is defined in the same namespace as the <data-rule> element.
> NEW:
> deny-nacm: This rule denies the "guest" group any access to the <nacm> 
> subtree.
> Andy
>
>     based examples are so completely wrong?   Whoever wrote and
>     reviewed those examples clearly had a different interpretation of
>     how these path based ACLs worked.
>
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Nov 2017 14:38:07 -0800

On Fri, Nov 10, 2017 at 12:36 PM, Robert Wilton <[email-masked]> wrote:

> In addition, in 3.3.4, does it make sense to clarify that descendant data
> nodes are excluded on get requests:
>
> OLD:
>
> Also, rules 9 and 10 of 3.4.5 may also need to be updated to indicate that
> the operation is rejected if the data node, or any ancestor parent data
> node, has a default-deny-write/all statement.
>
>

OK -- I will look through the rules for related updates

> ---
>
> I think that these changes above fix the NACM draft to make it consistent
> with the examples.
>

I agree now that data-rule is changed that the original change makes NACM
more difficult to use.
There is much less ACL maintenance required if the "none" edit-op
translates to "no-check"
rather than if it is a "read" request.

It is very implementation-specific what instance-info can be derived from
the error-tag
or other error information, allowing an attacker to guess the ancestor
instances
(i.e, nodes where the access check is "none" instead of "read")

In our server, field validation is done before instance validation in most
cases,
so an 'invalid-value' can be returned regardless of the instances actually
existing or not.

I propose that the draft revert to the old text, and a note added in the
security considerations
that servers should try not to expose instance information via error
reporting.

I think your enhancement for ancestors is not the only way to solve the
"/home read permit" problem.
I agree that we don't want a permit rule for read, just the user-dir

   path=/home/user1, operation=*, group=user1, action=permit

IMO the safe way to do that is to say that a read request on a normal
NP-container
is implicitly granted if no rule is found to prevent it.  The same
free-pass is not granted
to P-containers or lists (they need explicit rules). They convey data model
information
but NP containers do not.

Andy

>            specified by the path, or is a descendant data node of this data node.
>
>>>> > We should be doing more than clarifying it.  We need to fix it so
>>>> that it works in a sensible way.  I.e. to make the normative text
>>>> consistent with the behaviour currently described in the examples in
>>>> > the appendix B.4.
>>>> >
>>>> prefix from the root of the tree.  I.e. so the data-rule "/foo" matches
>>>> "/foo" and all of foo's descendant children nodes.
>>>>
>>>> Strongly agree.
>>>>
>>>>
>>>
>>>> allows read access for all ancestor parent nodes up to the root.  (I.e. to
>>>> >>>     My reading of this is that it implies that the interpretation
>>>> of the path rule is (i), but this is not how I would normally expect an ACL
>>>> "read /A" since that implies "read A/B" as well (as long as the rules are
>>>> listed in the correct order).
>>>> >>>
>>>> >>>
>>>> >>>>         running datastore then with the existing RFC, that could
>>>> be expressed with a single rule (example in 6536bis, appendix B.4)
>>>> >>>>
>>>> >>>>         E.g. For a tree of data nodes, rooted at A, if we wanted
>>>> to give read/write access only to "J" subtree, and no access for the rest
>>>> of the tree then:
>>>> >>>>
>>>> >>>>                          A
>>>> >>>>                          |
>>>> >>>>                 --------------------
>>>> >>>>                 |      |     |     |
>>>> >>>>                 B      C     D     E
>>>> >>>>                 |
>>>> >>>>            -----------
>>>> >>>>            |   |  |  |
>>>> >>>>            F   G  H  J
>>>> >>>>                      |
>>>> >>>>                     ...
>>>> >>>>
>>>> >>>>
>>>> >>>>         If this change is allowed, then the example in appendix
>>>> B.4 looks like it would need to be fixed, since the "limited-acl" probably
>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6
>>>> 536bis-08.txt>
>>>> >>>>>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Nov 2017 17:18:55 -0800

Hi,

I have made the descendant node clarifications to the github draft-09
version.
No other changes have been made.

I think you have shown that a lot of "deny rule" maintenance would be needed
with the new edit-op=none change, possibly making real deployments more
vulnerable
than the current behavior for access operation "none".

Andy

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 13 Nov 2017 16:28:10 +0100 (CET)

Hi,

I just read this thread, and I agree with the changes, but see below
for a comment.

>            specified by the path, or is a descendant data node of this

I propose:

             The rule does not have a "rule-type" defined or the
             "rule-type" is "data-node" and the "path" matches the
             requested data node, action node, or notification node.
             A path is considered to match if the requested node
             is the node specified by the path, or is a
             descendant node of the path.

Note:  s/current node/requested node/ which is the term used in the
first sentence.  And then s/data node/node/ since the first sentence
refer to data-, action-, and notification node.

I have checked in this fix in the repo.

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 15 Nov 2017 09:05:56 +0800

Andy,

I assume you will incorporate these changes in the -09 version of the draft.

However, I am unable to review the changes in github. Can you post the diffs of the draft w.r.t. -08 version.

That still leaves us with one issue, and that has to do with the what permission to give edit-operation. I am assuming the WG agrees that making the change from ‘none’ to ‘read’ for edit operations makes maintenance more difficult and makes the operation more vulnerable, unless all the deny rules are in place.

We will need to update the security considerations section to address Eric’s concerns. How about this update?

OLD:
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances.

NEW:
Therefore, a server MUST NOT vary their OPTIONS responses
based on the existence of the underlying resource, which would
indicate the presence or absence of resource instances. In particular
servers should not expose instance information before validating field
information.

Cheers.

> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 
> Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi,
>> 
Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Nov 2017 11:12:23 -0800

Hi,

I updated the draft with these changes on github.
There is a draft-pre-09.txt file now for you to review.

Andy

On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> That still leaves us with one issue, and that has to do with the what
> permission to give edit-operation. I am assuming the WG agrees that making
> the change from ‘none’ to ‘read’ for edit operations makes maintenance more
> difficult and makes the operation more vulnerable, unless all the deny
> rules are in place.
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 16 Nov 2017 12:29:27 +0800

"validating field information" is slightly unclear to me, can this be 
reworded slightly?

Thanks,
Rob

On 16/11/2017 03:12, Andy Bierman wrote:
> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Andy,
>
>     However, I am unable to review the changes in github. Can you post
>     the diffs of the draft w.r.t. -08 version.
>
>     That still leaves us with one issue, and that has to do with the
>     what permission to give edit-operation. I am assuming the WG
>     agrees that making the change from ‘none’ to ‘read’ for edit
>     operations makes maintenance more difficult and makes the
>     operation more vulnerable, unless all the deny rules are in place.
>
>     We will need to update the security considerations section to
>     address Eric’s concerns. How about this update?
>
>     OLD:
>
>>     On Nov 13, 2017, at 11:28 PM, Martin Bjorklund <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>
>>>     document

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 16 Nov 2017 12:55:17 +0800

Can you provide text?

> On Nov 16, 2017, at 12:29 PM, Robert Wilton <[email-masked]> wrote:
> 
> "validating field information" is slightly unclear to me, can this be reworded slightly?
> 
> Thanks,
> Rob
> 
>> On Tue, Nov 14, 2017 at 5:05 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> Andy,
>> 
>>> On Nov 13, 2017, at 11:28 PM, Martin Bjorklund <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi,
>>> 

Mahesh Jethanandani
[email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Thu, 16 Nov 2017 13:56:40 +0800

I'm not sure I understand exactly what point the previous text was 
stating so I'm not sure whether my proposed text is stating the same 
thing (or whether this has already been stated elsewhere in the draft):

OLD:

NEW:

servers should not expose any instance information before ensuring
that the client has the necessary access permissions to obtain that
information.

Is that any more clear?  Or have I missed the point?

Thanks,
Rob

On 16/11/2017 12:55, Mahesh Jethanandani wrote:
> Can you provide text?
>
>> On Nov 16, 2017, at 12:29 PM, Robert Wilton <[email-masked] 
>>>     However, I am unable to review the changes in github. Can you
>>>     post the diffs of the draft w.r.t. -08 version.
>>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 16 Nov 2017 14:16:11 +0800

Robert,

> On Nov 16, 2017, at 1:56 PM, Robert Wilton <[email-masked]> wrote:
> 
> I'm not sure I understand exactly what point the previous text was stating so I'm not sure whether my proposed text is stating the same thing (or whether this has already been stated elsewhere in the draft):
> 
> OLD:

The point of the previous text was to make sure the client should have their access permission checked before any instance information was checked. 

I am ok with this text.

>>> On Nov 16, 2017, at 12:29 PM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 16 Nov 2017 19:40:06 +0800

I have verified that the proposed changes have been incorporated in -09 version of the draft in GitHub.

Based on my discussion with Eric, there is a little more tweak that we need to provide to Security Considerations section in the third paragraph.

OLD:
   There is a risk related to the lack of access control enforcement for
   the RESTCONF OPTIONS method.  The risk here is that the response to
   OPTIONS may vary based on the presence or absence of a resource
   corresponding to the URL's path.  If this is the case, then it can be
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary their OPTIONS responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances.

NEW:
   There is a risk related to the lack of access control enforcement for
   the RESTCONF OPTIONS and PATCH methods.  The risk here is that the response to
   OPTIONS and PATCH may vary based on the presence or absence of a resource
   corresponding to the URL's path.  If this is the case, then it can be
   used to trivially probe for the presence or absence of values within
   a tree.  Therefore, a server MUST NOT vary its responses
   based on the existence of the underlying resource, which would
   indicate the presence or absence of resource instances. In particular
   servers should not expose any instance information before ensuring
   that the client has the necessary access permissions to obtain that
   information. In such cases, servers are expected to always return the “access-
   denied” error response.

Mahesh Jethanandani
[email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Fri, 17 Nov 2017 20:16:08 +0000

The updated text looks OK to me.

We also need to delete this paragraph from the end of section 1.2:

REMOVE:
    The server message processing behavior for the edit operation "none",
    used in the <edit-config>, has been changed.  Now read access is
    required for such data nodes, instead of no access required.

Thanks,
Rob

On 16/11/2017 11:40, Mahesh Jethanandani wrote:
> Based on my discussion with Eric, there is a little more tweak that we 
> need to provide to Security Considerations section in the third 
> paragraph.
>
> OLD:
>     indicate the presence or absence of resource instances.In particular
>> On Nov 16, 2017, at 1:56 PM, Robert Wilton <[email-masked] 
>>>>>     That still leaves us with one issue, and that has to do with
>>>>>     the what permission to give edit-operation. I am assuming the
>>>>>     WG agrees that making the change from ‘none’ to ‘read’ for
>>>>>     edit operations makes maintenance more difficult and makes the
>>>>>>     On Nov 13, 2017, at 11:28 PM, Martin Bjorklund
>>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>     Hi,
>>>>>>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Nov 2017 12:25:16 -0800

Hi,

I updated the draft-pre-09.txt version with these changes.

Andy

On Fri, Nov 17, 2017 at 12:16 PM, Robert Wilton <[email-masked]> wrote:

> need to provide to Security Considerations section in the third paragraph.
>
> OLD:
>
> I'm not sure I understand exactly what point the previous text was stating
> so I'm not sure whether my proposed text is stating the same thing (or
> whether this has already been stated elsewhere in the draft):
>
> OLD:
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Nov 2017 14:25:17 +0100

> Note that this issue is not related to the edit in the original 1-week 
That's right, but we found a source of misinterpretation in the draft 
and you have rightly corrected it in the github v9.

Regards, Benoit

---

From: Robert Wilton <[email-masked]>
Date: Wed, 22 Nov 2017 13:34:44 +0000

Hi Benoit,

There is also one further, unrelated change that I am proposing is made 
the draft before it is published, to help better clarify the expected 
behavior.  It isn't the end of the world if this doesn't go in, but I 
think that it prevents sometime taking a different, but IMO reasonable, 
interpretation of how "when" statements are considered, and then having 
a future argument about what behavior it specified in the standard.

If we clarify it now, then it closes that door :-)

I've proposed text to Andy and Martin on Monday, but I've not heard back 
yet.

Netconf email with proposed text attached.  The text doesn't necessarily 
have to match this, but personally I think that it is useful if the 
draft says something on this.

Thanks,
Rob

On 22/11/2017 13:25, Benoit Claise wrote:
>> Here are some proposed edits to make the data rule consistent with 
>> the examples.
>> Note that this issue is not related to the edit in the original 
>> 1-week change.
>> <nacm> subtree. Note that the default namespace is only applicable 
>> because this subtree is defined in the same namespace as the 
>> <data-rule> element.
>> NEW:
>>>     On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>
>>>
>>>>             clear that rule applied on the parent data-node does
>>>>             not apply to the child nodes. So yes, it would help to
>>>>             clarify it.
>>>>             > (i) that a data-node path match succeeds if it
>>>>             matches the path prefix from the root of the tree. 
>>>>             I.e. so the data-rule "/foo" matches "/foo" and all of
>>>>             foo's descendant children nodes.
>>>>
>>>>             Strongly agree.
>>>>
>>>>
>>>>
>>>         Because otherwise the path match part of the NACM solution
>>>         is really broken, and the path based examples in the
>>>         appendix are entirely misleading and wrong.  The only way
>>>         those examples make sense is the paths match descendant
>>>         children nodes as well.
>>>
>>>
>>>
>>     Yes it is, particularly when the difference is between needing a
>>     1 line rule, and a 100+ line rule.
>>
>>>
>>     "group=user1, path=/home/user1, action=permit", hence meaning
>>     that the rule works the same way as it does on an rfc6536
>>     compliant implementation.
>>
>>>
>>>        read-default=deny
>>>         but not under /var/log/apache2, would fail to match rule
>>>         (1), but would match rule (2) instead and be permitted.
>>>
>>>
>>>
>>>         operation 'none' didn't require read access.  Now read
>>>         access is required even for operation 'none', then this
>>>         change makes sense to make the NACM changes backwards
>>>         compatible, whilst still closing the security hole.
>>>
>>>         Thanks,
>>>         Rob
>>>
>>>>
>>>>
>>>>             --Per
>>>>
>>>>
>>>>
>>>>         Andy
>>>>
>>>>             > Thanks,
>>>>             > Rob
>>>>             >
>>>>             >
>>>>             >>
>>>>             >> Thanks
>>>>             >>
>>>>             >>>
>>>>             >>>
>>>>             >>> Andy
>>>>             >>>
>>>>             >>>
>>>>             "/acme:interfaces/acme:interface[acme:name='dummy']"
>>>>             >>>     Otherwise if the interpretation is (ii) then
>>>>             you only need "read /A" since that implies "read A/B"
>>>>             as well (as long as the rules are listed in the correct
>>>>             order).
>>>>             >>>
>>>>             >>>
>>>>             above.  In which case the "read/write 'A/B/J' rule
>>>>             would not be sufficient.  It would be necessary to
>>>>             define an Xpath expressions that contains
>>>>             >>>>         I'm not that familiar with NACM, but if
>>>>             you want to give a particular set of users read/write
>>>>             access to a subtree, but not allow them to have any
>>>>             other access to the configuration in the
>>>>             RFC, that could be expressed with a single rule
>>>>             (example in 6536bis, appendix B.4)
>>>>             >>>>
>>>>             of the tree down to the data node that read/write
>>>>             access is actually being given to.  The
>>>>             >>>>         E.g. For a tree of data nodes, rooted at
>>>>             A, if we wanted to give read/write access only to "J"
>>>>             >>>>         If this change is allowed, then the
>>>>             example in appendix B.4 looks like it would need to be
>>>>             fixed, since the "limited-acl" probably wouldn't give
>>>>             any access at all, unless default read
>>>>             >>>>         access had been given.
>>>>             >>>>
>>>>             >>>>         But, possibly I'm misunderstanding how
>>>>             this all works!  If so, apologies for the noise :-)
>>>>             >>>>
>>>>             >>>>         Thanks,
>>>>             >>>>         Rob
>>>>             >>>>
>>>>             >>>>
>>>>             draft-ietf-netconf-rfc6536bis, suggested by the
>>>>             Security AD Eric Rescola part of the IESG review, which
>>>>             I would like to validate with the WG. See
>>>>             >>>>>

Subject: Re: NACM and "when" statements
From: Robert Wilton <[email-masked]>
To: Martin Bjorklund <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 21 Nov 2017 13:58:01 +0000

Proposed text below.

On 21/11/2017 09:58, Martin Bjorklund wrote:
>> On Mon, Nov 20, 2017 at 2:28 AM, Robert Wilton <[email-masked]> wrote:
>>
>>> Hi Andy, Martin,
>>>
>>> I've got a question about 'when' statement handling related to NACM.
>>>
>>> Due to when statements, it is possible that a client could implicitly
>>> cause a change to a part of the data tree that they have no write access to
>>> because they cause a when condition to evaluate to a different answer.  Am
>>> I correct in presuming that this implicit change is allowed?
>>>
>>> E.g. in the following example, a user may only have write access to "baz"
>>> but not "bar". If they create "baz" then that may implicitly cause "bar" to
>>> be deleted.  Further, even if this implicit delete to "bar" is allowed, I
>>> presume that the equivalent explicit change or creating "baz" and deleting
>>> "bar" would still be rejected because there is no explicit write access to
>>> bar.
>>>
>>> container foo {
>>>    leaf bar {
>>>     when "not(../baz)";
>>>    }
>>>    leaf baz {
>>>    }
>>> }
>>>
>>> Should this be mentioned in the NACM draft at all?  I'm not convinced that
>>> the draft makes the correct behaviour for handling 'when' statements
>>> obvious.
>>>
>>> Similar considerations could also apply when writing to choice statements.
>>>
>>>
>> I just confirmed that our server does not enforce nacm:default-deny-all for
>> the "when-stmt" node.
>> NACM rules say "user X is allowed to write /foo/baz" and nothing about
>> /foo/baz side-effects.
> Our implementation works the same way, and I agree this is reasonable
> behavior.  NACM controls access to the operations, not the side
> effects.
OK, so I propose the following NEW additions to rfc6536bis:

Added to the end of section "1.2.  Changes Since RFC 6536":

    The data node access behavior for path matches has been clarified to
    also include matching descendant nodes of the specified path.

    The <edit-config> operation access rights behavior has been clarified
    to indicate that write access is not required for data nodes that are
    implicitly modified through side-effects (such as the evaluation of
    YANG when-stmts, or data nodes implicitly deleted when creating a
    data node under a different branch under a YANG choice-stmt).

Added to the end of section "3.2.5.  <edit-config> Operation":

    An <edit-config> operation may cause data nodes to be implicitly
    created or deleted as an implicit side-effect of a requested
    operation.  For example, a YANG when-stmt expression may evaluate to
    a different result, causing data nodes to be deleted, or created with
    default values; or if a data node is created under one branch of a
    YANG choice-stmt, then all data nodes under the other branches are
    implicitly removed.  No NACM access rights are required on any data
    nodes that are implicitly changed as a side effect of another allowed
    operation.

Added after paragraph 4 of "3.7.2.  General Configuration Issues":

    It is possible that the data model definition itself (e.g., YANG
    when-stmt or choice-stmt) will allow a session to implicitly create
    or delete nodes that the session does not have write access to as an
    implicit side effect from the processing of an allowed <edit-config>
    operation.

In case it is useful, git diff for the above change is also attached.

Thanks,
Rob

>
>
> /martin
>
>
>> YANG says nodes exist only if the when-stmt is true and nothing about how
>> they change
>> from true to false. I don't think access control is mentioned in either RFC
>> for this corner-case.
>>
>> Perhaps more security consideration text is needed, warning that any nodes
>> that are deleted
>> by the server because of false when-stmt evaluation are exempt from access
>> control.
>>
>> It would be a significant change to implementations to enforce delete
>> permissions on
>> when-stmt and choice-stmt automatic node removal. This can also apply to
>> automatic
>> creation of default nodes (when-stmt evaluates true, was false).
>>
>>
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>
>> Andy
> .
>

diff --git a/netconf-access-control.xml.in b/netconf-access-control.xml.in
index 402bf7c..6c5abdf 100644
--- a/netconf-access-control.xml.in
+++ b/netconf-access-control.xml.in
@@ -286,6 +286,20 @@
         so a simple mapping to the existing NACM procedures
         and data model is possible.
       </t>
+      <t>
+        The data node access behavior for path matches has been
+        clarified to also include matching descendant nodes of the
+        specified path.
+      </t>
+      <t>
+        The &lt;edit-config&gt; operation access rights behavior has
+        been clarified to indicate that write access is not required
+        for data nodes that are implicitly modified through
+        side-effects (such as the evaluation of YANG when-stmts, or
+        data nodes implicitly deleted when creating a data node under
+        a different branch under a YANG choice-stmt).
+
+      </t>
     </section>
   </section>
 
@@ -990,6 +1004,18 @@
           be exposed in any &lt;rpc-error&gt; elements
           within the reply.
         </t>
+        <t>
+          An &lt;edit-config&gt; operation may cause data nodes to be
+          implicitly created or deleted as an implicit side-effect of
+          a requested operation.  For example, a YANG when-stmt
+          expression may evaluate to a different result, causing data
+          nodes to be deleted, or created with default values; or if a
+          data node is created under one branch of a YANG choice-stmt,
+          then all data nodes under the other branches are implicitly
+          removed.  No NACM access rights are required on any data
+          nodes that are implicitly changed as a side effect of
+          another allowed operation.
+        </t>
       </section>
 
       <section title="&lt;copy-config&gt; Operation">
@@ -2047,6 +2073,13 @@ m4_include(ietf-netconf-acm.yang)
          by examining the presence and values of different data nodes.
        </t>
        <t>
+         It is possible that the data model definition itself (e.g.,
+         YANG when-stmt or choice-stmt) will allow a session to
+         implicitly create or delete nodes that the session does not
+         have write access to as an implicit side effect from the
+         processing of an allowed &lt;edit-config&gt; operation.
+       </t>
+       <t>
          There is a risk that non-standard protocol operations, or
          even the standard &lt;get&gt; protocol operation, may
          return data that "aliases" or "copies" sensitive data

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Nov 2017 14:41:09 +0100

Hi Rob,

At that points in time, if it clarifies the spec. and the authors agree 
with this, let's do the right thing.

Regards, Benoit.
>
> Hi Benoit,
>
> There is also one further, unrelated change that I am proposing is 
> made the draft before it is published, to help better clarify the 
> expected behavior.  It isn't the end of the world if this doesn't go 
> in, but I think that it prevents sometime taking a different, but IMO 
> reasonable, interpretation of how "when" statements are considered, 
> and then having a future argument about what behavior it specified in 
> the standard.
>
> I've proposed text to Andy and Martin on Monday, but I've not heard 
> back yet.
>
> Netconf email with proposed text attached.  The text doesn't 
> necessarily have to match this, but personally I think that it is 
> useful if the draft says something on this.
>
> Thanks,
> Rob
>
>
>>>>>             > allowed to create an interface because they would
>>>>>             not even have permission to write to the list key
>>>>>             'name' node required to create a list entry!  Instead,
>>>>>             a separate rule would be required for every
>>>     The examples in B.4, and the definition of "/" matching all
>>>     nodes supports this interpretation.
>>>
>>>     reviewed those examples clearly had a different interpretation
>>>     of how these path based ACLs worked.
>>>
>>>
>>>     allows read access for all ancestor parent nodes up to the
>>>     root.  (I.e. to mitigate the original change proposed on this
>>>     thread.)
>>>>         /var/log, but not under /var/log/apache2, would fail to
>>>>         match rule (1), but would match rule (2) instead and be
>>>>         permitted.
>>>>
>>>>
>>>>
>>>>>             >>>     As an example, using the tree below.  if I
>>>>>             have a rule that matches path "A/B" then does that
>>>>>             apply to only the specific node "A/B", or does it also
>>>>>             interpretation of the path rule is (i), but this is
>>>>>             not how I would normally expect an ACL rule to apply
>>>>>             in a tree like object (e.g a directory
>>>>>             >>>     file system).
>>>>>             >>>
>>>>>             >>>     If the rule is (i)  then the access rule
>>>>>             allows the client to read the specific node
>>>>>             as well (as long as the rules are listed in the
>>>>>             correct order).
>>>>>             >>>
>>>>>             >>>
>>>>>             you would also need all the explicit deny statements
>>>>>             as well, otherwise they would be allowed by the "read
>>>>>             /A" rule above.
>>>>>             >>>
>>>>>             >>>     Thanks,
>>>>>             >>>     Rob
>>>>>             >>>
>>>>>             >>>
>>>>>             >>>>
>>>>>             >>>>
>>>>>             >>>>     Andy
>>>>>             >>>>
>>>>>             >>>>
>>>>>             >>>>         With this new change, I think that you
>>>>>             may need to configure many more rules to achieve the
>>>>>             same thing.  I think that you would need to give read
>>>>>             access to the top node in the desired
>>>>>             rules for every sibling child node walking from the
>>>>>             top of the tree down to the data node that read/write
>>>>>             The draft doesn't seem to be particularly clear on
>>>>>             this point (it states that the rule applies
>>>>>             >>>>         when the path matches, but this would
>>>>>             seem to be counter intuitive), and perhaps it could be
>>>>>             clarified.
>>>>>             >>>>
>>>>>             Security AD Eric Rescola part of the IESG review,
>>>>>             which I would like to validate with the WG. See
>>>>>             >>>>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Nov 2017 10:09:41 -0800

> with this, let's do the right thing.
I will add the new text if that is what the WG wants.
There have not been any comments on this issue.

Andy

> behavior.  It isn't the end of the world if this doesn't go in, but I think
> that it prevents sometime taking a different, but IMO reasonable,
> interpretation of how "when" statements are considered, and then having a
> future argument about what behavior it specified in the standard.
>
> have to match this, but personally I think that it is useful if the draft
> says something on this.
> Thanks,
> Rob
>
>
> That's right, but we found a source of misinterpretation in the draft and
> you have rightly corrected it in the github v9.
>
> Regards, Benoit
>
>
>
> sec. 3.3.5:
>
> OLD:
>
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 23 Nov 2017 10:44:11 +0000

Hi Andy,

On 22/11/2017 18:09, Andy Bierman wrote:
>
>
> On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Rob,
>
>     At that points in time, if it clarifies the spec. and the authors
>     agree with this, let's do the right thing.
>
>
Having read this draft, I was undecided what the intended behavior 
actually should be.

The way that Yumapro and Tail-f have implemented this is reasonable, and 
is probably also the way that I would implemented it.

But I also think that it would be a reasonable implementation for a 
server to calculate the full change set (taking account of side effects 
from when and choice statements) to the datastore before checking the 
"write data node access control" against the resultant change set.

My interpretation is that the RFC text is ambiguous on what the correct 
behavior is, and one could make a reasonable argument that the current 
RFC actually specifies that the alternative behavior is correct, i.e. 
requiring delete access even if a node is implicitly changes as a side 
effect.  E.g. section 3.2.3 of RFC 6536 states:

    If the protocol operation would result in the deletion of a datastore
    node and the user does not have "delete" access permission for that
    node, the protocol operation is rejected with an "access-denied"
    error.

An <edit-data> request that causes a when constraint to evaluate 
differently does result in a deletion of those data nodes from the 
datastore, and hence according to the text above, requires explicit 
"delete" access permission to accomplish that.

Clearly it would be an interop issue if different servers implemented 
the NACM path based filtering differently.

Hence why I think that it would be prudent for the draft to be more 
explicit on when and choice statement handling.

Thanks,
Rob

>>     There is also one further, unrelated change that I am proposing
>>     is made the draft before it is published, to help better clarify
>>     the expected behavior.  It isn't the end of the world if this
>>     doesn't go in, but I think that it prevents sometime taking a
>>     different, but IMO reasonable, interpretation of how "when"
>>     statements are considered, and then having a future argument
>>     about what behavior it specified in the standard.
>>
>>     I've proposed text to Andy and Martin on Monday, but I've not
>>     heard back yet.
>>
>>>>     Here are some proposed edits to make the data rule consistent
>>>>     with the examples.
>>>     That's right, but we found a source of misinterpretation in the
>>>     draft and you have rightly corrected it in the github v9.
>>>
>>>     Regards, Benoit
>>>>
>>>>
>>>>     sec. 3.3.5:
>>>>
>>>>     OLD:
>>>>
>>>>
>>>>           data node rule:  controls access for a specific data node
>>>>     and its descendants,
>>>>     applicable because this subtree is defined in the same
>>>>     namespace as the <data-rule> element.
>>>>     NEW:
>>>>     On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton
>>>>>>                 >> I would agree with Robert that it was not
>>>>>>                 entirely clear that rule applied on the parent
>>>>>>                 data-node does not apply to the child nodes. So
>>>>>>                 > We should be doing more than clarifying it.  We
>>>>>>                 need to fix it so that it works in a sensible
>>>>>>                 way.  I.e. to make the normative text consistent
>>>>>>                 with the behaviour currently described in the
>>>>>>                 examples in
>>>>>>                 > the appendix B.4.
>>>>>>                 >
>>>>>>                 > If we follow Andy's interpretation that a data
>>>>>>                 rule doesn't match child nodes then those
>>>>>>                 examples are completely wrong.  E.g. the 4th rule
>>>>>>                 is described as "This rule gives the 'admin'
>>>>>>                 group read-write
>>>>>>                 > access to all acme <interface> entries."  But
>>>>>>                 If the path only strictly matches
>>>>>>                 "/acme:interfaces/acme:interface" then the admin
>>>>>>                 > allowed to create an interface because they
>>>>>>                 would not even have permission to write to the
>>>>>>                 list key 'name' node required to create a list
>>>>>>                 "/acme:interfaces/acme:interface"! I think that
>>>>>>                 this makes "permit" data-node rules completely
>>>>>>                 unusable.
>>>>>>
>>>>>>                 > To fix this properly, we need to make the
>>>>>>                 data-node path rule a prefix match.  In
>>>>>>                 particular, we need text that specifies:
>>>>>>                 >
>>>>>>                 matches the path prefix from the root of the
>>>>>>                 tree.  I.e. so the data-rule "/foo" matches
>>>>>             Because otherwise the path match part of the NACM
>>>>>             solution is really broken, and the path based examples
>>>>>             in the appendix are entirely misleading and wrong. 
>>>>>             The only way those examples make sense is the paths
>>>>>             match descendant children nodes as well.
>>>>>
>>>>>
>>>>>
>>>>         incorrectly specified; and that the examples, definition of
>>>>         "/" and standard practice are right.
>>>>
>>>>         Otherwise, how did IETF manage to publish an RFC where the
>>>>         path based examples are so completely wrong?   Whoever
>>>>         wrote and reviewed those examples clearly had a different
>>>>         interpretation of how these path based ACLs worked.
>>>>
>>>>
>>>>         Yes it is, particularly when the difference is between
>>>>         needing a 1 line rule, and a 100+ line rule.
>>>>
>>>>>
>>>>         path prefix from the root of the tree.  I.e. so the
>>>>         data-rule "/foo" matches "/foo" and all of foo's descendant
>>>>         children nodes.
>>>>         "/home".  Read access to that node it is implicitly given
>>>>         via "group=user1, path=/home/user1, action=permit", hence
>>>>         meaning that the rule works the same way as it does on an
>>>>         rfc6536 compliant implementation.
>>>>
>>>>>
>>>>>            read-default=deny
>>>>>             /var/log, but not under /var/log/apache2, would fail
>>>>>             to match rule (1), but would match rule (2) instead
>>>>>             and be permitted.
>>>>>
>>>>>
>>>>>
>>>>>>                 > (ii) if a data-node rule has action "permit"
>>>>>>                 then it implicitly allows read access for all
>>>>>>                 ancestor parent nodes up to the root.  (I.e. to
>>>>>             In the RFC version of the NACM this wasn't required
>>>>>             because operation 'none' didn't require read access. 
>>>>>             Now read access is required even for operation 'none',
>>>>>             then this change makes sense to make the NACM changes
>>>>>>                 >>>     As an example, using the tree below.  if
>>>>>>                 I have a rule that matches path "A/B" then does
>>>>>>                 that apply to only the specific node "A/B", or
>>>>>>                 >>>     My reading of this is that it implies
>>>>>>                 that the interpretation of the path rule is (i),
>>>>>>                 but this is not how I would normally expect an
>>>>>>                 ACL rule to apply in a tree like object (e.g a
>>>>>>                 directory
>>>>>>                 >>>  file system).
>>>>>>                 >>>
>>>>>>                 that the path rule is to be interpreted like
>>>>>>                 (ii), or otherwise the example rules seem to be
>>>>>>                 mostly pointless.
>>>>>>                 >>>
>>>>>>                 you only need "read /A" since that implies "read
>>>>>>                 A/B" as well (as long as the rules are listed in
>>>>>>                 the correct order).
>>>>>>                 >>>
>>>>>>                 >>>
>>>>>>                 >>>  Only if the interpretation of the rule is
>>>>>>                 (i) above.  In which case the "read/write 'A/B/J'
>>>>>>                 rule would not be sufficient.  It would be
>>>>>>                 >>>     If the interpretation of the rule is (ii)
>>>>>>                 then you would also need all the explicit deny
>>>>>>                 statements as well, otherwise they would be
>>>>>>                 <mailto:[email-masked]>
>>>>>>                 you want to give a particular set of users
>>>>>>                 read/write access to a subtree, but not allow
>>>>>>                 them to have any other access to the
>>>>>>                 configuration in the
>>>>>>                 >>>>      running datastore then with the
>>>>>>                 existing RFC, that could be expressed with a
>>>>>>                 single rule (example in 6536bis, appendix B.4)
>>>>>>                 >>>>
>>>>>>                 may need to configure many more rules to achieve
>>>>>>                 the same thing.  I think that you would need to
>>>>>>                 rules for every sibling child node walking from
>>>>>>                 the top of the tree down to the data node that
>>>>>>                 read/write access is actually being given to.  The
>>>>>>                 >>>>      E.g. For a tree of data nodes, rooted
>>>>>>                 at A, if we wanted to give read/write access only
>>>>>>                 to "J" subtree, and no access for the rest of the
>>>>>>                 tree then:
>>>>>>                 >>>>
>>>>>>                 >>>>   A
>>>>>>                 >>>>   |
>>>>>>                 >>>>  --------------------
>>>>>>                 >>>>              | |     |     |
>>>>>>                 >>>>              B C     D     E
>>>>>>                 >>>>              |
>>>>>>                 >>>>         -----------
>>>>>>                 >>>>         |   |  |  |
>>>>>>                 >>>>         F   G  H  J
>>>>>>                 >>>>                   |
>>>>>>                 >>>>                  ...
>>>>>>                 >>>>
>>>>>>                 >>>>
>>>>>>                 equivalent ACL rules would need to be 8 rules
>>>>>>                 long (assuming default deny all):
>>>>>>                 >>>>         "read/write 'A/B/J'
>>>>>>                 >>>>         "read A"
>>>>>>                 >>>>         "deny C"
>>>>>>                 >>>>         "deny D"
>>>>>>                 >>>>         "deny E"
>>>>>>                 >>>>         "deny F"
>>>>>>                 >>>>         "deny G"
>>>>>>                 >>>>         "deny H"
>>>>>>                 >>>>
>>>>>>                 matches for the given path and all descendant
>>>>>>                 nodes.  The draft doesn't seem to be particularly
>>>>>>                 seem to be counter intuitive), and perhaps it
>>>>>>                 could be clarified.
>>>>>>                 >>>>
>>>>>>                 example in appendix B.4 looks like it would need
>>>>>>                 to be fixed, since the "limited-acl" probably

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 23 Nov 2017 11:55:17 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> The way that Yumapro and Tail-f have implemented this is reasonable,
> and is probably also the way that I would implemented it.
> 
> server to calculate the full change set (taking account of side
> effects from when and choice statements) to the datastore before
> checking the "write data node access control" against the resultant
> change set.
> 
> My interpretation is that the RFC text is ambiguous on what the
> correct behavior is, and one could make a reasonable argument that the
> current RFC actually specifies that the alternative behavior is
> correct, i.e. requiring delete access even if a node is implicitly
> changes as a side effect.  E.g. section 3.2.3 of RFC 6536 states:
> 

I agree.  The text you proposed earlier is fine, except I would avoid
the NETCONF specific words, and be more generic.

/martin

---

From: "t.petch" <[email-masked]>
Date: Fri, 24 Nov 2017 11:02:20 -0000

<inline>

Tom Petch

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Thursday, November 23, 2017 10:44 AM

> > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote:
> >
> >     Hi Rob,
> >

> The way that Yumapro and Tail-f have implemented this is reasonable,
and
> server to calculate the full change set (taking account of side
effects
> My interpretation is that the RFC text is ambiguous on what the
correct

Rob

I have been reading that paragraph since this thread started and
wondering how it could be thought unclear, what am I missing:-)

To me it clearly states that the user must have the appropriate access
for the consequences of whatever they do, be that 'when', 'choice' or
anything else! Indeed, I see exactly that behaviour in operational
(non-network) databases of which I am a user with limited privileges.

My other thought was that given all the complexities of 'when' that
emerged during the specification of YANG 1.1, perhaps, were I an
implementor of this, I would take the easy option and ignore the side
effects of 'when'; but I might feel guilty about doing so.

If the new paragraphs go in as proposed, then I think that the two
paragraphs you quote need changing else that section looks to me like an
oxymoron.

Tom Petch

> >>>>>             On 10/11/2017 15:49, Andy Bierman wrote:
<snip>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Nov 2017 07:30:03 -0800

> (non-network) databases of which I am a user with limited privileges.

This is not correct.
The server is the entity that is cleaning up false when-stmt or unselected
cases
for a choice-stmt.

NACM does not prevent the sever from making any changes to the system.
It only affects the operations requested by a client.

Andy

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 24 Nov 2017 09:34:03 -0800

Hi -

Andy replied:
> This is not correct.
> The server is the entity that is cleaning up false when-stmt or 
> unselected cases
> for a choice-stmt.
> 

I think the point is that lots of Rube Goldberg / domino effect attacks
are made possible through management interfaces.  Sometimes
they are subtle, sometimes they're a result of explicit side-
effects in the definition of management information.  I think the
real question here is who is responsible for working through and
*documenting* such security consequences, and, subsequently, whether
the access control interface should deal them automagically (not
suggesting it's impossible, but there are aspects that could be hard)
or that figuring out the interconnections should be an exercise left
to the imagination of security administrators.

The former approach reduces the operational workload, but means more
complexity for standardizers and for the folks implementing the
access control infrastructure.  It also carries the risk of people
becoming over-confident that the standardizers' analysis might be
correct.  The latter approach requires hoping that every system's
security administrator will carry out an analysis of the side-effects
and correctly formulate access control policies that will do the right
things.  This carries the risks that the analysis will seldom happen,
and that the formulation of explicit access control policies to
account for side-effects is likely error-prone for garden-variety
administrators.

Pick your poison.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Nov 2017 10:01:01 -0800

> account for side-effects is likely error-prone for garden-variety

One of the design goals of NACM was to keep it simple to use.
There was a perception that VACM was too difficult to use,
and that's why it was not widely deployed.

I think the security considerations section for each YANG module RFC
should point out the linkage issues from when-stmt and choice-stmt.
The design goal should be to permit or deny access to an entire module.
The suggested granularity should be documented if any data-rules
are expected for normal operation.

Randy
Andy

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 24 Nov 2017 11:33:01 -0800

Hi -

On 11/24/2017 10:01 AM, Andy Bierman wrote:
> 
> 
> On Fri, Nov 24, 2017 at 9:34 AM, Randy Presuhn 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi -
> 
>     Tom wrote:
> 

Perhaps, but the security properties you're advocating for NACM
are exactly the same as as those of VACM in this regard - both
only consider access to a specific piece of information, and
leave the consideration of any side-effects as a problem for
the security administrator to puzzle out.  Keeping the implementation
of the access control model simple pushes operational complexity
to the security administrator.

> should point out the linkage issues from when-stmt and choice-stmt.

This is a start.  Unfortunately, these statements won't necessarily be
near the information objects for which an access control policy is being
formulated.

> The design goal should be to permit or deny access to an entire module.

I think such a goal is asking for trouble.  Things will either become
unwieldy from an operational/security perspective, or the modules
themselves will become so small and fragmented as to be
incomprehensible.

> are expected for normal operation.

Agreed, but consider the question of managing access in the presence
of side-effects going beyond "data-rules."  It's certainly a lot
easier for infrastructure designers to think about systems that behave
like VACM / NACM, but is such an "easy to think about" (and consequently
limited) model really in the best interest of folks who need to secure
their operations?

I'm not taking a hard stance either way, but I think the question needs
serious consideration.

Randy

---

From: "t.petch" <[email-masked]>
Date: Sat, 25 Nov 2017 12:42:34 -0000

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "t.petch" <[email-masked]>

> The server is the entity that is cleaning up false when-stmt or
unselected

Andy

My model is slightly different, that the server is a black box, with an
interface through which I can make authorised changes.  If something I
do causes the deletion of something I am not allowed to delete, may be
not even to read, well, we part company on the acceptability of that!

I do accept, as Randy points out, that the situation is complicated.  I
am reminded of the issues that came up relating to the 'when' statement
when preparing YANG 1.1.  Yes, 'when' makes things possible and is very
useful but at the same time, its side effects can be troublesome.  I
would like to wrap it up in a conceptual bubble so you could not have
the sort of fine-grained access control that allows the case that Rob
postulates to occur but have no idea what that might look like.  And I
don't know how much 'when' is used in that way in existing YANG
modules - uh huh, more reading required.

Tom Petch

> > > >>     necessarily have to match this, but personally I think that
it
> > is
> > > >>>     That's right, but we found a source of misinterpretation
in
> > the
> > > >>>>     deny-nacm: This rule denies the "guest" group any access
to
> > the
> > > >>>>     deny-nacm: This rule denies the "guest" group any access
to
> > the

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Nov 2017 07:53:15 -0800

> modules - uh huh, more reading required.

When the access control is too complicated, it does not get used.
Instead, the most likely access control is "everybody is the root user".
The server pruning of false when/choice data nodes is considered cleanup.
The pruned data is no longer relevant to the data model. This is the
indended
use, but when-stmt can easily be abused.

The complex tangled web of dependencies is no worse
than it has been with CLI for 30 years, where every dependency is ad-hoc
and probably undocumented. The granularity of CLI-based access control
is less granular than NACM.

It is possible that vendors and operators are willing to spend hours and
days
figuring out how to tune the NACM rules to allow a specific edit to work.
Of course the operator will not even be told by the server which nodes
are blocking the edit. That would be a security risk.

IMO NACM will be completely unusable if rules are needed to allow
server cleanup of dead nodes.  The additional NACM rules required
might provide more access than intended (unless lots of delete-only
rules are added). The huge jump in NACM rule management complexity is
a new security vulnerability, which might even be worse than the
vulnerability it is intended to fix.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Mon, 27 Nov 2017 10:39:43 +0000

I do get the point that Tom is making here, and have quite a lot of 
sympathy for it.  E.g. by automatically allowing the side effects of 
when/choice statements then we are introducing a potential security hole 
here that operators may find hard to be aware of and mitigate.

It also seems odd to me that a client is allowed to implicitly remove 
some configuration through the side effect of a when/choice statement 
that they are not allowed to delete explicitly.

The alternative of requiring appropriate access for the side-effects, 
seems like an intuitively safer design, but I also get Andy's concern 
that security isn't useful if it become so unwieldy that nobody uses it.

So, I guess the question here is, do we have some concrete examples 
using real data models where the extra NACM delete rules would be 
required?  If not then perhaps requiring the explicit access for side 
effects would be better.

Thanks,
Rob

On 25/11/2017 15:53, Andy Bierman wrote:
>
>
> On Sat, Nov 25, 2017 at 4:42 AM, t.petch <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     From: "Andy Bierman" <[email-masked] <mailto:[email-masked]>>
>     To: "t.petch" <[email-masked] <mailto:[email-masked]>>
>
>
>     > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > > <inline>
>     > >
>     > > Tom Petch
>     > >
>     > > From: "Robert Wilton" <[email-masked]
>     <mailto:[email-masked]>>
>     > > > But I also think that it would be a reasonable
>     implementation for
>     a
>     > > > from when and choice statements) to the datastore before
>     checking
>     the
>     > > > requiring delete access even if a node is implicitly changes
>     as a
>     side
>     > > >     node and the user does not have "delete" access
>     permission for
>     > > that
> It is possible that vendors and operators are willing to spend hours 
> and days
>     > > > >>     doesn't go in, but I think that it prevents sometime
>     taking
>     a

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Nov 2017 11:49:24 +0100

> are expected for normal operation.

It is quite likely that in more complex situations (e.g. involving
augments) such side effects may go unnoticed. And also, YANG modules
aren't produced only by SDOs, and this just opens a possibility for
hidden back-doors.

I have been criticising this auto-delete feature several times in the
past, and other people, too (I think Balazs was one). In my view, a sane
server behaviour would be to just report schema violation, rather than
delete anything automatically. This not only avoids the present NACM
issue but also helps prevent catastrophic mistakes.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Robert Wilton <[email-masked]>
Date: Mon, 27 Nov 2017 10:54:31 +0000

Hi Lada,

> issue but also helps prevent catastrophic mistakes.
Regarding auto-delete, do you have same opinion for both when and choice 
statements, or do you seem their ideal behavior as being different?

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Nov 2017 12:35:23 +0100

> statements, or do you seem their ideal behavior as being different?

No, it should IMO be the same: using another case in a choice would mean to
delete the existing case instance first (which may fail if the client has no
right to do so) and then create the new case. It's not a big deal but everything
 are explicit client's actions, no side effects.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Nov 2017 07:12:53 -0800

On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <[email-masked]> wrote:

> It also seems odd to me that a client is allowed to implicitly remove some
> configuration through the side effect of a when/choice statement that they
> are not allowed to delete explicitly.
>
> seems like an intuitively safer design, but I also get Andy's concern that
> security isn't useful if it become so unwieldy that nobody uses it.
>
> So, I guess the question here is, do we have some concrete examples using
> real data models where the extra NACM delete rules would be required?  If
> not then perhaps requiring the explicit access for side effects would be
> better.
>

Yes -- please provide some examples where it is better to force the operator
to provide extra "delete" rules to allow false-when data nodes to be
deleted.
It seems to me that these rules would allow individual data structures to be
removed by the client, that would not otherwise be possible.

If 3 data structures need to be in place "when /foo exists" then
deleting 1 or 2 of them directly may not be desirable.  Deleting
them all together (i.e., via when-false deletion) may be the intended usage.

The vendor and operator need to be aware of the data model dependencies.
That said, how come CLI-based configuration does not have this problem?
(Or rather, why has this problem been ignored for so long? Maybe it not
that real?)

Thanks,

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Nov 2017 16:32:46 +0100

On Mon, 2017-11-27 at 07:12 -0800, Andy Bierman wrote:
> > I do get the point that Tom is making here, and have quite a lot of sympathy
> > for it.  E.g. by automatically allowing the side effects of when/choice
> > statements then we are introducing a potential security hole here that
> > operators may find hard to be aware of and mitigate.
> > configuration through the side effect of a when/choice       statement that
> > they are not allowed to delete explicitly.
> > The alternative of requiring appropriate access for the side-effects, seems
> > like an intuitively safer design, but I also get Andy's concern that
> to provide extra "delete" rules to allow false-when data nodes to be deleted.

Here is an example:

Module A contains a choice with two cases, say "foo" and "bar". An operator
installs an instance of case "foo" and specifies NACM rules so that a non-
privileged client cannot remove it. Later, module B is added to the data model,
and it augments the choice with another case "baz". If a non-privileged user is
now allowed to create an instance of case "baz", he can trick the server into
deleting the protected instance of "foo".

So, module A may have bullet-proof security considerations and still, side
effects from module B create a security hole.

Lada  

> (Or rather, why has this problem been ignored for so long? Maybe it not that
> real?)
> 
> > Thanks,
> > Rob
> > 
> 
> Andy
>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 27 Nov 2017 15:44:27 +0000

On 27/11/2017 15:12, Andy Bierman wrote:
>
>
> On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <[email-masked] 
>     I do get the point that Tom is making here, and have quite a lot
>     of sympathy for it.  E.g. by automatically allowing the side
>     effects of when/choice statements then we are introducing a
>     potential security hole here that operators may find hard to be
>     aware of and mitigate.
>
>     It also seems odd to me that a client is allowed to implicitly
>     remove some configuration through the side effect of a when/choice
>     statement that they are not allowed to delete explicitly.
>
>     The alternative of requiring appropriate access for the
>     side-effects, seems like an intuitively safer design, but I also
>     get Andy's concern that security isn't useful if it become so
>     unwieldy that nobody uses it.
>
>     So, I guess the question here is, do we have some concrete
>     examples using real data models where the extra NACM delete rules
>     would be required?  If not then perhaps requiring the explicit
>     access for side effects would be better.
>
>
>
Yes, this is true.

But it is still odd that they a client is allowed to delete the 
configuration, just not explicitly.  I.e. it is strange that they are 
not allowed to put in a semantically equivalent request that explicitly 
deletes the configuration, they are only allowed to do it if the delete 
is implicit.  This seems inconsistent.

> them all together (i.e., via when-false deletion) may be the intended 
If there is a dependency that all three exist then that may be better 
expressed with a must statement instead.

> That said, how come CLI-based configuration does not have this problem?
My experience of CLI based configurations do have these sorts of 
problems, and many more :-)

> (Or rather, why has this problem been ignored for so long? Maybe it 
> not that real?)
This may be the real crux of the argument:

It probably doesn't make sense to use when statements on disjoint parts 
of the YANG schema (e.g. it does not make sense for the OSPF YANG model 
to depend on whether an interface it runs over has an IP address 
configured).  Instead, a more normal usage would be a flag (e.g. like 
interface type) to allow/prevent certain child nodes from being 
available.  In these scenarios, if a user is allowed to change the type 
of an interface then they are most likely allowed to change the other 
settings on the interface as well.

So for 'normal' when statements, it probably doesn't make much 
difference whether or not explicit NACM access is required to the nodes 
being implicitly deleted because the client probably already has the 
necessary access rights.

But for the 'corner case' when statement scenario, that are unlikely to 
be used, it still seems safer to require explicit access permissions 
than implicitly accepting the side effect with no NACM validation.

Thanks,
Rob

>>         > On Fri, Nov 24, 2017 at 3:02 AM, t.petch
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>         >
>>         > > <inline>
>>         > >
>>         > > Tom Petch
>>         > >
>>         > > > >     At that points in time, if it clarifies the spec.
>>         and the
>>         > > authors
>>         > > > from when and choice statements) to the datastore
>>         before checking
>>         the
>>         > > > behavior is, and one could make a reasonable argument
>>         that the
>>         current
>>         > > > RFC actually specifies that the alternative behavior is
>>         correct,
>>         i.e.
>>         > > > requiring delete access even if a node is implicitly
>>         changes as a
>>         side
>>         > > >     If the protocol operation would result in the
>>         deletion of a
>>         > > datastore
>>         > > To me it clearly states that the user must have the
>>         appropriate
>>         access
>>         > > for the consequences of whatever they do, be that 'when',
>>         'choice'
>>         or
>>     The pruned data is no longer relevant to the data model. This is
>>     the indended
>>     It is possible that vendors and operators are willing to spend
>>     hours and days
>>         > > implementor of this, I would take the easy option and
>>         ignore the
>>         side
>>         > > paragraphs you quote need changing else that section
>>         looks to me
>>         like an
>>         > > oxymoron.
>>         > >
>>         > > Tom Petch
>>         > >
>>         > > > Hence why I think that it would be prudent for the
>>         draft to be
>>         more
>>         > > > >>     There is also one further, unrelated change that
>>         I am
>>         proposing
>>         > > > >>     is made the draft before it is published, to
>>         help better
>>         > > clarify
>>         > > > >>     the expected behavior. It isn't the end of the
>>         world if
>>         this
>>         > > > >>     doesn't go in, but I think that it prevents
>>         sometime taking
>>         a
>>         > > > >>     I've proposed text to Andy and Martin on Monday,
>>         but I've
>>         not
>>         > > > >>     heard back yet.
>>         > > > >>
>>         > > > >>>>     Note that this issue is not related to the
>>         edit in the
>>         > > original
>>         > > > >>>>     1-week change.
>>         > > > >>>>     data node rule: controls access for a specific
>>         data
>>         > > > >>>>     node, identified
>>         > > > >>>>     by its path location within the conceptual XML
>>         document
>>         > > > >>>>     for the
>>         > > > >>>>     data node.
>>         > > > >>>>
>>         > > > >>>>
>>         > > > >>>>     NEW:
>>         > > > >>>>
>>         > > > >>>>     * The rule does not have a "rule-type" defined
>>         or the
>>         > > > >>>>     "rule-
>>         > > > >>>>     * The rule does not have a "rule-type" defined
>>         or the
>>         > > > >>>>     "rule-
>>         A path is
>>         > > > >>>>     considered to match if the current data node
>>         is the
>>         > > > >>>>     data node
>>         > > > >>>>     specified by the path, or is a descendant data
>>         node
>>         > > > >>>>     of this data node.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Nov 2017 08:26:08 -0800

On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton <[email-masked]> wrote:

>> some configuration through the side effect of a when/choice statement that
> configuration, just not explicitly.  I.e. it is strange that they are not
> allowed to put in a semantically equivalent request that explicitly deletes
> the configuration, they are only allowed to do it if the delete is
> implicit.  This seems inconsistent.
>
>
It is just as odd that a request  to create /foo/case1 will work if nothing
from
the choice-stmt exists, but will fail if /foo/case2 has to be deleted in
order
to create /foo/case1.

> My experience of CLI based configurations do have these sorts of problems,
> and many more :-)
>

> It probably doesn't make sense to use when statements on disjoint parts of
> the YANG schema (e.g. it does not make sense for the OSPF YANG model to
> depend on whether an interface it runs over has an IP address configured).
> Instead, a more normal usage would be a flag (e.g. like interface type) to
> allow/prevent certain child nodes from being available.  In these
> scenarios, if a user is allowed to change the type of an interface then
> they are most likely allowed to change the other settings on the interface
> as well.
>
> So for 'normal' when statements, it probably doesn't make much difference
> whether or not explicit NACM access is required to the nodes being
> implicitly deleted because the client probably already has the necessary
> access rights.
>
> But for the 'corner case' when statement scenario, that are unlikely to be
> used, it still seems safer to require explicit access permissions than
> implicitly accepting the side effect with no NACM validation.
>

This is fine, except there is no way to tell a normal when from a
corner-case when.

In all cases, the false-when evaluation means the node is not relevant to
the model anymore.
Same for a case that is being replaced by a different case.
In order for this NACM threat to be real. the YANG modeler needs to be
wrong about
whether the false-when states are actually irrelevant to the model in its
new state.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Nov 2017 17:53:47 +0100

On Mon, 2017-11-27 at 08:26 -0800, Andy Bierman wrote:
> > deletes the configuration, they are only allowed to do it if the delete is
> the choice-stmt exists, but will fail if /foo/case2 has to be deleted in order
> to create /foo/case1.

Why is this odd? RFC 7950 says:

   The "choice" statement defines a set of alternatives, only one of
   which may be present in any one data tree.

So it is quite clear that adding /foo/case1 makes the data tree invalid if
/foo/case2 exists.

> > allow/prevent certain child nodes from being available.  In these scenarios,
> > if a user is allowed to change the type of an interface then they are most
> > likely allowed to change the other settings on the interface as well.
> > 
> This is fine, except there is no way to tell a normal when from a corner-case
> when.
> 
> In all cases, the false-when evaluation means the node is not relevant to the
> model anymore.

The client that causes the when expression to become invalid may not be entitled
to decide whether the node is relevant or not.

> In order for this NACM threat to be real. the YANG modeler needs to be wrong
> about
> whether the false-when states are actually irrelevant to the model in its new
> state.

The YANG modeller may be absolutely correct but other modules (out of his
control) may change this.

Lada

> > > > > > > > > >     At that points in time, if it clarifies the spec. and
> > > > > > the
> > > > > > > > authors
> > > > > > > > > But I also think that it would be a reasonable implementation
> > > > > > for
> > > > > > a
> > > > > > > > >     If the protocol operation would result in the deletion of
> > > > > > a
> > > > > > > > datastore
> > > > > > > > >     node and the user does not have "delete" access permission
> > > > > > for
> > > > > > > > that
> > > > > > > > > >>     is made the draft before it is published, to help
> > > > > > better
> > > > > > > > clarify
> > > > > > > > > >>     I've proposed text to Andy and Martin on Monday, but
> > > > > > I've
> > > > > > not
> > > > > > > > > >>     heard back yet.
> > > > > > > > > >>
> > > > > > > > > >>>>     Note that this issue is not related to the edit in
> > > > > > the
> > > > > > > > original
> > > > > > > > > >>>>     1-week change.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Nov 2017 09:20:25 -0800

On Mon, Nov 27, 2017 at 8:53 AM, Ladislav Lhotka <[email-masked]> wrote:

> remove
> side-effects,
> > > > It seems to me that these rules would allow individual data
> structures to
> > > > be

>From a NACM POV, the rule to allow "create /foo/case1" works differently
depending on whether server auto-deletion is used.

IMO, NACM controls client access, and auto-deletion is server access,
which is mandated by the specific YANG data-def statements.

> scenarios,
> difference
> corner-case

The YANG designers need to consider the impact of when statements on the
data model usage.
NACM needs to be used at a sufficiently course granularity and it is quite
possible
to setup NACM with inappropriate granularity, where intended access is
blocked
and unintended access is allowed.

> wrong

The widespread use of vendor extensions and deviations makes it impossible
to
focus on just the standard modules when considering access control.
Perhaps the best the IETF can do is identify YANG usage patterns that need
to considered
when configuring NACM.

Another option is to create smarter NACM filters, based on tags, not data
nodes.
Data rules are very sharp knifes that need to be used with care.

Lada
Andy

> > > > > > > > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <
> [email-masked]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > <inline>
> > > > > > > > >
> > > > > > > > > Tom Petch
> > > > > > > > >
> implementation
> > > > > > > > > > server to calculate the full change set (taking account
> of
> > > > > > > side
> > > > > > > > > effects
> > > > > > > > > > "write data node access control" against the resultant
> change
> > > > > > > set.
> > > > > > > > > >
> > > > > > > > > > My interpretation is that the RFC text is ambiguous on
> what
> > > > > > > the
> > > > > > > > > correct
> changes
> deletion of
> permission
> > > > > > > > NACM does not prevent the sever from making any changes to
> the
> > > > > > > system.
> > > > > > > My model is slightly different, that the server is a black
> box, with
> > > > > > > an
> > > > > > > interface through which I can make authorised changes.  If
> something
> > > > > > > I
> > > > > > > do causes the deletion of something I am not allowed to
> delete, may
> > > > > > > be
> > > > > > > when preparing YANG 1.1.  Yes, 'when' makes things possible
> and is
> > > > > > > very
> > > > > > > would like to wrap it up in a conceptual bubble so you could
> not
> > > > > > > have
> > > > > > > the sort of fine-grained access control that allows the case
> that
> > > > > > > Rob
> > > > > > > postulates to occur but have no idea what that might look
> like.  And
> > > > > > > I
> > > > > > than it has been with CLI for 30 years, where every dependency
> is ad-
> > > > > > hoc
> hours
> > > > > > figuring out how to tune the NACM rules to allow a specific edit
> to
> > > > > > work.
> > > > > > > > > My other thought was that given all the complexities of
> 'when'
> > > > > > > that
> > > > > > > > > If the new paragraphs go in as proposed, then I think that
> the
> > > > > > > two
> > > > > > > > > paragraphs you quote need changing else that section looks
> to me
> > > > > > > like an
> > > > > > > > > oxymoron.
> > > > > > > > >
> > > > > > > > > Tom Petch
> > > > > > > > >
> > > > > > > > > > differently does result in a deletion of those data
> nodes from
> > > > > > > the
> > > > > > > > > > datastore, and hence according to the text above,
> requires
> > > > > > > explicit
> > > > > > > > > > Hence why I think that it would be prudent for the draft
> to be
> > > > > > > more
> sometime
> > > > > > > > > > >>     different, but IMO reasonable, interpretation of
> how
> > > > > > > "when"
> > > > > > > > > > >>     statements are considered, and then having a
> future
> > > > > > > argument
> but
> > > > > > > > > > >>     Netconf email with proposed text attached. The
> text
> > > > > > > doesn't
> > > > > > > > > > >>     necessarily have to match this, but personally I
> think
> > > > > > > that
> > > > > > > it
> > > > > > > > > is
> > > > > > > > > > >>>>     Here are some proposed edits to make the data
> rule
> > > > > > > consistent
> > > > > > > > > > >>>>     with the examples.
> > > > > > > > > > >>>     draft and you have rightly corrected it in the
> github
> > > > > > > v9.
> > > > > > > > > > >>>
> > > > > > > > > > >>>     Regards, Benoit
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     sec. 3.3.5:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     OLD:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     identified by its path location within the
> conceptual
> > > > > > > XML
> > > > > > > > > > >>>>     document for the
> > > > > > > > > > >>>>     data node.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>     data node, action node, or notification node. A
> path
> > > > > > > is
> > > > > > > > > > >>>>     considered to match if the current data node is
> the
> > > > > > > > > > >>>>     data node
> > > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group
> any
> > > > > > > access
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > >>>>     <nacm> subtree. Note that the default namespace
> is
> > > > > > > only
> > > > > > > > > > >>>>     applicable because this subtree is defined in
> the
> > > > > > > same
> > > > > > > > > > >>>>     deny-nacm: This rule denies the "guest" group
> any
> > > > > > > access
> > > > > > > to
> > > > > > > > > the
> > > > > > > > > > >>>>     <nacm> subtree.
> > > > > > > > > > >>>>     Andy
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>>         <[email-masked] <mailto:
> [email-masked]>>
> > > > > > > wrote:
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>

---

From: "t.petch" <[email-masked]>
Date: Tue, 28 Nov 2017 10:10:59 -0000

----- Original Message -----
From: "Robert Wilton" <[email-masked]>
Sent: Monday, November 27, 2017 10:39 AM

> required? If not then perhaps requiring the explicit access for side

Robert

This is what I was obliquely referring to when I said

" And I
"

I did start looking and found that many, if not most, 'when' statements
relate to 'augment', e.g. for a specific interface type, and so are
simpler than the case postulated which can cause an implicit delete (I
have yet to see one such in an actual YANG module).

Then I started wondering what the NACM rules would be like if I wanted
to permit changes to LAN interfaces but not to WAN interfaces, both
specified by 'augment' to the base model.

Then I started wondering if a NACM rule that permitted changes to a LAN
interface would be valid on a server with no LAN interfaces specified.;
and would that change if a LAN card is hot plugged and auto-configured.

Um, more reading required.

As Andy says, NACM needs to be simple else it will not be used.  The
concept is simple - permit LAN, deny WAN - but the NACM rules I am less
clear about.

Tom Petch

the
> >     > > > My interpretation is that the RFC text is ambiguous on
what the
> >     > > correct
> >     > > > behavior is, and one could make a reasonable argument that
the
correct,
changes
a
appropriate
'choice'
> >     interface through which I can make authorised changes. If
something I
> >     when preparing YANG 1.1. Yes, 'when' makes things possible and
is
> >     the sort of fine-grained access control that allows the case
that Rob
'when'
> >     > > implementor of this, I would take the easy option and ignore
the
> >     > > If the new paragraphs go in as proposed, then I think that
the two
to me
to be
better
I've
> >     think that
the
> >     github v9.
document
> >     conceptual XML

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 28 Nov 2017 11:28:27 +0100

On Mon, 2017-11-27 at 09:20 -0800, Andy Bierman wrote:
> > > > > It seems to me that these rules would allow individual data structures
> > to
> > > > > be
> The YANG designers need to consider the impact of when statements on the data
> model usage.
> to setup NACM with inappropriate granularity, where intended access is blocked
> > new
> The widespread use of vendor extensions and deviations makes it impossible to
> Perhaps the best the IETF can do is identify YANG usage patterns that need to
> considered
> when configuring NACM.
> 

Eliminating side effects would make them considerably more robust. Rules about a
particular instance should ideally fully determine what can happen with it -
such rules would be easy to set up up and maintain.

Lada 

> > > > > > > > My model is slightly different, that the server is a black box,
> > with
> > > > > > > > an
> > > > > > > > do causes the deletion of something I am not allowed to delete,
> > may
> > > > > > > > be
> > > > > > > > postulates to occur but have no idea what that might look like. 
> > And
> > > > > > > > I
> > > > > > > than it has been with CLI for 30 years, where every dependency is
> > ad-
> > > > > > > hoc
> > > > > > > > > > > differently does result in a deletion of those data nodes
> > from
> > > > > > > > the
> > > > > > > > > > > >>     There is also one further, unrelated change that I
> > am
> > > > > > > > proposing
> > > > > > > > > > > >>>>     * The rule does not have a "rule-type" defined or
> > the
> > > > > > > > > > > >>>>     "rule-
> > > > > > > > > > > >>>>     * The rule does not have a "rule-type" defined or
> > the
> > > > > > > > > > > >>>>     "rule-
> > > > > > > > > > > >>>>>         <[email-masked] <mailto:[email-masked]
> > >>
> > > > > > > > wrote:
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>