Misc security considerations on the current netconf draft

[Wes Hardaker <wjhns1@hardakers.net>]

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

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

Quick background on the documents current access-control: Some of the
commands, like edit-config, operate on specific elements of a
configuration set.  These are subject to, currently, the access
provided to the operator which has logged in over the "session".  IE,
if user A can't modify an interface on the console, he can't modify it
over the netconf channel via edit-config.

- Issue -1: Section 1.4.1 specifies that at least one netconf session
  must be supported.  So it's possible to tie up a lame box using a
  single connection.  Or its possible to tie up a medium box by
  logging in 10 times (its max)?  Does a connection mean the initial
  connection to the port, or a successful login through the transport?
  (I hope just opening a TCP connection doesn't qualify and that a
  full session must be established)

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

  Currently the document specifies that netconf commands must be
  subject to access control restrictions as if the same user was at
  the console.  IE, if you can't change the IP address at the console
  you must not be able to change it via netconf.

  What is missing in this approach is what should be legal remotely
  over what protocols and what isn't.  There are many cases where an
  operator in hardened security environments may only want to
  configure some aspect of a device if he can physically touch it.
  Let alone the ability to specify the minimum "protection level" a
  protocol must support before a operator can legally modify or view
  some aspect of it.  I know that interoperable access-control hasn't
  been dealt with from a standards point of view, but the protocol
  as-is seems dangerous to me as currently specified.

  A fundamental problem here is that existing access control
  mechanisms weren't necessarily designed to accommodate
  over-the-network modifications.  They weren't necessarily designed
  to say "don't let people do things without at least encryption
  turned on".  They weren't necessarily designed that way because it
  wasn't expected that some future protocol would call on them that
  way.  This issue will, hopefully, go away once a standardized access
  control system can be properly applied.  But in the mean time
  implementation of the netconf system means opening avenues of
  operation that you can't turn off or didn't even know you were
  allowing in.

  Also, when new standardized data models get deployed, will they
  be required to check their existing ACLs against the newer data
  models?  This is a potentially non-trivial mapping which could even
  be incompatible.

  When a standardized access control model gets figured out, will it
  be required to check both the local ACL implementation along with
  the standardized one (it should be, IMHO, because to do otherwise
  would potentially allow stuff through which was not expected to
  succeed).

  One of the ACL issues that will likely come up in the future is the
  frequent re-treeing issue as it applies to access control.  It has
  been frequently said that one of the advantages of XML is that
  anytime a change needs to be made to how the data is displayed or
  arranged, all you have to do is retree it and deploy the new
  structure.  Because its in xml, translating among old and new data
  models will be a snap.  What I think, however, will be difficult
  will be ensuring that an ACL setting defined by a NOC for a given
  operational environment.  If re-treeing happens frequently, its
  possible that access control "holes" will appear when new updates
  are applied to a network.  Doing access control by offering
  inclusion only rather than exclusion is going to be critical here to
  protect against this problem.

- Issue 2: Data modification style types (cli vs xml) with access control

  Current access control mechanisms are potentially designed for CLI
  usage.  They may not all be designed with the ability to figure out
  that if user A is trying to set an IP address trough netconf that it
  maps to one of a potentially few CLI requests that might effect the
  same data.  netconf operates on the data directly, where many access
  control models within CLI systems may model their ACL approach on the
  commands themselves instead.  This means that implementations will
  have to do a potentially complex and error-prone analysis of current
  CLI access control settings to data modification access control
  settings.  It makes implementing the current user-based ACL setting
  requirement difficult, only because of the difference in how things
  are done: data vs cli vs xxx?

- Issue 3: global operations vs specific access control

  Operations such as lock, commit, validate, copy-config, etc operate
  on an entire collection of configuration data.  But no where does
  the document specify how access control is treated in these cases.
  The fundamental issue here, which I've raised before specific to
  just the "lock" operation, is that the protocol is designed from a
  "root"-only mode perspective.  There has been a general goal all
  along to offer a more limited-role-oriented approach as well, parts
  of which exist now (the documentation describing the use of existing
  access control mechanisms) and parts of which are not yet specified
  (future access control, for which there has always been a desire to
  implement a localized modification limitation (user A can do this,
  but not that)).

  The problem is that no where in the document does it say where
  access control (current or future) is applied.  There are hints, but
  nothing explicit and complete.  This leads to questions which I'm
  not sure about the answers to, like:

    setup: lets say a user A can modify value X but not Y (if you want
    a hard core example to think about, consider the case where Y
    might be an IP address of an interface, and X might be the link
    up/down status).  Lets also say he can't even see the value Z (EG,
    firewall policy rules).

    - Can a user modify the value Y in the candidate vs running
      config?  (one or neither?)
    - Can a user modify the value Y in a file/URL config store?
    - Can a user validate all of the candidate config including value
      Z even if he couldn't see Z normally.
    - If a user copy's the running config to the candidate config,
      does it copy the candidate's value for Y and Z.
    - Can a user create a file containing Y and Z settings, and then
      use copy-config to candidate?

    This is not an exhaustive list.  I'll leave it to an exercise to
    the reader to generate a complete list for these cases.

- Issue 4: global operations vs multiple users

  The above list was just a starting list for a problem which only
  gets significantly compounded when you start involving multiple
  users.

    Further setup: B is a root-level operator than can do everything.

    - If B doesn't hold a lock on the candidate config and wants to
      modify restricted values Y or Z, can user A issue a
      discard-changes operation in the middle of B's edit stream, but
      before he does a commit (consider B deleting user A and A
      rolling it back before B commits it).  sub: what happens with
      A's session if his user is deleted in mid-stream, by the way.
    - If B does hold a lock on the candidate config, can A
      discard-changes to it?  I'd assume not, but I'd have to just
      hope that everyone implementing it would also realize this.
    - If B does hold a lock on the candidate config, can A copy it to
      running in the middle of his edits? (bad if B just opened up an
      access control or firewall setting where his next operation was
      going to close a particularly bad operation or port in the next
      operation).  Hopefully the copy-config would validate access
      control settings of all of the source first against whoever was
      actually committing?
    - If B modifies the candidate config for value Z (which A can't
      see), and A runs <validate> on the candidate config and there is
      a syntax error in Z's value, did the implementation ensure that
      the error message doesn't contain information about the exact
      nature of the problem (which would include the value, and
      possibly the configuration path (which can frequently contain
      valuable information)?
    - If B temporarily modifies the running config value Y, can A
      copy-config the running config to the startup data store thus
      making the change persistent?
    - If B does a confirmed commit and blows it and does something
      stupid, can A issue a <confirm>?


- Issue 5: protocol chaining:
  - We've discussed this before, but as long as I was writing stuff up
    anyway: the use of the url capability implies that authentication
    information must be passed from the netconf session to the URL
    session.  This could be done within the url for cases where that
    is possible and the URL supports it (http://user:password@host/ if
    I remember correctly), (note the drop in protocol protection in
    this case, which was a deliberate example).  If done properly
    through https using TLS, how do you specify which server certs or
    parent certificates are acceptable to avoid a spoofing attack?
    Some of this, of course, needs to be handled by the data model
    (like certificate authorization configuration).



- Issue 6: security considerations are not mandatory to implement.
  Users won't read them.  Cheap management systems may not implement
  them.

  EG: its written in many places you "should" use a lock, but that
  doesn't mean that everyone will have read the document entirely and
  that everyone implementing management stations will implement the
  lock "should".  Users won't be able to have an easy basis of
  understanding to enable them to pick between secure management
  stations which properly use locking techniques and those that do
  not.

  User's know that they need to pick tools with appropriate
  authentication and encryption, and they know that they may know that
  they need to pick tools that prevent multiple interacting managers
  from conflicting with each other (IE, they need locking).  However,
  locking is generally not considered necessary for security by users
  but the netconf protocol states in many places that you should use
  it for security reasons.  I don't think end-users will be able to
  make intelligent security choices about this.

  In summary: It bothers me that the solution to netconf security
  potential problems is to just "document it in the security
  considerations".  I suspect this will make the protocol harder to
  deploy and more vulnerable to future problems.


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

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

I drew a diagram on a sheet of paper on a plane yesterday that should
help think about this, but I haven't drawn it electronically yet.
I'll try to do that sometime soon, but I have a few work-critical
things to get done first.
-- 
"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/>