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

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 <rwilton@cisco.com> 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 <rwilton@cisco.com <mailto:rwilton@cisco.com>> 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 <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> 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 <mbj@tail-f.com <mailto:mbj@tail-f.com>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I just read this thread, and I agree with the changes, but see below
>>>>> for a comment.
>>>>> 
>>>>> 
>>>>> Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> 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
>>>>> Netconf@ietf.org <mailto:Netconf@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>>>> Mahesh Jethanandani
>>>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org <mailto:Netconf@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>>> 
>> 
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
> 

Mahesh Jethanandani
mjethanandani@gmail.com