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

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

(Alia Atlas) Yes

(Ben Campbell) Yes

Comment (2017-10-25 for -07)
No email
send info
-1.1: The document contains lower case versions of 2119 words. Please consider the updated boilerplate from 8174.

(Benoît Claise) Yes

Alissa Cooper Yes

Warren Kumari Yes

Alexey Melnikov Yes

Comment (2017-10-25 for -07)
No email
send info
Thank you for a well written document.

(Kathleen Moriarty) Yes

Comment (2017-10-23 for -07)
No email
send info
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.

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

(Eric Rescorla) No Objection

Comment (2017-10-21 for -07)
No email
send info
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.

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2017-10-25 for -07)
No email
send info
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.