Re: Misc security considerations on the current netconf draft

[Wes Hardaker <wjhns1@hardakers.net>]

Wes> I've had the chance again to review a recent copy of the protocol
Wes> draft again, and have a few questions regarding what I read.  Some of
Wes> them are technical, some are nit-picks or clarification in nature, and
Wes> some are security related.  I'll split those categories into separate
Wes> mail messages.

Andy> thanks for your detailed review -- we need it!

Sorry for the delay in responding too you.  My clients aren't
prioritizing netconf at the moment, so real work gets in the way
sometimes....

Wes> One of the fundamental difficult parts of security with respect to the
Wes> current netconf protocol is it has a large number of commands which
Wes> are specific to portions of a given configuration set, but other
Wes> commands that operate on the whole of the set.  This
Wes> mixing-and-matching is going to inherently cause problems (that I'm
Wes> not at all convinced we can for-see them all which is what scares me
Wes> more than anything else).

Andy> Can you provide more details or an example that explains this more?
Andy> I don't see why the agent implementation would have a problem here.
Andy> Do you mean the manager will have problems?

The rest of the message was about examples of the types of problems I
was thinking about.  I apparently didn't make that clear though.

Andy> I decided to stop worrying about all the corner cases
Andy> we have that result from misuse of the protocol operations.

It's issues of misuse that I'm worried about.  It's the cases where
the misuse can lead to security compromises of some kind.

Wes> Quick background on the documents current access-control: Some of the
Wes> commands, like edit-config, operate on specific elements of a
Wes> configuration set.  These are subject to, currently, the access
Wes> provided to the operator which has logged in over the "session".  IE,
Wes> if user A can't modify an interface on the console, he can't modify it
Wes> over the netconf channel via edit-config.
Wes> 
Wes> - Issue -1: Section 1.4.1 specifies that at least one netconf session
Wes>   must be supported.  So it's possible to tie up a lame box using a
Wes>   single connection.  Or its possible to tie up a medium box by
Wes>   logging in 10 times (its max)?  Does a connection mean the initial
Wes>   connection to the port, or a successful login through the transport?
Wes>   (I hope just opening a TCP connection doesn't qualify and that a
Wes>   full session must be established)

Andy> We aren't setting maximum limits, we're setting minimum limits.
Andy> DOS attacks at the transport level are dealt with by the
Andy> transport protocol, not NETCONF.

It was the minimum level I was worried about.

Actually, the whole statement seems kind of an odd "no-duh" to me and
seems kind of silly to even state it, but hey...  whatever.

Wes> - Issue 0: section 2 does not discuss authentication of the server.
Wes>   EG, currently the only transports defined make use of certificates
Wes>   and section 2 doesn't talk about the need for the manager to
Wes>   validate the certificate of the TLS connection or ssh host key to
Wes>   ensure it is talking to who it thinks it is.  Since the transport
Wes>   security requirements are not defined, it is important to talk
Wes>   (generically) about both identification of *both* sides in both
Wes>   cases (2 identities or a shared secret-key type identity)

Andy> Can you work with Rob to fix the text?

Sure.

Wes>   
Wes> - Issue 1: current access control vs current protocol operations:

Andy> I don't like all the fuzzy coupling to CLI in the document, but
Andy> I agree with the design goal of leveraging access control
Andy> technology already in place for CLI-based configuration> We need
Andy> to specify this in detail or remove these 'console' references.

IMHO, you have 2 choices:

1) remove it entirely and add a note in the security section stating
   that this protocol must not be implemented unless an adequate
   access control mechanism is implemented along with it and that no
   standardized access control model exists yet today.

2) Leave it in and better document it.

Either way, all my points I think still remain a problem.  If you
don't specify *where* access control checks are important in the
protocol, it worries me people will get it wrong when they actually
implement it with their own access control mechanisms.  My examples
showed a number of hard cases to think about.  I'm very convinced that
without such guidelines, this protocol will be implemented in insecure
ways.  I suspect you disagree that it is a problem or are not willing
to expend the energy at this point in fixing this problem since you're
working so hard to move forward.

Wes>   Currently the document specifies that netconf commands must be
Wes>   subject to access control restrictions as if the same user was at
Wes>   the console.  IE, if you can't change the IP address at the console
Wes>   you must not be able to change it via netconf.
Wes> 
Wes>   What is missing in this approach is what should be legal remotely
Wes>   over what protocols and what isn't.  There are many cases where an
Wes>   operator in hardened security environments may only want to
Wes>   configure some aspect of a device if he can physically touch it.
Wes>   Let alone the ability to specify the minimum "protection level" a
Wes>   protocol must support before a operator can legally modify or view
Wes>   some aspect of it.  I know that interoperable access-control hasn't
Wes>   been dealt with from a standards point of view, but the protocol
Wes>   as-is seems dangerous to me as currently specified.
Wes> 
Wes>   A fundamental problem here is that existing access control
Wes>   mechanisms weren't necessarily designed to accommodate
Wes>   over-the-network modifications.  They weren't necessarily designed
Wes>   to say "don't let people do things without at least encryption
Wes>   turned on".  They weren't necessarily designed that way because it
Wes>   wasn't expected that some future protocol would call on them that
Wes>   way.  This issue will, hopefully, go away once a standardized access
Wes>   control system can be properly applied.  But in the mean time
Wes>   implementation of the netconf system means opening avenues of
Wes>   operation that you can't turn off or didn't even know you were
Wes>   allowing in.
Wes> 
Wes>   Also, when new standardized data models get deployed, will they
Wes>   be required to check their existing ACLs against the newer data
Wes>   models?  This is a potentially non-trivial mapping which could even
Wes>   be incompatible.
Wes> 
Wes>   When a standardized access control model gets figured out, will it
Wes>   be required to check both the local ACL implementation along with
Wes>   the standardized one (it should be, IMHO, because to do otherwise
Wes>   would potentially allow stuff through which was not expected to
Wes>   succeed).
Wes> 
Wes>   One of the ACL issues that will likely come up in the future is the
Wes>   frequent re-treeing issue as it applies to access control.  It has
Wes>   been frequently said that one of the advantages of XML is that
Wes>   anytime a change needs to be made to how the data is displayed or
Wes>   arranged, all you have to do is retree it and deploy the new
Wes>   structure.  Because its in xml, translating among old and new data
Wes>   models will be a snap.  What I think, however, will be difficult
Wes>   will be ensuring that an ACL setting defined by a NOC for a given
Wes>   operational environment.  If re-treeing happens frequently, its
Wes>   possible that access control "holes" will appear when new updates
Wes>   are applied to a network.  Doing access control by offering
Wes>   inclusion only rather than exclusion is going to be critical here to
Wes>   protect against this problem.

Andy> Response to all comments related to granular access control:

Andy> We are not chartered to work on the issue at this time.

Andy> How does the agent know who can do what to which objects?
Andy> First you standardize a data definition language that
Andy> includes mechanisms to describe the access control requirements
Andy> for all objects and attributes (e.g., MAX-ACCESS, MIN-ACCESS),
Andy> standardize data naming, and standardize an overall data model
Andy> framework.  Then you can design an access control model and
Andy> a data model to configure and monitor it.

Andy> I don't really want to throw in a temporary access control model
Andy> that provides a little bit of granularity.  I think this is big
Andy> enough and important enough that a WG spend the time to get it
Andy> right the first time.

You do realize that you *have* specified access control in the current
document, right?

Andy> Of course, nothing is stopping anyone from writing an I-D
Andy> proposing an access control model, to get this work started.

As I mentioned 2 years ago when this work was first getting going, I
suggested that security and data modeling be started immediately.  I'm
still sad that it hasn't been started.  At least the data modeling has
almost begun...

