Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
Andy Bierman <andy@yumaworks.com> Sun, 12 November 2017 01:19 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06476128B91 for <netconf@ietfa.amsl.com>; Sat, 11 Nov 2017 17:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g7iJBZRUHVW for <netconf@ietfa.amsl.com>; Sat, 11 Nov 2017 17:18:59 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648531252BA for <netconf@ietf.org>; Sat, 11 Nov 2017 17:18:58 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id a2so14785086lfh.11 for <netconf@ietf.org>; Sat, 11 Nov 2017 17:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7PGO3vA9HIAhwgujyzsETq+hd9ICyI969j6v1tVX3s4=; b=ODnicjQlLNPBv9U5Yj2vLb3XT9WZZTqoGLbQNkEI/1071uFRiAuc/7t12b1fWNokZG 5P2ouow0Zs823XuspeWvbl6CKOVKppZHE8igNfHXfCr9xEoDjmMsCmrxXcPeyly6hpBX bprvqCBDV2yKWRVsdvAdBhh2qtvKcazpnl9hDKoTTmveNv384A+sUMnVXTIbDVtRY4Vv vU4qvlBBxsbfOIJOHqu4rYlffZAmEVXkp7LwauAQaKJRnVFjf92Au6Tt3SvxwPzpf+sZ UgGNBnNx7z58WuLszQ1kcP1mY2icK0vTeXaCywOEIkG3r9iH31E3S7SEmHbGdZLMTa+O DXVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7PGO3vA9HIAhwgujyzsETq+hd9ICyI969j6v1tVX3s4=; b=Bzb2wDV0QI4CMMZfckOz3pYbc19Q/mULZ+dzkE8r0CtgoPVYVEuz5BDLLWPHwTKTOL dONpQB/tdCDudRuRsVulvu46T3PAj8UZPMwsRpxupitfdPT8UB8NrcASUOXkGqAhZ8zQ VG5ejf7koLHaV8IKr03+41yAVugQ2QPxHD7KpGsxeAVS3aD5rwIA1ULJUKjuQ9kgH5GD OnASjBQuvKK/73/75caTW0iDp/Zv7RRaKjMPl14FyeaygFg7PYpmoY4fZSDhlEaLkceV drdxQvSn59oxEnC9yiZDeciISLTd6sL7FEy0S7Ow2ueqaAoGqJMP6PpGSc7fU43Jv2pi 9mLQ==
X-Gm-Message-State: AJaThX4YNmhFc1EHL7NWN1EfDHvnvA0sLbX9DVOb8xt8rnXREeklt827 iS2HXqvUP0bDtTbO5gYSdjdVWPRNQNamnke23S6vsg==
X-Google-Smtp-Source: AGs4zMajALJzsQfbLdtcCoIH5PyTjC4Tz5C0mX9Jtz5s/Ge5GKu/CX47G6NfUIAqyGKSHgAExkK2yj0ezB1vVQ+udpI=
X-Received: by 10.46.57.3 with SMTP id g3mr1695856lja.77.1510449536476; Sat, 11 Nov 2017 17:18:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.33.81 with HTTP; Sat, 11 Nov 2017 17:18:55 -0800 (PST)
In-Reply-To: <d3b6e152-f21c-e3d1-d72a-495574b0098f@cisco.com>
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <5f8d9c1c-9c4f-dc70-7eb6-09838ba97b46@cisco.com> <CABCOCHRM71Gv2txrjDhV=1bZB0a12_YvhgrpdX0iw14gk1w-Dw@mail.gmail.com> <078300ab-480d-057d-d441-9f8d730de1eb@cisco.com> <CABCOCHRDVEP3KZP0-m4mCPO7GTiTUAO+k6MrcSC3=1V-qN3ASQ@mail.gmail.com> <2F1909ED-61A5-43FC-B2D8-FD08DEF49183@gmail.com> <3138dace-d750-308f-0169-a26e8abce5d1@cisco.com> <5A05A4A4.3000304@tail-f.com> <CABCOCHT_5zHWf3mdNM+8uUd8sqZMKKiwVtr=O4C4BhNrbygNzw@mail.gmail.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> <CABCOCHSYYFrZxC11v_++adG2uCP7urxR=VOKX-+8zXA-qiBCTA@mail.gmail.com> <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> <CABCOCHTEXwhAq6NzoAGHcC-EE19bXJ0kbqPS0hwJB5_+RtOfyg@mail.gmail.com> <d3b6e152-f21c-e3d1-d72a-495574b0098f@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Sat, 11 Nov 2017 17:18:55 -0800
Message-ID: <CABCOCHRtBHjxdZ5wq5+mCohQuF77KoZRvfw6SA+vx76zCsws2g@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Per Hedeland <per@tail-f.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, NETCONF <netconf@ietf.org>, "sec-ads@ietf.org" <sec-ads@ietf.org>
Content-Type: multipart/alternative; boundary="089e082f6ee812bd78055dbef0bb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sXnCE2QCc8bNHPxpFjaGTH-6pAc>
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Nov 2017 01:19:03 -0000
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 On Fri, Nov 10, 2017 at 12:36 PM, Robert Wilton <rwilton@cisco.com> wrote: > 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: > > 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. > > 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 > > > On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton <rwilton@cisco.com> wrote: > >> >> >> On 10/11/2017 16:33, Andy Bierman wrote: >> >> >> >> On Fri, Nov 10, 2017 at 8:16 AM, Robert Wilton <rwilton@cisco.com> wrote: >> >>> >>> >>> On 10/11/2017 15:49, Andy Bierman wrote: >>> >>> >>> >>> On Fri, Nov 10, 2017 at 5:07 AM, Per Hedeland <per@tail-f.com> wrote: >>> >>>> On 2017-11-10 11:42, Robert Wilton wrote: >>>> > >>>> > >>>> > On 10/11/2017 10:02, Mahesh Jethanandani wrote: >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> Mahesh Jethanandani >>>> >> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com> >>>> >> On Nov 10, 2017, at 10:07 AM, Andy Bierman <andy@yumaworks.com >>>> <mailto:andy@yumaworks.com>> wrote: >>>> >> >>>> >>> 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? >>>> >> >>>> >> 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. >>>> >>>> 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. >>>> >>>> >>> >>> I do not see how the text can be interpreted this way. >>> >>> >>> 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. >>> >>> >> >> IMO the text does not support this interpretation. >> >> 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. >> >> >> 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. >> >> No. If the rules apply to descendant children, all normal examples work >> well (including the ones in the appendix). >> >> >> IMO the number of rules required to implement a use-case is not >> very relevant or objective criteria. >> >> Yes it is, particularly when the difference is between needing a 1 line >> rule, and a 100+ line rule. >> >> >> 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 >> >> 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. >> >> >> 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 >> >> 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 >>> >>> >>> 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. >>> >>> >>> >> 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. >> >> 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.) >>>> >>>> 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. >>>> >>> >>> The text does not say this at all so I do not approve of this change >>> >>> >>> 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 <rwilton@cisco.com >>>> <mailto:rwilton@cisco.com>> wrote: >>>> >>> >>>> >>> 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" < >>>> 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 ... >>>> >>> >>>> >>> On 08/11/2017 20:05, Andy Bierman wrote: >>>> >>>> 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. >>>> >>> 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 that case, explicit rules to read /A and /A/B would be >>>> needed >>>> >>>> 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 < >>>> rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote: >>>> >>>> >>>> >>>> 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: >>>> >>>>> 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/rfcdif >>>> f?url2=draft-ietf-netconf-rfc6536bis-08.txt < >>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6 >>>> 536bis-08.txt> >>>> >>>>> >>>> >>>>> <dfpcfioondggippe.png> >>>> >>>>> 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 >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> Netconf mailing list >>>> >>>>> Netconf@ietf.org <mailto:Netconf@ietf.org> >>>> >>>>> https://www.ietf.org/mailman/listinfo/netconf < >>>> https://www.ietf.org/mailman/listinfo/netconf> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Netconf mailing list >>>> >>> Netconf@ietf.org <mailto:Netconf@ietf.org> >>>> >>> https://www.ietf.org/mailman/listinfo/netconf >>>> >> >>>> >> Mahesh Jethanandani >>>> >> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com> >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Netconf mailing list >>>> > Netconf@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/netconf >>>> > >>>> >>>> >>> >>> >> >> > >
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Kent Watsen
- [Netconf] draft-ietf-netconf-rfc6536bis: one week… Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Per Hedeland
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Martin Bjorklund
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Martin Bjorklund
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Randy Presuhn
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Randy Presuhn
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise