Re: Misc security considerations on the current netconf draft

[Andy Bierman <abierman@cisco.com>]

At 09:52 AM 5/19/2004, Wes Hardaker wrote:

>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.

thanks for your detailed review -- we need it!


>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).

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

I decided to stop worrying about all the corner cases
we have that result from misuse of the protocol operations.
We should just try to make it easy for the manager to use 
the protocol correctly, and document the proper error responses
for misuse cases.


>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)

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


>- 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)

Can you work with Rob to fix the text?

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

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


>  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.


Response to all comments related to granular access control:

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

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

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

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


>- 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).

these issues need to be worked out in the draft




>- 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.

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

The document says they need locking to prevent config changes
from other sources.  I think the best we can do is document
security issues in detail.  We can't mandate that people
read the RFCs in their entirety. 



>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.

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


>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.

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


>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

Andy


--
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/>