Wes> - Issue 2: Data modification style types (cli vs xml) with access control
Wes> 
Wes>   Current access control mechanisms are potentially designed for CLI
Wes>   usage.  They may not all be designed with the ability to figure out
Wes>   that if user A is trying to set an IP address trough netconf that it
Wes>   maps to one of a potentially few CLI requests that might effect the
Wes>   same data.  netconf operates on the data directly, where many access
Wes>   control models within CLI systems may model their ACL approach on the
Wes>   commands themselves instead.  This means that implementations will
Wes>   have to do a potentially complex and error-prone analysis of current
Wes>   CLI access control settings to data modification access control
Wes>   settings.  It makes implementing the current user-based ACL setting
Wes>   requirement difficult, only because of the difference in how things
Wes>   are done: data vs cli vs xxx?
Wes> 
Wes> - Issue 3: global operations vs specific access control
Wes> 
Wes>   Operations such as lock, commit, validate, copy-config, etc operate
Wes>   on an entire collection of configuration data.  But no where does
Wes>   the document specify how access control is treated in these cases.
Wes>   The fundamental issue here, which I've raised before specific to
Wes>   just the "lock" operation, is that the protocol is designed from a
Wes>   "root"-only mode perspective.  There has been a general goal all
Wes>   along to offer a more limited-role-oriented approach as well, parts
Wes>   of which exist now (the documentation describing the use of existing
Wes>   access control mechanisms) and parts of which are not yet specified
Wes>   (future access control, for which there has always been a desire to
Wes>   implement a localized modification limitation (user A can do this,
Wes>   but not that)).
Wes> 
Wes>   The problem is that no where in the document does it say where
Wes>   access control (current or future) is applied.  There are hints, but
Wes>   nothing explicit and complete.  This leads to questions which I'm
Wes>   not sure about the answers to, like:
Wes> 
Wes>     setup: lets say a user A can modify value X but not Y (if you want
Wes>     a hard core example to think about, consider the case where Y
Wes>     might be an IP address of an interface, and X might be the link
Wes>     up/down status).  Lets also say he can't even see the value Z (EG,
Wes>     firewall policy rules).
Wes> 
Wes>     - Can a user modify the value Y in the candidate vs running
Wes>       config?  (one or neither?)
Wes>     - Can a user modify the value Y in a file/URL config store?
Wes>     - Can a user validate all of the candidate config including value
Wes>       Z even if he couldn't see Z normally.
Wes>     - If a user copy's the running config to the candidate config,
Wes>       does it copy the candidate's value for Y and Z.
Wes>     - Can a user create a file containing Y and Z settings, and then
Wes>       use copy-config to candidate?
Wes> 
Wes>     This is not an exhaustive list.  I'll leave it to an exercise to
Wes>     the reader to generate a complete list for these cases.
Wes> 
Wes> - Issue 4: global operations vs multiple users
Wes> 
Wes>   The above list was just a starting list for a problem which only
Wes>   gets significantly compounded when you start involving multiple
Wes>   users.
Wes> 
Wes>     Further setup: B is a root-level operator than can do everything.
Wes> 
Wes>     - If B doesn't hold a lock on the candidate config and wants to
Wes>       modify restricted values Y or Z, can user A issue a
Wes>       discard-changes operation in the middle of B's edit stream, but
Wes>       before he does a commit (consider B deleting user A and A
Wes>       rolling it back before B commits it).  sub: what happens with
Wes>       A's session if his user is deleted in mid-stream, by the way.
Wes>     - If B does hold a lock on the candidate config, can A
Wes>       discard-changes to it?  I'd assume not, but I'd have to just
Wes>       hope that everyone implementing it would also realize this.
Wes>     - If B does hold a lock on the candidate config, can A copy it to
Wes>       running in the middle of his edits? (bad if B just opened up an
Wes>       access control or firewall setting where his next operation was
Wes>       going to close a particularly bad operation or port in the next
Wes>       operation).  Hopefully the copy-config would validate access
Wes>       control settings of all of the source first against whoever was
Wes>       actually committing?
Wes>     - If B modifies the candidate config for value Z (which A can't
Wes>       see), and A runs <validate> on the candidate config and there is
Wes>       a syntax error in Z's value, did the implementation ensure that
Wes>       the error message doesn't contain information about the exact
Wes>       nature of the problem (which would include the value, and
Wes>       possibly the configuration path (which can frequently contain
Wes>       valuable information)?
Wes>     - If B temporarily modifies the running config value Y, can A
Wes>       copy-config the running config to the startup data store thus
Wes>       making the change persistent?
Wes>     - If B does a confirmed commit and blows it and does something
Wes>       stupid, can A issue a <confirm>?
Wes> 
Wes> 
Wes> - Issue 5: protocol chaining:
Wes>   - We've discussed this before, but as long as I was writing stuff up
Wes>     anyway: the use of the url capability implies that authentication
Wes>     information must be passed from the netconf session to the URL
Wes>     session.  This could be done within the url for cases where that
Wes>     is possible and the URL supports it (http://user:password@host/ if
Wes>     I remember correctly), (note the drop in protocol protection in
Wes>     this case, which was a deliberate example).  If done properly
Wes>     through https using TLS, how do you specify which server certs or
Wes>     parent certificates are acceptable to avoid a spoofing attack?
Wes>     Some of this, of course, needs to be handled by the data model
Wes>     (like certificate authorization configuration).

Andy> these issues need to be worked out in the draft

If you mean the issues 2-5, I'm happy to hear that.  I'm not sure from
your sentence which issues you're referring to.  It could have been
you only were talking about #5.

Wes> - Issue 6: security considerations are not mandatory to implement.
Wes>   Users won't read them.  Cheap management systems may not implement
Wes>   them.
Wes> 
Wes>   EG: its written in many places you "should" use a lock, but that
Wes>   doesn't mean that everyone will have read the document entirely and
Wes>   that everyone implementing management stations will implement the
Wes>   lock "should".  Users won't be able to have an easy basis of
Wes>   understanding to enable them to pick between secure management
Wes>   stations which properly use locking techniques and those that do
Wes>   not.
Wes> 
Wes>   User's know that they need to pick tools with appropriate
Wes>   authentication and encryption, and they know that they may know that
Wes>   they need to pick tools that prevent multiple interacting managers
Wes>   from conflicting with each other (IE, they need locking).  However,
Wes>   locking is generally not considered necessary for security by users
Wes>   but the netconf protocol states in many places that you should use
Wes>   it for security reasons.  I don't think end-users will be able to
Wes>   make intelligent security choices about this.
Wes> 
Wes>   In summary: It bothers me that the solution to netconf security
Wes>   potential problems is to just "document it in the security
Wes>   considerations".  I suspect this will make the protocol harder to
Wes>   deploy and more vulnerable to future problems.

Andy> These security concerns are no different than for any other
Andy> protocol you could name.  Operators and developers need to
Andy> be aware of security details.  

My problem is that the issues are complex and not discussed anywhere.
It vaguely states that you should use locks, but doesn't state how
critical they are.

Wes> Many of these issues and their examples are only initial quickly
Wes> thought up examples.  What scares me is not the examples themselves,
Wes> but rather how each company might decide what to do in a different
Wes> way.  Or even worse, miss some of the critical things to get right
Wes> that are subtle (the copy-config or commit to running during mid-edit
Wes> by someone else with greater power is a good example, as well as the
Wes> discard-changes in mid-edit).  Access control will likely need to be
Wes> checked at multiple points, and it is critical to get all those points
Wes> right regardless of whether this applies to existing access control
Wes> mechanisms or future ones.  IE, you can't discard describing how
Wes> access control is applied just because you're leveraging existing
Wes> mechanisms.  You still need to state how and when it is applied.

Andy> We can state where access control (in the processing flow) is
Andy> applied.  We can specify a standard access control model as
Andy> follow-up work.  Not unlike how VACM was added to SNMP.

I'd very much like to see where access control is applied.  This would
alleviate many of my concerns.

Wes> I'm not convinced we could enumerate all the tricky things to get
Wes> right with 100% certainty.  I'm also not looking forward to the many
Wes> rules that will have to be stated when we get to the standardized
Wes> access control model.  I don't believe implementations will correctly
Wes> map their access control settings to the current protocol operations
Wes> properly.  1-1 mappings are fairly easy to get right.  M-N mappings
Wes> are quite a bit harder to get right, which is where this is currently
Wes> left.

Andy> We aren't creating an access control model now, but when we do,
Andy> I'm sure we won't get it 100% perfect on the first try.  

Well, I hope future netconf customers read this ;-)  They should wait
for a few revisions I guess :-)

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>