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

[Andy Bierman <[e-mail]>]

Hi,

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


Andy


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

> 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:
>
> 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.
>
>
>
> On Nov 16, 2017, at 1:56 PM, Robert Wilton <[e-mail]> 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:
>
> 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.
>
>
> 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 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 <[e-mail]> wrote:
>
> "validating field information" is slightly unclear to me, can this be
> reworded slightly?
>
> Thanks,
> Rob
>
> On 16/11/2017 03:12, Andy Bierman wrote:
>
> 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 <
> [e-mail]> wrote:
>
>> 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 <[e-mail]> wrote:
>>
>> Hi,
>>
>> I just read this thread, and I agree with the changes, but see below
>> for a comment.
>>
>>
>> Andy Bierman <[e-mail]> wrote:
>>
>> 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:
>>
>>        *  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.
>>
>>
>> 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.
>>
>>
>> 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
>>
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>> Mahesh Jethanandani
>> [e-mail]
>>
>>
>
>
> _______________________________________________
> Netconf mailing [e-mail]://www.ietf.org/mailman/listinfo/netconf
>
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>