Skip to main content

Network Configuration Access Control Model
draft-ietf-netconf-rfc6536bis-09

Yes

Warren Kumari
(Alia Atlas)
(Alissa Cooper)
(Benoît Claise)

No Objection

(Alvaro Retana)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)

Note: This ballot was opened for revision 07 and is now closed.

Warren Kumari
Yes
Alexey Melnikov Former IESG member
Yes
Yes (2017-10-25 for -07) Unknown
Thank you for a well written document.
Alia Atlas Former IESG member
Yes
Yes (for -07) Unknown

                            
Alissa Cooper Former IESG member
Yes
Yes (for -07) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (2017-10-25 for -07) Unknown
-1.1: The document contains lower case versions of 2119 words. Please consider the updated boilerplate from 8174.
Benoît Claise Former IESG member
Yes
Yes (for -07) Unknown

                            
Kathleen Moriarty Former IESG member
Yes
Yes (2017-10-23 for -07) Unknown
Thanks for your work on this draft to improve access controls on data.

I'l watch responses to Eric's comment on line 648 as I agree with the concern.
Adam Roach Former IESG member
No Objection
No Objection (2017-10-25 for -07) Unknown
Quick note on Table 1:

   | HEAD    | all             | <get>               | N/A             |
   | GET     | all             | <get>               | N/A             |

Shouldn't these be "<get>, <get-config>" rather than just "<get>"?

----------------------------------------------------------------------

I'll note that there's a subtle OPTIONS-related attack here similar to what Eric calls out regarding PUT and PATCH.

This document appears to put no access restrictions whatsoever on the use of OPTIONS. RFC 8040, section 4.1 indicates that the answer can change based on the "specific resource", while RFC7231, section 4.3.7 stipulates that "a server's communication options typically depend on the resource." 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 and if no access control is applied to OPTIONS, then it can be used to trivially probe for the presence or absence of values within a tree.

I believe there should be text either in section 3.2.3 or under the "Security Considerations" section that warns implementations not to vary their OPTIONS responses based on the existence of the underlying resource.
Alvaro Retana Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2017-10-21 for -07) Unknown
Line 231
      object.  One of "none", "read", "create", "delete", "update", or
      "execute".
Your table below does not make use of "none" but rather makes use of N/A. Are they the same?


Line 469
   The RESTCONF protocol [RFC8040] is used for network management
   purposes within this document.
Maybe just merge these sentences?


Line 559
      is rejected with an "access-denied" error.

   The following sequence of conceptual processing steps is executed for
How does this discussion correspond to the diagram above. For instance, what does pre-read data node acc tl correspond to?

Line 648
      operation for these nodes is considered to be "none".  The edit
      begins at the target resource.
IMPORTANT: I believe this creates a modest vulnerability to treat
PATCH (and potentially PUT) this way because it allows the attacker to
confirm a guess for the contents of a resource it could not have read
(because the parents were unreadable). The attack here is to provide a
patch with the "before" being a guess for parts of the file and then
look for success or failure. How hard this is depends on file
structure (characters per line), etc.


Line 670
   | POST    | datastore, data | <edit-config>       | create          |
   | POST    | operation       | specified operation | N/A             |
   | PUT     | data            | <edit-config>       | create, replace |
I don't folllow why "Access operation" is N/A for, e.g. "GET". an you explain?


Line 673
   | PUT     | datastore       | <copy-config>       | replace         |
   | PATCH   | data, datastore | <edit-config>       | merge           |
   | DELETE  | data            | <edit-config>       | delete          |
"merge" does not appear in the list of access oeprations above.


Line 1057
        match any of the user's groups, proceed to the next rule-list
        entry.
Assuming I am reading this correctly, it is not possible to have
access control entries for individuals but only only for
groups. There's nothing wrong with that, but you should make it clear
earlier. If I'm wrong, can you correct me and explain what I'm
missing.
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -07) Unknown